Netflow export doesn't work with vrf lite on 6500?

Hi, I've configured netflow on a 6500 with vrf lite enabled, but can't seem to get the 6500 to export to the destination.

router>sh ip flow export Flow export v5 is enabled for main cache Exporting flows to x.x.x.x (9800) x.x.x.x (9800) Exporting using source interface Vlan Version 5 flow records 474136 flows exported in 147459 udp datagrams 0 flows failed due to lack of export packet 1 export packets were sent up to process level 147457 export packets were dropped due to no fib

Reply to
centaury_utopian
Loading thread data ...

Not all IOS features are vrf-aware on all releases on all platforms.

What often happens is that router-originated traffic is emitted in the global vrf rather than in the vrf associated with the "source-interface".

On the assumption that this is your problem, let me give you a possible generic workaround. I've fleshed it out with some netflow specifics.

interface loopback 1 ip vrf forwarding your-management-vrf ip address 1.1.1.1 255.255.255.255

ip flow-export source loopback1 ip flow-export destination 2.2.2.2 2055

ip access-list extended vrf-magic permit udp host 1.1.1.1 host 2.2.2.2 eq 2055

route-map vrf-magic permit 10 match ip address vrf-magic set interface loopback1

ip local policy route-map vrf-magic

! Note that this route is in the global vrf ip route 2.2.2.2 255.255.255.255 loopback1

! And, of course, you have your regular route in the production vrf ip route your-production-vrf 2.2.2.0 255.255.255.0 VLAN mumble

The traffic starts in the global VRF and routed out through an interface that's in your production VRF. All things being equal, this wouldn't help much since the outbound interface is in the one vrf and the traffic being directed through it is in another. But the local policy route fixes that up and you end up routing the traffic out through your production vrf. Note that this technique works with unidirectional outbound flows such as syslog or SNMP traps. Or Netflow. It doesn't neccessarily do the job for bidirectional flows like TACACS where the reply traffic from the authentication server has to get back into the global vrf in order to be properly recognized.

Failing this, you may be stuck running an actual cable between vrfs and seeing if you can get this past your security folks.

Reply to
briggs

Thanks, tried it out and it works!

I understand the reasoning of the approach, but I'm not sure why the global route is needed:

Wouldn't the local policy-routing take precedence over this global route anyway?

Nevertheless the global route is indeed required, as i tried removing the global route and the 6500 had problem forwarding the netflow.

snipped-for-privacy@encompasserve.org wrote:

Reply to
centaury_utopian

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.