Rubens Kuhl Jr. wrote: > Packets originating from the router can be controlled by: > ip local policy route-map <name of the route map> > > One thing I would try, but I have no idea if it works, is policy > routing the traffic to a loopback interface that belongs to a VRF. > The netflow export address would be the one inside the VRF, the source > will be inside the global routing table, but the PBR would match udp > to that address and port and set the next-hop to the loopback > interface.
I have my doubts that would work on hardware platforms, but anyway... > Let's repeat: it's just an idea, not something from a reference or > that had real testing. I am fairly sure that won't work, for the simple reason that it won't always be the CPU/MSFC that generates the packets. In many cases, the PFC or DFCs generate the netflow export packets. The Netflow/UDP packets would need to be emitted by the PFC/DFC directly onto the fabric bound for an output port(s), and thus a FIB lookup will need to take place. It's my understanding that the bit of the PFC/DFC doing the NDE doesn't lookup in the VPN/VRF TCAM. Whether it could be made to I don't know. It might be possible to force the MSFC to handle the netflow packets (e.g. by enabling one of the options such as source/dest AS# which have to be "filled in" on the CPU) and then the VRF export might work; but it would cost MSFC CPU. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
