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

Discussion in 'Cisco' started by centaury_utopian, Oct 12, 2006.

  1. 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<id>
    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 <------- No
    0 export packets were dropped due to adjacency issues
    0 export packets were dropped due to fragmentation failures
    0 export packets were dropped due to encapsulation fixup failures
    0 export packets were dropped enqueuing for the RP
    0 export packets were dropped due to IPC rate limiting

    Since the export destination is a host in a vlan belonging to a vrf, I
    thought by setting the source VLAN would do the trick:
    router(config)# ip flow-export source Vlan<id>

    but doesn't seem to be the case.

    So the question is, when the destination host is in a vlan of a vrf,
    how do I configure so that the 6500 knows how to forward flows

    centaury_utopian, Oct 12, 2006
    1. Advertisements

  2. centaury_utopian

    briggs Guest

    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

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

    ip access-list extended vrf-magic
    permit udp host host 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 loopback1

    ! And, of course, you have your regular route in the production vrf
    ip route your-production-vrf 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.
    briggs, Oct 12, 2006
    1. Advertisements

  3. 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.
    centaury_utopian, Oct 16, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.