[c-nsp] IOS XR - advertising additional paths with RR

Thu Aug 22 22:33:34 EDT 2013

Hi,

Just for future reference - I managed to identify the issues:
1. ASR903 doesn't support additional paths if the peer is configured
with ha-mode sso - has to be downgraded to GR instead.
2. Due to manipulation of next-hops between the 'access' and 'core'
domains to make UMPLS work the P1/RR was setting all ipv4 prefixes to
next-hop self (even if they were received from P2).

Once that cleared I can see a backup path as expected:
 #sh ip cef 10.122.129.255/32 detail
10.122.129.255/32, epoch 3, flags rib defined all labels
  recursive via 10.123.129.1 label 16013
    nexthop 10.123.129.1 Tunnel3000
  recursive via 10.123.129.3 label 40, repair
    nexthop 10.123.129.3 Tunnel3001

kind regards
Pshem

On 23 August 2013 10:26, Pshem Kowalczyk <pshem.k at gmail.com> wrote:
> Hi,
>
> I'm trying to lab out a setup for core PIC on IOS XR using 4.2.3. I'm
> not sure if my understanding of the feature is correct, so please
> correct me if I'm going down the rabbit hole.
>
> My setup:
>
> PE1---P1/RR--PE2
>      \      |        /
>            P2
>
> (both PE1 and PE2 are multihomed to P1/RR and P2, there is a link
> between P1/RR and P2)
>
> PE1 - ASR901 (15.3.3) (lo0: 10.122.129.255)
> PE2 - ASR903 (3.10.0) (lo0: 10.123.129.2)
> P1 - ASR9k (4.2.3) (lo0: 10.123.129.1)
> P2 - ME3600x (3.10.0) (lo0: 10.123.129.3)
>
> PE1 is part of the 'access' domain (unified MPLS) and has BGP sessions
> with both P1/RR and P2. PE2 is part of the 'core' domain and only has
> a session with P1/RR
> P2 is part of the 'core' domain and has a session with P1/RR (and PE1
> for the 'access')
>
> P1/RR is the core RR for P2 and PE2.
> P1/RR is access RR for PE1
> P2 is access RR for PE1.
>
> I expect that if I enable core PIC for ipv4 I should be able to see
> both paths from PE2 to PE1 (i.e via P1/RR and P2) on P2. And
> conversely I should be able to see both  paths from PE1 to PE2.
>
> on PE1 I can see both paths to PE2 (10.123.129.2):
>
> #sh ip bgp 10.123.129.2
> BGP routing table entry for 10.123.129.2/32, version 106
> Paths: (2 available, best #1, table default)
>   Additional-path-install
>   Not advertised to any peer
>   Refresh Epoch 1
>   Local
>     10.123.129.11 (metric 2) from 10.123.129.11 (10.123.129.1)
>       Origin IGP, metric 0, localpref 100, valid, internal, best
>       Community: 17492:1100 17492:62902
>       Originator: 10.123.129.2, Cluster list: 10.123.129.1
>       mpls labels in/out nolabel/16012
>       rx pathid: 0x1, tx pathid: 0x0
>   Refresh Epoch 2
>   Local
>     10.123.129.14 (metric 2) from 10.123.129.14 (10.123.129.3)
>       Origin IGP, metric 0, localpref 100, valid, internal, backup/repair
>       Community: 17492:1100 17492:62902
>       Originator: 10.123.129.2, Cluster list: 10.123.129.3, 10.123.129.1
>       mpls labels in/out nolabel/43
>       rx pathid: 0, tx pathid: 0
>
>
> #sh ip cef 10.123.129.2
> 10.123.129.2/32
>   nexthop 10.122.129.1 Vlan4001 label [implicit-null|26] 16012
>     repair: attached-nexthop 10.122.129.9 Vlan4002
>
> That works because there are two distinct BGP sessions (with P1/RR and P2).
>
> However on PE2 I can only see one path for PE1 (10.122.129.255):
>
> #sh ip bgp 10.122.129.255
> BGP routing table entry for 10.122.129.255/32, version 59
> Paths: (1 available, best #1, table default)
>   Additional-path-install
>   Not advertised to any peer
>   Refresh Epoch 1
>   Local
>     10.123.129.1 (metric 10) from 10.123.129.1 (10.123.129.1)
>       Origin IGP, metric 0, localpref 100, valid, internal, best
>       Community: 17492:1100 17492:40129 17492:62911
>       Originator: 10.122.129.255, Cluster list: 10.123.129.1
>       mpls labels in/out nolabel/16013
>       rx pathid: 0, tx pathid: 0x0
>
> That can be traced back to the P1/RR setup, that can see both paths to
> PE1 (direct and via P2):
>
> #sh bgp ipv4 u 10.122.129.255
> Fri Aug 23 10:06:47.813 NZST
> BGP routing table entry for 10.122.129.255/32
> Versions:
>   Process           bRIB/RIB  SendTblVer
>   Speaker                 66          66
>     Local Label: 16013
> Last Modified: Aug 23 09:46:28.961 for 00:20:18
> Paths: (2 available, best #1)
>   Advertised to peers (in unique update groups):
>     10.123.129.3    10.123.129.2
>   Path #1: Received by speaker 0
>   Advertised to peers (in unique update groups):
>     10.123.129.3    10.123.129.2
>   Local, (Received from a RR-client)
>     10.122.129.255 (metric 2) from 10.122.129.255 (10.122.129.255)
>       Received Label 3
>       Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
>       Received Path ID 0, Local Path ID 1, version 66
>       Community: 17492:1100 17492:40129 17492:62911
>   Path #2: Received by speaker 0
>   Not advertised to any peer
>   Local, (Received from a RR-client)
>     10.123.129.3 (metric 10) from 10.123.129.3 (10.122.129.255)
>       Received Label 40
>       Origin IGP, metric 0, localpref 100, valid, internal, backup, add-path
>       Received Path ID 0, Local Path ID 2, version 66
>       Community: 17492:1100 17492:40129 17492:62911
>       Originator: 10.122.129.255, Cluster list: 10.123.129.3
>
> The second path is seen as the 'backup' correctly, but doesn't get
> advertised to anyone.
>
> The BGP setup on P1/RR looks like this:
>
> router bgp 17492
>  nsr
>  bgp router-id 10.123.129.1
>  bgp graceful-restart
>  ibgp policy out enforce-modifications
>  address-family ipv4 unicast
>   additional-paths receive
>   additional-paths send
>   additional-paths selection route-policy RP-ADDITIONAL-PATH-TO-BGP
>   network 10.123.129.1/32 route-policy RP-LOOPBACK-TO-BGP
>   allocate-label all
>
>  neighbor-group VC-RR
>   remote-as 17492
>   dscp cs6
>   password encrypted 01050549590C16
>   update-source Loopback0
>   address-family ipv4 labeled-unicast
>    route-policy RP-BGP-ADJUST-NHOP out
>   !
>   address-family vpnv4 unicast
>   !
>   address-family vpnv6 unicast
>   !
>   address-family l2vpn vpls-vpws
>   !
>
>  neighbor-group VC-RR-CLIENT
>   use neighbor-group VC-RR
>   address-family ipv4 labeled-unicast
>    route-reflector-client
>   !
>   address-family vpnv4 unicast
>    route-reflector-client
>   !
>   address-family vpnv6 unicast
>    route-reflector-client
>   !
>   address-family l2vpn vpls-vpws
>    route-reflector-client
>
> neighbor-group VC-ACCESS
>   remote-as 17492
>   dscp cs6
>   password encrypted 01050549590C16
>   update-source Loopback10
>   address-family ipv4 labeled-unicast
>    route-reflector-client
>    next-hop-self
>   !
>   address-family vpnv4 unicast
>    route-reflector-client
>   !
>   address-family vpnv6 unicast
>    route-reflector-client
>   !
>   address-family l2vpn vpls-vpws
>    route-reflector-client
>   !
>  !
>  neighbor 10.122.129.255
>   use neighbor-group VC-ACCESS
>   description PE1
>  !
>  neighbor 10.123.129.2
>   use neighbor-group VC-RR-CLIENT
>   description PE2
>
> route-policy RP-ADDITIONAL-PATH-TO-BGP
>   set path-selection backup 1 advertise install
> end-policy
>
> So how should I setup the ASR9k to advertise the backup paths to all
> it's clients?
> I found this presentation (h
> ttp://www.cisco.com/web/SK/expo2012/pdf/advanced_routing_resilliency_josef_ungerman_cisco.pdf
> ) that mentions that 'solution C' - add path (page 48) is available in
> XR 4, but the config presented only shows IOS setup. I tried to
> tab-through the options on the 9k, but there doesn't seem to be
> anything there on the neighbour level.
>
> kind regards
> Pshem