It sounds impossible, right? So let's double-check the basics to ensure you're in the clear before digging into NTA.
- Is the policy built correctly? If it's missing some traffic definitions, and that traffic is hitting that interface, your policy may not be in play.
- Is it applied?
- Is it applied to the right interface?
- Can you prove the amount of traffic is actually hitting that policy and exceeding the egress limitation you've installed?
- Show us your policy. I'm certain there are some great Policy Building Thwack members who can confirm you've got it down pat.
- How are you testing it? Maybe with WAN Killer running outside of business hours for a brief period? Don't impact the users, but DO prove you've got the problem you think you do.
- Is NTA getting the right information? From the right hardware and interfaces? I've seen times where I thought I had it built correctly, then later discovered the hardware couldn't support one or more NetFlow items (e.g.: Ingress versus Egress) that I was counting on.
- Show us the Netflow configuration on your switch or router so you've got another few sets of eyes on it. Maybe someone will recognize a limitation or gotcha . . .
It can depend on how you have Netflow configured sometimes and the number of interfaces you have.
The rule of thumb is to configure Netflow on the ingress of every interface, and that should work pretty well.
The problem is this. Lets say you have a router with two WAN links g0/0 and g0/1 both at 500Mbps. Most traffic will go to your LAN, but if two sites are communicating directly with eachother, it could transit across both WAN interfaces. So, just taking the WAN interfaces, if you configured "ip flow ingress" and "ip flow egress" on both of them, and that that was the only place you had netflow configured on the router. Traffic going to your LAN would look correct in bandwidth numbers, but traffic transiting from one WAN link to the other would be double the actual values? Why?
Lets say you had a 100kbps of video traffic coming from a site on g0/0 to another site on g0/1 and the same amount of return traffic. Netflow would first record it on the ingress of g0/0 and the same traffic on the egress of g0/1, and visa versa. The traffic that initially came in the ingress of g0/1 would be counted both there and when it egressed to g0/0. Does that make sense?
So, now if you have g0/2 being your LAN interface and both ingress and egress configured there, your also doubling traffic that flows across those.
Now lets say you have a GRE tunnel going out G0/0 to a site, if you configure netflow on the tunnel interface, as well as the g0/0 itself, you would not only see the GRE traffic, but the individual flows within the tunnel.
Gets confusing, but does make some sense. Now, there are reasons to configure ip flow egress, like if you have a WAN compression device and you want to record the traffic POST compression, you would want to do egress on that interface
Post your config and we can try and figure it out a bit more?
Sorry for the delay. Here is the config on the interface, for netflow and QoS
ip address 192.168.x.x 255.255.255.252
ip access-group BORDER_ACCESS in
ip nbar protocol-discovery
ip flow monitor FAPS-MON input
ip flow monitor FAPS-MON output
crypto map FAPS
service-policy input XO_IN
service-policy output Shaping
class-map match-any Critical
match dscp af31 af32 af33 cs6 cs7
class-map match-any Realtime
match dscp cs3 cs5 ef
class-map match-any Critical-Plus
match dscp cs4 af41 af42 af43
match protocol gre
match protocol ipsec
priority percent 30
bandwidth remaining percent 50
bandwidth remaining percent 50
shape average 3000000
set dscp ef
set dscp af31
set dscp cs4
flow exporter FAPS-EXP
transport udp 2055
flow monitor FAPS-MON
record netflow ipv4 original-input
I think your flows are displaying on completion instead of being transmitted to your NTA at regular intervals. Not sure why the default is 30 minutes, but I had this issue when I first configured NetFlow.
flow timeout active 60
Dizzyhminus and HolyGuacamole were both pretty close. Under flexible netflow it is:
flow monitor <monitor name>
cache timeout active 60
Thanks for getting me on the right track to solve this.
I think mine might have been for NX-OS, glad it worked out for you. I'm having a similar issue with some ASAs but I think it could be a bug in the code level. as my timeouts are configured for one minute.