[c-nsp] route-target import on non-leaking PEs

[Jason Lixfeld]

On 2012-12-13, at 10:12 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 13/12/12 15:04, Jason Lixfeld wrote:
>> 
>> On 2012-12-13, at 9:56 AM, Phil Mayers <p.mayers at imperial.ac.uk>
>> wrote:
>> 
>>> On 13/12/12 14:47, Jason Lixfeld wrote:
>>>>> 
>>>>> Yes. In fact, that's *required* if you want to do multi-path.
>>>> 
>>>> I seem to do multi-path just fine with maximum-paths ibgp 2 on my
>>>> RR clients inside a VRF that sees a default sourced from two
>>>> different RRs.  Said VRF has a common RD between the two PEs.
>>>> 
>>>> How is that different?
>>> 
>>> Well, AIUI multipath *ought* to require unique RDs. Obviously not;
>>> I wonder how that's working for you?
>> 
>> So based on the link you posted previously, which I am currently
>> making my way through, what's happening is on my production network
>> where this multi-path stuff is actually working, I'm using XR as my
>> RRs, which has add-path support.
> 
> Presumably the RR clients have add-path too (it's needed at both ends)?

I was just going to reply to my last post and correct myself...  This seems to work on 7600s but not on ME3600s.. (both running 15.2(2)S1).  I saw multi-path on the 7600s and presumed it was working everywhere.   Both are RR clients of the two ASR9k PEs that are sourcing the defaults.

rrc-7600#sh ip bgp vpnv4 vrf Inetv4 0.0.0.0
BGP routing table entry for 1:4:0.0.0.0/0, version 6002
Paths: (2 available, best #2, table Inetv4, not advertised to EBGP peer)
Multipath: iBGP
  Not advertised to any peer
  Refresh Epoch 1
  Local
    1.1.1.11 (metric 20) from 1.1.1.11 (1.1.1.11)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath(oldest)
      Community: 1:65535 no-export
      Extended Community: RT:1:4
      mpls labels in/out nolabel/16000
  Refresh Epoch 1
  Local
    1.1.1.10 (metric 20) from 1.1.1.10 (1.1.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal, multipath, best
      Community: 1:65535 no-export
      Extended Community: RT:1:4
      mpls labels in/out nolabel/289985
rrc-7600##sh ip cef vrf Inetv4 0.0.0.0/0 detail       
0.0.0.0/0, epoch 35, flags rib defined all labels, default route, per-destination sharing
  recursive via 1.1.1.10 label 289985
    nexthop 1.1.1.166 TenGigabitEthernet7/0/0
  recursive via 1.1.1.11 label 16000
    nexthop 1.1.1.164 TenGigabitEthernet7/0/1
rrc-7600#


vs.


rrc-3600#sh ip bgp vpnv4 vrf Inetv4 0.0.0.0
BGP routing table entry for 1:4:0.0.0.0/0, version 20719
Paths: (2 available, best #1, table Inetv4, not advertised to EBGP peer)
Multipath: iBGP
  Not advertised to any peer
  Refresh Epoch 1
  Local
    1.1.1.11 (metric 30) from 1.1.1.11 (1.1.1.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 1:65535 no-export
      Extended Community: RT:1:4
      mpls labels in/out nolabel/16000
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local
    1.1.1.10 (metric 40) from 1.1.1.10 (1.1.1.10)
      Origin IGP, metric 0, localpref 100, valid, internal
      Community: 1:65535 no-export
      Extended Community: RT:1:4
      mpls labels in/out nolabel/289985
      rx pathid: 0, tx pathid: 0
rrc-3600#sh ip cef vrf Inetv4 0.0.0.0/0 detail
0.0.0.0/0, epoch 0, flags rib defined all labels, default route
  recursive via 1.1.1.11 label 16000
    nexthop 1.1.1.197 TenGigabitEthernet0/2 label 36
rrc-3600#

> Other explanations might be that by chance one RR had advertised one path and the other RR another path.

This is actually the case.  I should have been more clear in this regard.  Two PEs each sourcing a default route.  Each of these two PEs is a RR for downstream PEs which are RR clients of both RRs.

> But yes, my original email should have been more specific: unless you have add-paths, unique RD is required for multipath.

So... looks like I do need to do a different RD on my other default-route-sourcing PE.  If I'm reading the output of those two commands correctly, add path seems to be there on the 7600s (albeit in an undocumented manner) but not at all on the ME3600s.

This continues to be a really eye-opening thread for me.  Thanks all for taking the time to continue to participate.

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