[c-nsp] PBR within MPLS VPN

[Jeff Bacon]

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....

Thanks
-bacon



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
https://supportforums.cisco.com/thread/2017902

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.

HTH
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 172.31.1.1/32<http://172.31.1.1/32>, a PE device in an MPLS mesh. device B is a cat6500/sup720, global IP 172.31.1.14/32<http://172.31.1.14/32>, PE device in another city. there is a VRF "fred" defined. There's device C, also with VRF fred, global IP 172.31.2.3/32<http://172.31.2.3/32>, publishing a default route.


host1 (172.30.250.40) -> 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    172.31.250.32 is directly connected, Vlan49    <---- host1 is here
     200.3.3.0/24<http://200.3.3.0/24> is variably subnetted, 3 subnets, 3 masks
B       200.3.3.32/29<http://200.3.3.32/29> [200/0] via 172.31.1.14, 3d18h
B*   0.0.0.0/0<http://0.0.0.0/0> [20/8192] via 64.1.1.1, 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-172.30.250.40/32
   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 172.31.1.14.

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,
-bacon



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