[c-nsp] PBR within MPLS VPN

Jeff Bacon bacon at walleyesoftware.com
Wed Aug 29 12:53:48 EDT 2012

This was actually useful, but only to the extent that I've determined that "no you really can't do that" - "show tcam int" confirmed that using "set ip vrf X next-hop recursive Y" is software-punted, and the combinations that do create a hdw forward entry send packets into some random black hole.

I suppose I can see this - the packet is already part-way through the switching path and it's probably already missed the turn-off that would allow the switch to stick an MPLS label on it - it'd have to be recirc'ed, and Cisco would be understandably not keen to create too many recirc paths.

it would appear - though I haven't tried it - that "set ip next-hop recursive" _is_ supported in hdw on the sup2t which I have in the primary POP, not the secondary POP. And I can't justify a full-on upgrade just for this...

I wonder if the ME3600Xs support it? Hm....


From: Xu Hu [mailto:jstuxuhu0816 at gmail.com]
Sent: Tuesday, August 28, 2012 11:24 PM
To: Jeff Bacon
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] PBR within MPLS VPN

Hi Bacon,

For the PBR hardware switched or software switched, it depends, please check the detail as below website

For the question which you raised "Or can you not policy-route to a non-directly-connected PE over MPLS using PBR?"
The answer is, of course, you can do.

Hu Xu
2012/8/29 Jeff Bacon <bacon at walleyesoftware.com<mailto:bacon at walleyesoftware.com>>
As I sit and write this, this starts to sound stupid even to me. Just stick with it, please, THEN tell me I'm being stupid. :)

So, device A is a cat6500/sup720, global IP<>, a PE device in an MPLS mesh. device B is a cat6500/sup720, global IP<>, PE device in another city. there is a VRF "fred" defined. There's device C, also with VRF fred, global IP<>, publishing a default route.

host1 ( -> int vlan 49/vrf-fred/device-A <-> MPLS mesh <-> int g3/1/vrf-fred/device-B -> <INTERNET>
                                              -> device-C-publishing-default-route -> <OTHERINTERNET>

so, the route table in VRF fred on device A looks like:

C is directly connected, Vlan49    <---- host1 is here<> is variably subnetted, 3 subnets, 3 masks
B<> [200/0] via, 3d18h
B*<> [20/8192] via, 5d23h

now, please don't ask why, but I want to be able to policy-route host1's traffic to make it use device-B and not follow the default route, e.g.:

int vlan 49
  ip policy route-map source-route-map

route-map source-route-map permit 10
   match ip address ACL-matching-
   set ip next-hop <something-making-it-go-to-B>

I have no idea what <something> should be.

Now, I can do "set ip next-hop recursive X" where X is a real IP in VRF fred on device B. Works fine. It's also software-switched - fast-path, "show ip cef switching stat feat" increments showing PBR is working via CEF, but "show int vlan49 switching" tells me that the packets are being fast-path-switched, not hardware-switched.

Release notes say that "set ip next-hop" is supported in hardware. But that presumes I give it the right IP address.

The problem is this: so what's the next-hop that I *can* use to specify CEF adjacency of "that specific other PE device over there, VRF fred"? It doesn't appear to be

Or can you not policy-route to a non-directly-connected PE over MPLS using PBR?

(I can hear it now - "that's what TE is for" or "can't you split the traffic into separate VRFs and use source selection"... ok, yes, well... )

Thanks for your indulgence,

cisco-nsp mailing list  cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list