Inter-AS MPLS L3VPN – Option C Interop – IOS-XE, IOS, Junos

I initially wanted to test option C between IOS, Junos, and Brocade Netiron, but the Netiron doesn’t support option B or C

Cisco has released the csr1000v ios-xe router that runs in vmware. So what better way to test that little router with an inter-op blog?

The Junos and IOS-XE boxes will be the router reflectors. In this scenario they are nowhere in the data path. They are simply doing control-plane duties.

This inter-op is a bit of a cheat. IOS-XE is nearly identical to IOS. I do not have readily available access to IOS-XR so can’t easy attach that to my Junos lab.

Most of the config is listed from my regular option C post over here. I’ve removed the route-reflector config off of R12 and R8.

IOS-XE config

This is the version of IOS-XE I’m using:

IOS-XE-RR#sh ver | include IOS
Cisco IOS Software, IOS-XE Software (X86_64_LINUX_IOSD-ADVENTERPRISEK9-M), Version 15.3(2)S0a
IOS XE Version: 03.09.00a.S
Cisco IOS-XE software, Copyright (c) 2005-2013 by cisco Systems, Inc.

Let’s start off with the usual IGP config:

interface Loopback0
 ip address 30.30.30.30 255.255.255.255
 ip router isis
!
interface GigabitEthernet1
 ip address 10.0.0.30 255.255.255.0
 ip router isis
!
router isis
 net 49.0000.0000.0030.00
 is-type level-2-only
 metric-style wide

Now we need to set up our BGP sessions. As the previous post showed, I need to ensure the next-hop remains unchanged when advertising off to the Juniper. I also need to rewrite the RT values inbound:

ip extcommunity-list standard 200:1 permit rt 200:1
ip extcommunity-list standard 200:2 permit rt 200:2
!
route-map CHANGE_COMMUNITY permit 10
 match extcommunity 200:1
 set extcommunity rt 100:1
!
route-map CHANGE_COMMUNITY permit 20
 match extcommunity 200:2
 set extcommunity rt 100:2
!
router bgp 100
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 12.12.12.12 remote-as 100
 neighbor 12.12.12.12 update-source Loopback0
 neighbor 20.20.20.20 remote-as 200
 neighbor 20.20.20.20 ebgp-multihop 255
 neighbor 20.20.20.20 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
  neighbor 2.2.2.2 route-reflector-client
  neighbor 12.12.12.12 activate
  neighbor 12.12.12.12 send-community extended
  neighbor 12.12.12.12 route-reflector-client
  neighbor 20.20.20.20 activate
  neighbor 20.20.20.20 send-community extended
  neighbor 20.20.20.20 next-hop-unchanged
  neighbor 20.20.20.20 route-map CHANGE_COMMUNITY in
 exit-address-family

Junos config

With Junos we are doing the same thing, the config just looks very different of course. I’ve configured regular OSPF and LDP a number of times so I won’t post it here again. As before, I need to be able to rewrite the RT values inbound so let’s create a policy to do so:

policy-options {
    policy-statement CHANGE_COMMUNITY {
        term 1 {
            from community 100:1;
            then {
                community set 200:1;
            }
        }
        term 2 {
            from community 100:2;
            then {
                community set 200:2;
            }
        }
    }
    community 100:1 members target:100:1;
    community 100:2 members target:100:2;
    community 200:1 members target:200:1;
    community 200:2 members target:200:2;
}

This will be applied inbound on our eBGP session. One thing to note under Junos is that usually you change attributes through a routing-policy. If I want to ensure the next-hop doesn’t change it goes under multihop – no-nexthop-change. A bit odd but that’s the way it is. This is my BGP config:

USERJR1:JR1> show configuration protocols bgp
group VPNv4_EXTERNAL {
    multihop {
        no-nexthop-change;
    }
    local-address 20.20.20.20;
    import CHANGE_COMMUNITY;
    family inet-vpn {
        unicast;
    }
    peer-as 100;
    neighbor 30.30.30.30 {
        multihop;
    }
}
group VPNv4_INTERNAL {
    local-address 20.20.20.20;
    family inet-vpn {
        unicast;
    }
    cluster 20.20.20.20;
    peer-as 200;
    neighbor 8.8.8.8;
    neighbor 9.9.9.9;
}

Verification

At this point, our BGP updates are going like so:

I’ve added the new loopbacks to my ASBRs route-map on R13, R15, R5, and R6. Let’s ensure our BGP sessions are up:

IOS-XE-RR#  show bgp vpnv4 un all summary | beg Neigh
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4          100      38      42        9    0    0 00:30:11        2
12.12.12.12     4          100      38      43        9    0    0 00:30:09        2
20.20.20.20     4          200      71      72        9    0    0 00:30:04        4
USERJR1:JR1> show bgp summary
Groups: 2 Peers: 3 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 0          0          0          0          0          0
bgp.l3vpn.0            8          8          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active
8.8.8.8                 200         94         99       0       4       42:21 Establ
  bgp.l3vpn.0: 2/2/2/0
9.9.9.9                 200        194        206       0       4       42:24 Establ
  bgp.l3vpn.0: 2/2/2/0
30.30.30.30             100         72         71       0       4       30:20 Establ
  bgp.l3vpn.0: 4/4/4/0

Let’s drill down a bit deeper. 11.11.11.11/32 should be on the XE router with an RT value of 100:1 – Is that what we see?

IOS-XE-RR#show bgp vpnv4 unicast rd 8.8.8.8:1   11.11.11.11
BGP routing table entry for 8.8.8.8:1:11.11.11.11/32, version 5
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  200
    8.8.8.8 (metric 20) from 20.20.20.20 (20.20.20.20)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.118.8:0
      mpls labels in/out nolabel/27
      rx pathid: 0, tx pathid: 0x0

We do see that. Notice too that the next-hop is set to the PE address of 8.8.8.8. This is what we want.

From the Junos side we should see 1.1.1.1/32 coming in with an RT value of 200:1:

USERJR1:JR1> show route table bgp.l3vpn.0 rd-prefix 2.2.2.2:1:1.1.1.1 detail

bgp.l3vpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
2.2.2.2:1:1.1.1.1/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 2.2.2.2:1
                Next hop type: Indirect
                Address: 0x8fadd00
                Next-hop reference count: 1
                Source: 30.30.30.30
                Protocol next hop: 2.2.2.2
                Push 27
                Indirect next hop: 2 no-forward
                State: 
                Local AS:   200 Peer AS:   100
                Age: 33:40      Metric2: 1
                Task: BGP_100.30.30.30.30+18533
                Announcement bits (1): 0-BGP RT Background
                AS path: 100 ?
                Communities: target:200:1
                Accepted
                VPN Label: 27
                Localpref: 100
                Router ID: 30.30.30.30

That’s exactly what we see. Notice again that the protocol next-hop is set to R2’s address.

So this should mean that not only can R1 get to R11, but it also goes the optimal path:

R1#traceroute 11.11.11.11 so lo0

Type escape sequence to abort.
Tracing the route to 11.11.11.11

  1 10.0.12.2 12 msec 12 msec 4 msec
  2 10.0.23.3 [MPLS: Labels 23/29/27 Exp 0] 32 msec 52 msec 40 msec
  3 10.0.33.13 [MPLS: Labels 29/27 Exp 0] 44 msec 52 msec 8 msec
  4 10.13.14.14 [MPLS: Labels 24/27 Exp 0] 32 msec 32 msec 60 msec
  5 10.0.146.6 [MPLS: Labels 26/27 Exp 0] 24 msec 52 msec 24 msec
  6 10.0.118.8 [MPLS: Label 27 Exp 0] 32 msec 32 msec 28 msec
  7 10.0.118.11 60 msec *  24 msec

Let’s be 100% sure the reverse path is also the optimal path:

R11#traceroute 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

  1 10.0.118.8 8 msec 12 msec 4 msec
  2 10.0.68.6 [MPLS: Labels 28/27 Exp 0] 44 msec 48 msec 24 msec
  3 10.0.146.14 [MPLS: Labels 29/27 Exp 0] 12 msec 60 msec 44 msec
  4 10.13.14.13 [MPLS: Labels 22/27 Exp 0] 48 msec 40 msec 48 msec
  5 10.0.33.3 [MPLS: Labels 26/27 Exp 0] 48 msec 40 msec 8 msec
  6 10.0.12.2 [MPLS: Label 27 Exp 0] 40 msec 12 msec 28 msec
  7 10.0.12.1 56 msec *  20 msec

I’d like to add a few more things to this particular lab, but I’ll leave that for another day.

© 2009-2019 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright