CCIE SPv4 - MPLS - MPLS Authentication

Software versions:
IOS XE 15.5
IOS XR 5.3

Our topology for this demo:

This post will focus on the authentication capabilities of MPLS using the various options available. We'll first look at the neighbor specific configuration and move on from there. IOS supports several methods, IOS XR seems limited to only the neighbor option here. You'll notice that if there is an existing TCP connection between 2 LSRs, that MD5 authentication won't have an effect. It only is effected during the initial peering.

IOS
configure terminal
 mpls ldp neighbor 192.168.1.11 password LDP

%TCP-6-BADAUTH: No MD5 digest from 192.168.1.11(31640) to 192.168.1.1(646) tableid - 0
This syslog message indicates that XR1 (192.168.1.11) did not send an MD5 digest, tableid-0 indicates this is the global routing table

XR
mpls ldp
 neighbor
  192.168.1.1:0 password encrypted 00283736




I used the same password "LDP" on both ends but IOS XR auto encrypts in the XRv.
%LDP-5-NBRCHG: LDP Neighbor 192.168.1.11:0 (3) is UP
The neighbor is now up!

Verification time:
You'll notice that the "neighbor" is bolded, check below XR1s peer for XR2s and you see "none" is bolded. R1 and XR1 are running neighbor authentication, R1 and XR2 are not.
R1#sho mpls ldp neighbor password current
Peer LDP Ident: 192.168.1.11:0; Local LDP Ident 192.168.1.1:0
        TCP connection: 192.168.1.11.56350 - 192.168.1.1.646
        Password: not required, neighbor, in use
        State: Oper; Msgs sent/rcvd: 33/33
Peer LDP Ident: 192.168.1.12:0; Local LDP Ident 192.168.1.1:0
        TCP connection: 192.168.1.12.38288 - 192.168.1.1.646
        Password: not required, none, in use
        State: Oper; Msgs sent/rcvd: 1280/1279

Next we'll take a look at authentication globally. It doesn't appear that IOS XR supports anything authentication wise for LDP passed neighbor. So we'll just focus on IOS from here out on this post.

There are multiple capabilities available for LDP authentication globally on IOS.

ldp: MD5 protection is required for peer 192.168.1.4:0(default), but no password is configured.

There are 4 specific options that LDP can use globally, they are "fallback", "option", "required" and "rollover"

Fallback is "self-explanatory" meaning that if you don't have more specific authentication enabled, you can use the fallback password, this can be used to authenticate with IOS XR where XR uses the neighbor password. This option can also leverage a key chain for multiple keys.

Option lets you specify the sequence in which ACLs are referenced to determine whether a peer LSR referenced in the ACL should be permitted to form an adjacency with the local LSR. In the peer LSR is not permitted, sequence processing continues to the next sequence referenced by the option keyword. Processing continues until a match occurs, if there is no match, the fallback password is used, if no fallback password is configured then MD5 is not used.

Required means that LDP must use a password leveraging MD5. If a password is not configured then LDP tears down the session.

Rollover determines how long a password can be considered valid during a password change. This is typically leveraged when using rotating keys in a key chain when the lifetime values overlap.


We'll start with the fallback password, we'll configure this on R3 and R4, XR doesn't support this, but we can use the password used for fallback on IOS for XRs neighbor password.

IOS
mpls ldp password fallback LDP
IOS by default will not encrypt clear text passwords unless service password-encryption is enabled.

R3#sh run | sec mpls|service password-encryption
service password-encryption
mpls ldp password fallback 7 080D687E

R3#sh mpls ldp discovery detail
GigabitEthernet1.34 (ldp): xmit/recv
            Enabled: IGP config;
            Hello interval: 5000 ms; Transport IP addr: 192.168.1.3
            LDP Id: 192.168.1.4:0
              Src IP addr: 10.3.4.4; Transport IP addr: 192.168.1.4
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Reachable via 192.168.1.4/32
              Password: not required, fallback, in use
            Clients: IPv4, mLDP

RP/0/0/CPU0:XR4#sh mpls ldp neighbor g0/0/0/0.143 detail
Peer LDP Identifier: 192.168.1.3:0
  TCP connection: 192.168.1.3:646 - 192.168.1.14:45316; MD5 on

XR
mpls ldp
 neighbor

  192.168.1.3:0 password encrypted 09606A39
XR by default will encrypt any clear text passwords.


Now on to the options capability, for now we will leave the fallback password on, but later we will disable that and see the difference.

For the option capability, we will show a deny and then show a permit and see how R3 handles that.
First lets create standard ACLs that first deny and second permit R4s loopback address.

ip access-list standard R4_DENY
 deny   192.168.1.4
ip access-list standard R4_PERMIT
 permit 192.168.1.4

Next we will configure MPLS authentication to use the option capability with 2 sequence numbers, 1 to match the R4_DENY ACLand 2 to match the R4_PERMIT ACL.

mpls ldp password option 1 for R4_DENY 7 153E2F3C
mpls ldp password option 2 for R4_PERMIT 7 022A206B

R3#sh mpls ldp discovery all detail
GigabitEthernet1.34 (ldp): xmit/recv
            Enabled: IGP config;
            Hello interval: 5000 ms; Transport IP addr: 192.168.1.3
            LDP Id: 192.168.1.4:0
              Src IP addr: 10.3.4.4; Transport IP addr: 192.168.1.4
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Reachable via 192.168.1.4/32
              Password: not required, option 2, in use
            Clients: IPv4, mLDP

As you can see, LDP chose option 2 since it permitted the source of R4's loopback. We can also check the ACLs to see what sequences received hits.

R3#show ip access-lists
Standard IP access list R4_DENY
    10 deny   192.168.1.4 (2 matches)
Standard IP access list R4_PERMIT
    10 permit 192.168.1.4 (2 matches)

Lets disbale the fallback password on both R3 and R4. Currently R4 is has only been using the fallback password this entire time.

R3(config)#no mpls ldp password fallback 7 080D687E
R4(config)#no mpls ldp password fallback
R4#
*Nov 19 14:34:17.889: %LDP-5-PWDCFG: Password configuration changed for 192.168.1.3:0
By default there is password logging done by LDP.

Let's flap the G1.34 link between R3 and R4
interface g1.34
shut
no shut - do this after you see the console show the interface down.

R3#
ldp: 192.168.1.4:0 MD5 setup: pwd Rx1/Rx2/Tx/fl is [defined]/[defined]/[defined]/5
%TCP-6-BADAUTH: No MD5 digest from 192.168.1.4(26121) to 192.168.1.3(646) tableid - 0

As you can see, no password is on R4, so the LDP session simple doesn't come up.

Let's look at required now, which will force us to fix the above issue.
IOS
mpls ldp password required


R4#
 %LDP-4-PWD: MD5 protection is required for peer 192.168.1.3:0, no password configured

R4 doesn't have a password configured. We'll go ahead and set him up with one.

R4(config)#mpls ldp password fallback LDP

R3#sh mpls ldp discovery all detail
GigabitEthernet1.34 (ldp): xmit/recv
            Enabled: IGP config;
            Hello interval: 5000 ms; Transport IP addr: 192.168.1.3
            LDP Id: 192.168.1.4:0
              Src IP addr: 10.3.4.4; Transport IP addr: 192.168.1.4
              Hold time: 15 sec; Proposed local/peer: 15/15 sec
              Reachable via 192.168.1.4/32
              Password: required, option 2, in use

An issue occured on R3 when being specific with the password option, we were only permitting R4's loopback through, XR4 was getting dropped due to the ACL being specific to only R4. We can either change the ACL to add XR4 or add a separate neighbor statement for XR4. The latter is what I chose to do.

R3#
ldp: guess MD5 key for TCP connection 192.168.1.3:646 - 192.168.1.14:24862; password is [nil]

R3(config)#mpls ldp neighbor 192.168.1.14 password 7 11253D35

%LDP-5-NBRCHG: LDP Neighbor 192.168.1.14:0 (2) is UP

R3#sh mpls ldp discovery all detail

Notice below that a password is required but how it is configured is different.

GigabitEthernet1.143

Password: required, neighbor, in use

GigabitEthernet1.34

Password: required, option 2, in use

A bit deeper verification is the TCP database that shows the active connections from R3 to XR4 and R4

R3#show tcp brief

TCB       Local Address               Foreign Address             (state)

7F9512BBC628  192.168.1.3.646            192.168.1.14.33493          ESTAB

7F9513CEF250  192.168.1.3.646            192.168.1.4.23890           ESTAB

Now lets expand this out and see a bit more info.

R3#show tcp tcb 7F9513CEF250 | in MD5

  MD5 lossless password switchover, Retrans timeout

The “lossless password switchover” feature is enabled, meaning that we can apply a key-chain with time constraints for automatic rollover.

Get what we will take a look at now..... you guessed it, auto key rollover with key chains and also look at the rollover option.

IOS XRv does not support key chain authentication for LDP, so we will focus on just IOS now.

We will configure both fallback and option to use the key chain, but we'll only configure 1 set of key chains, 2 keys in it and test with option first then fall back. Option needs to call an ACL to match a source and then authenticate with the key chain, fallback just calls the key-chain and that's it. 

IOS - Configured on both R3 and R4

key chain LDP_AUTH

 key 1

   key-string LDP

   accept-lifetime 16:00:00 Nov 19 2016 16:05:00 Nov 19 2016

   send-lifetime 16:00:00 Nov 19 2016 16:05:00 Nov 19 2016

   cryptographic-algorithm md5

 key 2

   key-string LDP_2

   accept-lifetime 16:05:00 Nov 19 2016 infinite

   send-lifetime 16:05:00 Nov 19 2016 infinite

   cryptographic-algorithm md5

Created an ACL on both to permit the local loopback

R3

ip access-list standard R4_DENY

 deny   192.168.1.4

ip access-list standard R4_PERMIT

 permit 192.168.1.4

R4

ip access-list standard R3_PERMIT

 permit 192.168.1.3

R3 

mpls ldp password rollover duration 1

mpls ldp password option 2 for R4_PERMIT key-chain LDP_AUTH

R4

mpls ldp password rollover duration 1

mpls ldp password option 1 for R3_PERMIT key-chain LDP_AUTH

So now the configuration is setup like this, R3 is using the option 2 to check the ACL R4_PERMIT to check whether R4's loopback is permitted, it is so then the key chain is check to make sure that the appropriate time, key # and key string all match, R4 does the same exact thing. 

Now all we have to do is set the clock to the appropriate time, 1 minute before 4 PM.

clock set 15:59:00 Nov 19 2016

 %SYS-6-CLOCKUPDATE: System clock has been updated from 16:14:59 UTC Sat Nov 19 2016 to 15:59:00 UTC Sat Nov 19 2016

You will see a landslide of console messages since we are logging debugs to the console. So beware!

Nov 19 15:59:55.154: ldp: Opening listen port 646 for 192.168.1.4 (for hellos from 10.3.4.4)

Nov 19 15:59:55.154: ldp: MD5 protection is required for peer 192.168.1.4:0(default), but no password is configured.

Nov 19 16:00:04.566:  Key chain LDP_AUTH; Res Tx/Rx 2/2; Xmit pwd: [defined], Recv pwd1/pwd2: [defined]/[nil]

Nov 19 16:00:08.405: ldp: Opening listen port 646 for 192.168.1.4 (for hellos from 10.3.4.4)

Nov 19 16:00:08.405: ldp: 192.168.1.4:0 MD5 setup: pwd Rx1/Rx2/Tx/fl is [defined]/[defined]/[defined]/5

As you can see there is obviously activity and the key chain, mpls ldp authentication and ACL are sync'ed to allow the traffic

Nov 19 16:00:43.321: %LDP-5-NBRCHG: LDP Neighbor 192.168.1.4:0 (1) is UP

It took 43 seconds to see the neighbor actually come up. Lets check the ACL, key chain and LDP discovery.

R3#show access-lists

Standard IP access list R4_DENY

    10 deny   192.168.1.4 (31 matches)

Standard IP access list R4_PERMIT

    10 permit 192.168.1.4 (31 matches)

R3#sh key chain

Key-chain LDP_AUTH:

    key 1 -- text "LDP"

        accept lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016) [valid now]

        send lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016) [valid now]

    key 2 -- text "LDP_2"

        accept lifetime (16:05:00 UTC Nov 19 2016) - (infinite)

        send lifetime (16:05:00 UTC Nov 19 2016) - (infinite)

R3#show mpls ldp neighbor password current

    Peer LDP Ident: 192.168.1.4:0; Local LDP Ident 192.168.1.3:0

        TCP connection: 192.168.1.4.46772 - 192.168.1.3.646

        Password: required, option 2 (LDP_AUTH), in use

        State: Oper; Msgs sent/rcvd: 37/36

Now it's been 5 minutes.

R3#sh clock

16:05:00.388 UTC Sat Nov 19 2016

R3#sh key chain

Key-chain LDP_AUTH:

    key 1 -- text "LDP"

        accept lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016)

        send lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016)

    key 2 -- text "LDP_2"

        accept lifetime (16:05:00 UTC Nov 19 2016) - (infinite) [valid now]

        send lifetime (16:05:00 UTC Nov 19 2016) - (infinite) [valid now]

R3#show mpls ldp neighbor password current

    Peer LDP Ident: 192.168.1.4:0; Local LDP Ident 192.168.1.3:0

        TCP connection: 192.168.1.4.46772 - 192.168.1.3.646

        Password: required, option 2 (LDP_AUTH), in use

        State: Oper; Msgs sent/rcvd: 38/37

Nov 19 16:05:28.393:  Key chain LDP_AUTH; Res Tx/Rx 2/2; Xmit pwd: [defined], Recv pwd1/pwd2: [defined]/[nil]

Nov 19 16:05:28.393: %LDP-5-PWDCFG: Password configuration changed for 192.168.1.4:0

So last but finally not least, configuring fallback to use a keychain. 

R3 and R4

mpls ldp password fallback key-chain LDP_AUTH

I also deleted the option capabilities. This ensures that I use the fallback option now. Lets verify it.

R3#sh mpls ldp neighbor password current

    Peer LDP Ident: 192.168.1.4:0; Local LDP Ident 192.168.1.3:0

        TCP connection: 192.168.1.4.29522 - 192.168.1.3.646

        Password: required, fallback, in use

        State: Oper; Msgs sent/rcvd: 33/32

R3#show key chain

Key-chain LDP_AUTH:

    key 1 -- text "LDP"

        accept lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016)

        send lifetime (16:00:00 UTC Nov 19 2016) - (16:05:00 UTC Nov 19 2016)

    key 2 -- text "LDP_2"

        accept lifetime (16:05:00 UTC Nov 19 2016) - (infinite) [valid now]

        send lifetime (16:05:00 UTC Nov 19 2016) - (infinite) [valid now]

As you can see, just authentication alone can be pretty involved. It really boils down to knowing what each sub-feature does and how to implement them. As we progress into other LDP features, leveraging ACLs to filter traffic will be repeated. 

Thanks for stopping by!

Rob Riker, CCIE #50693

CCIE SPv4 - MPLS - MPLS Timers

Software versions:
IOS XE Version 15.5
IOS XR Version 5.3.0

In this post we will take our existing MPLS rollout from the previous post, I went ahead and enabled MPLS on every router in the AS. We will focus on the different timers that MPLS uses for operations. It goes without saying this will be on both IOS and XR, but for clarity, it will. 

MPLS uses hello and hold down timers like the IGPs do, by default it's 5 seconds for hellos and 15 seconds for hold down by default. There is also a proposed local/peer timer 15/15 this can be manipulated as well. 

The topology we will use:

We will continue to look at R1 and XR1, for now anyways. First lets look at the default values and manipulate them from there.

R1

R1#sh mpls ldp discovery detail

 Local LDP Identifier:

    192.168.1.1:0

    Discovery Sources:

    Interfaces:

        GigabitEthernet1.111 (ldp): xmit/recv

            Enabled: Interface config, IGP config;

            Hello interval: 5000 ms; Transport IP addr: 192.168.1.1

            LDP Id: 192.168.1.11:0

              Src IP addr: 10.1.11.11; Transport IP addr: 192.168.1.11

              Hold time: 15 sec; Proposed local/peer: 15/15 sec

              Reachable via 192.168.1.11/32

              Password: not required, none, in use

            Clients: IPv4, mLDP

XR1

RP/0/0/CPU0:XR1#sh mpls ldp discovery detail

Thu Nov 17 23:46:32.793 UTC

Local LDP Identifier: 192.168.1.11:0

Discovery Sources:

  Interfaces:

    GigabitEthernet0/0/0/0.111 (0x800) : xmit/recv

      VRF: 'default' (0x60000000)

      Source address: 10.1.11.11; Transport address: 192.168.1.11

      Hello interval: 5 sec (due in 2.9 sec)

      Quick-start: Enabled

      LDP Id: 192.168.1.1:0

          Source address: 10.1.11.1; Transport address: 192.168.1.1

          Hold time: 15 sec (local:15 sec, peer:15 sec)

                     (expiring in 14.2 sec)

As you can see in bold highlight that the hello is actually in milliseconds at 5000ms and the hold time is listed in seconds at 15. Proposed local/peer is 15/15.

IOS XR gives you the output of how much time is left, closer to what IGP advertises like OSPFv2. 

Let's go ahead on both IOS and XR, reduce the hello and hold time by 3 seconds each and see the output.

IOS

mpls ldp discovery hello interval 3

mpls ldp discovery hello holdtime 12

XR

mpls ldp

 discovery

  hello holdtime 12

  hello interval 3

The verification for the change:

R1#show mpls ldp discovery detail

 Local LDP Identifier:

    192.168.1.1:0

    Discovery Sources:

    Interfaces:

        GigabitEthernet1.111 (ldp): xmit/recv

            Enabled: Interface config, IGP config;

            Hello interval: 3000 ms; Transport IP addr: 192.168.1.1

            LDP Id: 192.168.1.11:0

              Src IP addr: 10.1.11.11; Transport IP addr: 192.168.1.11

              Hold time: 12 sec; Proposed local/peer: 12/12 sec

              Reachable via 192.168.1.11/32

              Password: not required, none, in use

            Clients: IPv4, mLDP

RP/0/0/CPU0:XR1#sh mpls ldp discovery detail

Thu Nov 17 23:50:15.598 UTC

Local LDP Identifier: 192.168.1.11:0

Discovery Sources:

  Interfaces:

    GigabitEthernet0/0/0/0.111 (0x800) : xmit/recv

      VRF: 'default' (0x60000000)

      Source address: 10.1.11.11; Transport address: 192.168.1.11

      Hello interval: 3 sec (due in 1.4 sec)

      Quick-start: Enabled

      LDP Id: 192.168.1.1:0

          Source address: 10.1.11.1; Transport address: 192.168.1.1

          Hold time: 12 sec (local:12 sec, peer:12 sec)

                     (expiring in 11.2 sec)

Now let's go back and remove the modification to XR1.

XR

RP/0/0/CPU0:XR1#sh mpls ldp discovery detail

Thu Nov 17 23:51:48.131 UTC

Local LDP Identifier: 192.168.1.11:0

Discovery Sources:

  Interfaces:

    GigabitEthernet0/0/0/0.111 (0x800) : xmit/recv

      VRF: 'default' (0x60000000)

      Source address: 10.1.11.11; Transport address: 192.168.1.11

      Hello interval: 4 sec (due in 2.6 sec)

      Quick-start: Enabled

      LDP Id: 192.168.1.1:0

          Source address: 10.1.11.1; Transport address: 192.168.1.1

          Hold time: 12 sec (local:15 sec, peer:12 sec)

                     (expiring in 11 sec)

What ends up happening here is that the routers will always agree on the discovery hold time, XR1s hello interval changed automatically, but we didn't make that change. The LDP discovery hello interval must be at least 3 times as often as the hold time. XR1 had to reduce its hold time to 12 to accommodate this. The original 5 second hello was too slow.

There is also a globally configured holdtime. This is set to 60 seconds as a keepalive timer and 180 second holdtime. 

R1

R1#show mpls ldp neighbor 192.168.1.11 detail | in time

        Up time: 1d00h; UID: 20; Peer Id 0

            holdtime: 12000 ms, hello interval: 3000 ms

        Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab

On XR1, we'll configure this to be faster, 120 second peer hold time. 

mpls ldp

 session holdtime 120

Problem with this configuration is the session is already established and needs to be flapped to use the new values

RP/0/0/CPU0:XR1#show mpls ldp neighbor 192.168.1.1 detail | in time

Fri Nov 18 00:04:51.878 UTC

  Session Holdtime: 120 sec

  Up time: 00:00:11

  Peer holdtime: 180 sec; KA interval: 40 sec; Peer state: Estab

Notice that only the session holdtime and KA interval timers changed. 

Also notice that R1s timers change.

R1#show mpls ldp neighbor 192.168.1.11 detail | in time

        Up time: 00:04:17; UID: 26; Peer Id 3

            holdtime: 12000 ms, hello interval: 3000 ms

        Peer holdtime: 120000 ms; KA interval: 40000 ms; Peer state: estab

There is one more timer that we can take a look at. The backoff timer, think of this as a way for MPLS to prevent another LSR from constantly being signaled to peer. You may have an LSR that has an older version of code that or other configured values that won't be compatible with the local LSR. This prevents a constant peering session from being initiated. By default these values are 15 and 120, the initial backoff timer is 15 seconds, the initial failure and the longest timer is 120 seconds.

IOS

R1(config)#mpls ldp backoff 5 60

XR

mpls ldp

 session backoff 5 60

R1#show mpls ldp backoff all

LDP initial/maximum backoff: 5/60 sec

RP/0/0/CPU0:XR1#show mpls ldp backoff

  Backoff Time:

    Initial:5 sec, Maximum:60 sec

  Backoff Table:

    No Entry

Thanks for stopping by!

Rob Riker, CCIE #50693

CCIE SPv4 - MPLS - Enabling MPLS

Software versions:
IOS XE Version 15.5
IOS XR Version 5.3.0

We'll take a look at enabling MPLS on IOS and XR with OSPF as the IGP. We'll enable it with the interface and auto-configuration capability. We also will look at disabling the auto-configuration capability where it may not be needed. We will take a look at 2 different debugs, transport events and ldp advertisements. We'll see the session form and then LDP labels distributed.

The topology for this section:

Our first 2 victims here are R1 and XR1. Both IOS and IOS XR support the interface and auto-configuration feature. One thing to note, the loopbacks of the LSRs here don't have MPLS enabled on them, but are used, if the LSR is a PE device, the loopback is used to terminate an LSP. 

First the interface level configuration:

IOS

interface GigabitEthernet1.111

 mpls ip

XR

mpls ldp

 interface GigabitEthernet0/0/0/0.111

Next the auto-configuration:

IOS

router ospf 1

 network 0.0.0.0 255.255.255.255 area 0

 mpls ldp autoconfig area 0

Note: The "area 0" arguement is an add on to be specific in the inter-area rollouts later. Without the "area' configuration, auto-config is enabled whereever IGP is enabled.

XR

router ospf 1

 area 0

  mpls ldp auto-config

Note: The auto-config capability alone will not enable MPLS, mpls ldp globally still has to be configured and enabled.

XR

mpls ldp

Auto-configuration can be disabled at the interface level on IOS and XR as well.

IOS

interface GigabitEthernet1.111

 no mpls ldp igp autoconfig

XR

mpls ldp

 interface GigabitEthernet0/0/0/0.111

  address-family ipv4

   auto-config disable

Verification time

Lets verify the interfaces are enabled for MPLS, notice that the interface is enabled for only LDP, not tunneling, BGP or static labels, all discussed later.

R1#show mpls interfaces

Interface                       IP                Tunnel   BGP Static Operational

GigabitEthernet1.111   Yes (ldp)     No         No    No     Yes

RP/0/0/CPU0:XR1#show mpls interfaces

Wed Nov 16 22:53:43.389 UTC

Interface                               LDP     Tunnel   Static   Enabled

--------------------------          --------   --------   -------- --------

GigabitEthernet0/0/0/0.111 Yes        No         No       Yes

Lets take a look at the ldp discovery on XR1 to R1.
Xmit/Recv indicates the interfaces is sending and receiving data.
VRF Default means the global routing table.
The LDP ID and Transport address are both the loopback address.
The holdtime, both local and peer are 15 sec. which is the default.

RP/0/0/CPU0:XR1#show mpls ldp discovery gigabitEthernet 0/0/0/0.111

Wed Nov 16 22:54:47.575 UTC

Local LDP Identifier: 192.168.1.11:0

Discovery Source:

    GigabitEthernet0/0/0/0.111 : xmit/recv

      VRF: 'default' (0x60000000)

      LDP Id: 192.168.1.1:0, Transport address: 192.168.1.1

          Hold time: 15 sec (local:15 sec, peer:15 sec)

Lets see what R1 is advertising to us.
GR is not enabled currently, the session holdtme this is negotiated, defaults to 180 seconds.
Downstream-Unsolicited indicates that label bindings for all IGP routes are distributed to all neighbors without being asked for them.
LDP Discovery Sources indicates that currently only IPv4 peerings are up.
Address bound to this peer shows the directly connected /32 interface addresses that R1 is advertising to XR1.

RP/0/0/CPU0:XR1#show mpls ldp neighbor

Wed Nov 16 22:56:50.116 UTC

Peer LDP Identifier: 192.168.1.1:0

  TCP connection: 192.168.1.1:646 - 192.168.1.11:37146

  Graceful Restart: No

  Session Holdtime: 180 sec

  State: Oper; Msgs sent/rcvd: 58/58; Downstream-Unsolicited

  Up time: 00:22:52

  LDP Discovery Sources:

    IPv4: (1)

      GigabitEthernet0/0/0/0.111

    IPv6: (0)

  Addresses bound to this peer:

    IPv4: (4)

      10.1.11.1      10.1.12.1      10.1.15.1      192.168.1.1

    IPv6: (0)

Lets debug the LDP adjacency

debug mpls ldp transport events interface g1.111

LDP enabled on G1.111

ldp: enabling ldp on GigabitEthernet1.111

LDP hello sent out G1.111 with src of 10.1.11.1 dst of 224.0.0.2 or (S, G)

ldp: Send ldp hello; GigabitEthernet1.111, src/dst 10.1.11.1/224.0.0.2, inst_id 0

LDP Hello received in on G1.111 from XR1

ldp: Rcvd ldp hello; GigabitEthernet1.111, from 10.1.11.11 (192.168.1.11:0), intf_id 0, opt 0xC

Local TCP DB session is added to TCB for the new LDP session

ldp: Opening listen port 646 for 192.168.1.11

The initial hello connectivity is successful via UDP from the directly connected adjacency. Now the TCP connection between R1 and XR1 via their loopbacks has to form

ldp: Incoming {ldp conn 192.168.1.1:646=>192.168.1.11:46784} with normal priority

R1 is the server and XR1 is the client here, based on their port numbers 646 is the well known port for LDP, R1 is sourcing it therefore R1 is the server.

A new LDP adjacency has formed! This won't happen if the loopbacks of the LSRs are reachable, ACL, CoPP or some other reason.

%LDP-5-NBRCHG: LDP Neighbor 192.168.1.11:0 (1) is UP

The output indicates that we peered with 192.168.1.11:0 or XR1 with a system wide label space.

One big thing about MPLS is the dependency on the loopback address and the Router ID. If the loopback address of the LSR is not advertised into IGP, the TCP connection will not form or will break. You can change the transport address, discussed in another post. It is highly recommended, and should be part of your initial configuration, to hard code the Router ID.

Normally a Router ID is simply a way for a node on a network to identify itself. The LDP RID however needs to be a routeable IP address, advertised into IGP. It is recommended, the method we will use, is to map the RID to the loopback address. Makes life much simpler long term.

IOS
R1(config)#mpls ldp router-id loopback 0 force

XR
mpls ldp
 router-id 192.168.1.11

Now onto the label advertisement

R1's advertisement to XR1, this is of course only a brief output due to the R1 knowing all the peerings out there currently. We'll enable the ldp advertisement debug and flap the link between R1 and XR1. 

R1#debug mpls ldp advertisements

lcon: Send initial advertisements to peer 192.168.1.11:0

lcon: peer 192.168.1.11:0 (pp 0x7F5D39BE89A0): advertise 10.1.12.1

lcon: peer 192.168.1.11:0 (pp 0x7F5D39BE89A0): advertise 10.1.15.1

lcon: peer 192.168.1.11:0 (pp 0x7F5D39BE89A0): advertise 192.168.1.1

lcon: peer 192.168.1.11:0 (pp 0x7F5D39BE89A0): advertise 10.1.11.1

lcon: peer 192.168.1.11:0 (pp 0x7F5D39BE89A0): advertise 10.1.12.0/24, label 3 (imp-null) (#4)

lcon: peer 192.168.1.11:0 (pp 0x7F5D39BE89A0): advertise 10.1.15.0/24, label 3 (imp-null) (#6)

lcon: peer 192.168.1.11:0 (pp 0x7F5D39BE89A0): advertise 10.2.6.0/24, label 16 (#8)

lcon: peer 192.168.1.11:0 (pp 0x7F5D39BE89A0): advertise 10.3.4.0/24, label 17 (#10)

You'll see the the first 4 are the local interfaces of R1. Followed by connected /24 subnets to XR2 and XR5. These are imp-null'd with label 3 since they are directly connected to their peers and receiving the PHP configuration from their peer. The labels for subsequent prefixes start at 16 and climb up from there. Since the loopback address block here is 192.168.1.0/24, that gets advertised last, not shown here. 

XR1 also advertises a label allocation to R1

lcon: Allocating address 10.1.11.11 advertised by LDP router-id 192.168.1.11

lcon: Allocating address 10.11.14.11 advertised by LDP router-id 192.168.1.11

lcon: Allocating address 192.168.1.11 advertised by LDP router-id 192.168.1.11

We can verify the mpls forwarding tables of the LSRs

R1#show mpls forwarding-table interface g1.111

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop

Label      Label      or Tunnel Id     Switched      interface

20         Pop Label  10.11.14.0/24    0             Gi1.111    10.1.11.11

24         24012      10.14.3.0/24     0             Gi1.111    10.1.11.11

31         24010      192.168.1.3/32   0             Gi1.111    10.1.11.11

35         Pop Label  192.168.1.11/32  0             Gi1.111    10.1.11.11

38         24008      192.168.1.14/32  0             Gi1.111    10.1.11.11

Pop label indicates that the PHP process is going to remove the transport label and forward the packet via raw IP, 192.168.1.11 is XR1s loopback address. 

R1#sh ip route 192.168.1.3

Routing entry for 192.168.1.3/32

  * 10.1.15.15, from 192.168.1.3, 22:52:50 ago, via GigabitEthernet1.115

      Route metric is 4, traffic share count is 1

    10.1.11.11, from 192.168.1.3, 00:21:16 ago, via GigabitEthernet1.111

      Route metric is 4, traffic share count is 1

R1#show ip cef 192.168.1.11

192.168.1.11/32

  nexthop 10.1.11.11 GigabitEthernet1.111

192.168.1.3 is R3s loopback address, R1 will use label 24010 out int g1.111 to get there. 

R1#show ip cef 192.168.1.3

192.168.1.3/32

  nexthop 10.1.11.11 GigabitEthernet1.111 label 24010

  nexthop 10.1.15.15 GigabitEthernet1.115

The first link will use an LSP, the second will not

R1#show ip cef 192.168.1.3 internal

output chain:

    loadinfo 7F5D3A981E40, per-session, 2 choices, flags 0003, 4 locks

      flags [Per-session, for-rx-IPv4]

      16 hash buckets

        < 0 > label 24010

              TAG adj out of GigabitEthernet1.111, addr 10.1.11.11 7F5D3AB3BE88

        < 1 > IP adj out of GigabitEthernet1.115, addr 10.1.15.15 7F5D39BDB200

As you can see, 1 LSP the other is raw IP

R1#traceroute 192.168.1.3 source lo0 num

Type escape sequence to abort.

Tracing the route to 192.168.1.3

VRF info: (vrf in name/id, vrf out name/id)

  1 10.1.15.15 2 msec

    10.1.11.11 [MPLS: Label 24010 Exp 0] 2 msec

    10.1.15.15 1 msec

  2 10.11.14.14 2 msec

    10.15.4.4 1 msec

    10.11.14.14 1 msec

  3 10.3.4.3 2 msec

    10.14.3.3 1 msec *

Being able to know the recursion process will help during your prep, this is the most basic configuration setup. They will only get more complicated as we go.

Thanks for stopping by!

Rob Riker, CCIE #50693

MPLS Inter AS L3 VPN Carrier Supporting Carrier or CSC

In this post we will take a look at CSC or Carrier Supporting Carrier. This is a really involved configuration and will take sometime to break down all the individual steps in order to get our Customer sites to be able to talk to each other.

First, lets cover what CSC is. The really basic part is we're connecting regional Tier 2 POPs together via a Tier 1 Backbone provider. That's pretty much it, a bit oversimplified but if you have never seen, heard of or worked with CSC, it's one of the more advanced and configuration intensive IAS capabilities out there.

So what is really going, I know what your thinking, jee.... connecting Tier 2 POPs together via a Tier 1 backbone, jee.... way to make it sound not complicated. That's kind of the point. There are 3 individual MPLS L3 VPN providers in our setup here, 2 of which are in the same BGP AS (Tier 2 POPs) and the 3rd is the Tier 1 Backbone. The Backbone provider treats both Tier 2 POPs as CE sites, the Tier 2 POPs treat their customer as regular CEs. Pretty much a hierarchical L3 VPN at the end of the day. Sort of like the MPLS Superbackbone with OSPF.

Out Topology:

The ASN 50693 is our T1 backbone, R1, R2, R3, XR1, XR2 and XR3.

The ASN 1000 is 2 Regions, R4, R5 and XR4; R13, R14 and R16.

R7 and R15 are our customer sites that need to reach each other.....

First and foremost, IGP/LDP, VPNv4 PE-PE iBGP peerings, and VRFs need to be configured in each site. In my first rollout, I leveraged R1, R5 and R16 as RR for BGP. I kept this design until the very end, we'll discuss this later. 

Once you have Intra AS L3 VPN setup and ready to go, the Inter AS setup comes. We'll start with the Backbone configuration. ****For whatever reason, haven't figured out why, IOS XRv 5.3.0 would not pass VPNv4 traffic down to the CSC_CEs.**** I ended up routing around XRv and using all IOS XE (CSR1000v) to get this up and running. I'll add in the applicable configuration for XRv. 

On the connection from XR2 to R13 I placed g0/0/0/0.1312 into VRF CSC.

XR2, XR3

vrf CSC

 address-family ipv4 unicast

  import route-target

   3:3

  !

  export route-target

   3:3

XR2

int g0/0/0/0.1312

vrf CSC

ipv4 address 13.12.0.12 255.255.255.0

 ipv6 address 2001:13:12::12/64

XR3

interface GigabitEthernet0/0/0/0.134

 vrf CSC

 ipv4 address 13.4.0.13/24

 ipv6 address 2001:13:4::13/64

Now on to the BGP configuration

XR2

vrf CSC

  rd 3:3

  address-family ipv4 unicast

  !

  neighbor 13.12.0.13

   remote-as 1000

   address-family ipv4 labeled-unicast

    route-policy PASS in

    route-policy PASS out

    as-override

The RD is placed under the VRF configuration under BGP

Labeled-unicast is used to advertise BGP labels

AS-override is to remove the AS received from the Customer Carrier and replace it with the Core Carrier AS

XR3

vrf CSC

  rd 3:3

  address-family ipv4 unicast

  !

  neighbor 13.4.0.4

   remote-as 1000

   address-family ipv4 labeled-unicast

    route-policy PASS in

    route-policy PASS out

    as-override

Now we need to make sure that any routes that are learned in the IPv4 Unicast AFI get labels associated to them

XR2 and XR3

router bgp 50693

 address-family ipv4 unicast

  allocate-label all

Allocate label all is used to allocate labels to global BGP routes

Now we have one more issue, the prefix that XR2 and XR3 peer with is /24 to the CSC_CE. No labels will be allocated for a /24, we need to make this a /32.

XR2

show mpls forwarding-table

120012 Aggregate   13.12.0.0/24[V]    CSC                          0

XR2 

router static

 vrf CSC

  address-family ipv4 unicast

   13.12.0.13/32 GigabitEthernet0/0/0/0.1312

XR2

show mpls forwarding-table

120003 Pop         13.12.0.13/32[V]   Gi0/0/0/0.1312 13.12.0.13      6480

You can see how now there is a "Pop" now. That's how we'll get label allocation for this connected prefix that is a /24.

XR3

router static

 vrf CSC

  address-family ipv4 unicast

   13.4.0.4/32 GigabitEthernet0/0/0/0.134

Like I mentioned, XRv wasn't advertising routes to the Customer Carrier, so I modified the configuration and removed XR from the demo. The above configuration is still applicable, use it if you can.

IOS Based setup from here out.

R3 

I created the VRF CSC on R3 and R1, then under BGP I peered with R4 to R3 and R1 to R13. 

R3

int g1.34

vrf for CSC

en do 34

ip add 3.4.0.3 255.255.255.0

R4

int g1.34

en do 34

ip add 3.4.0.4 255.255.255.0

R1

int g1.13

en do 13

vrf for CSC

ip add 1.13.0.1 255.255.255.0

R13

int g1.13

en do 13

ip add 1.13.0.13 255.255.255.0

Now we can configure the BGP IPv4 Unicast peerings and advertise BGP Labels. IGP+LDP is applicable here but not demo'd. It would have been easier but who likes easy?

R1

router bgp 50693

 no bgp default ipv4-unicast

 address-family ipv4 vrf CSC

  neighbor 1.13.0.13 remote-as 1000

  neighbor 1.13.0.13 activate

  neighbor 1.13.0.13 as-override

  neighbor 1.13.0.13 send-label

Send-label is the equivalent to labeled-unicast in XR, it advertises BGP labels. Both R1 and R13 need this configured. AS Override is configured since both Tier 2 POPs are in the same ASN.

R13

router bgp 1000

no bgp default ipv4

neighbor 1.13.0.1 remote-as 50693

address-family ipv4

  redistribute ospf 1

  neighbor 1.13.0.1 activate

  neighbor 1.13.0.1 allowas-in

  neighbor 1.13.0.1 send-label

R3

router bgp 50693

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

address-family ipv4 vrf CSC

  neighbor 3.4.0.4 remote-as 1000

  neighbor 3.4.0.4 activate

  neighbor 3.4.0.4 as-override

  neighbor 3.4.0.4 send-label

R4

router bgp 1000

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

address-family ipv4

  neighbor 3.4.0.3 activate

  neighbor 3.4.0.3 allowas-in

  neighbor 3.4.0.3 send-label

Now routes are propagating via BGP.

R4

show ip bgp sum

3.4.0.3         4        50693     302     288       77    0    0 04:08:16        8

show ip bgp

*>  14.14.14.14/32   3.4.0.3                                0 50693 50693 ?

I omitted everything but R14's loopback, it's all we care about.

R13

show ip bgp sum

1.13.0.1        4        50693     262     265       59    0    0 03:54:21        8

show ip bgp

*>  114.114.114.114/32          1.13.0.1                               0 50693 50693 ?

Now we need to be able to ping/trace R14 to XR4 loopbacks.

R14#ping 114.114.114.114 source lo0

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 2/6/20 ms

R14#traceroute 114.114.114.114 source lo0 num

VRF info: (vrf in name/id, vrf out name/id)

  1 13.14.0.13 [MPLS: Labels 29/44 Exp 0] 5 msec 7 msec 5 msec

  2 1.13.0.1 [MPLS: Label 44 Exp 0] 30 msec 31 msec 152 msec

  3 10.1.2.2 [MPLS: Labels 24/30 Exp 0] 31 msec 32 msec 31 msec

  4 3.4.0.3 [AS 50693] [MPLS: Label 30 Exp 0] 32 msec 30 msec 29 msec

  5 3.4.0.4 [AS 50693] [MPLS: Label 18 Exp 0] 21 msec 20 msec 20 msec

  6 10.4.14.14 [AS 50693] 21 msec *  3 msec

Now we need to peer R14 to XR4 via VPNv4.

R14

router bgp 1000

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 114.114.114.114 remote-as 1000

 neighbor 114.114.114.114 update-source Loopback0

address-family vpnv4

  neighbor 114.114.114.114 activate

  neighbor 114.114.114.114 send-community extended

XR4

router bgp 1000

neighbor 14.14.14.14

  remote-as 1000

  update-source Loopback0

  address-family vpnv4 unicast

R13 and R4 have to redistribute BGP into OSPF

router ospf 1

 redistribute bgp 1000 subnets

RP/0/0/CPU0:XR4#sh bgp vpnv4 unicast summary

14.14.14.14       0  1000     264     239        5    0    0 03:56:05          1

R14 and XR4 are now peered via VPNv4 iBGP. You can also see that "1" route is being propagated.

RP/0/0/CPU0:XR4#sh bgp vpnv4 unicast

*> 14.7.0.0/24        14.7.0.7                 0             0 7 i

*>i14.15.0.0/24       14.14.14.14              0    100      0 15 i

XR4 sees the route of 14.15.0.0/24 that R14 advertised it.

R15

show ip route

B        14.7.0.0/24 [20/0] via 14.15.0.14, 00:14:47

R15 sees the R7 route.

Now lets see if we can ping from R15 to R7

R15#ping 14.7.0.7

.....

Success rate is 0 percent (0/5)

WHAT!!!! Ok, calm down, easily fixed. But first explained. XR4 is learning the 14.7.0.0/24 prefix from R7. XR4 generates a VPNv4 label for it. That info is propagated via VPNv4 to R14. The problem is that XR4 to R4 is IGP+LDP. Therefore, when XR4 goes to forward the traffic, R4 won't know what do with it. The problem is that R13 is receving BGP labels from R1, there has to be a way to bridge the LSP from XR4 to R14, but we can't since R13 terminates the LSP via BGP and R13 to R14 is LDP. So.... we have to extend BGP to R14.

R13

router bgp 1000

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 14.14.14.14 remote-as 1000

 neighbor 14.14.14.14 update-source Loopback0

address-family ipv4

  neighbor 14.14.14.14 activate

  neighbor 14.14.14.14 send-label

R14

router bgp 1000

 bgp log-neighbor-changes

 no bgp default ipv4-unicast

 neighbor 13.13.13.13 remote-as 1000

 neighbor 13.13.13.13 update-source Loopback0

address-family ipv4

  neighbor 13.13.13.13 activate

  neighbor 13.13.13.13 send-label

Now R13 can advertise BGP labels to R14

R15

R15#ping 14.7.0.7

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 3/7/18 ms

R15#traceroute 14.7.0.7 num

VRF info: (vrf in name/id, vrf out name/id)

  1 14.15.0.14 71 msec 3 msec 1 msec

  2 13.14.0.13 [MPLS: Labels 29/44/24006 Exp 0] 29 msec 16 msec 4 msec

  3 1.13.0.1 [MPLS: Labels 44/24006 Exp 0] 12 msec 32 msec 51 msec

  4 10.1.13.13 [MPLS: Labels 130002/30/24006 Exp 0] 122 msec 81 msec 23 msec

  5 10.13.3.3 [MPLS: Labels 30/24006 Exp 0] 32 msec 52 msec 33 msec

  6 3.4.0.4 [MPLS: Labels 18/24006 Exp 0] 20 msec 26 msec 21 msec

  7 10.4.14.14 20 msec 77 msec 15 msec

  8 14.7.0.7 [AS 7] 35 msec *  6 msec

VIOLA! Ok, it's a bit dirty but it's working. You can see there are 3 label stacks on hops 2 and 4

24006 is the VPNv4 label XR4 allocated the 14.7.0.0/24 prefix. This never changes. The 29/44 in our first hop is 44 of the LDP label and 29 of the BGP label. 

That is pretty much it. OK, I know what your thinking. Jee Rob, long enough post? This is the last long one for a while. Not much left to cover for CCNP stuff. I plan on doing a ton of posts for CCIE prep. 

Thanks for stopping by!

Rob Riker, CCIE #50693

MPLS L3 VPN Inter AS Option C Multihop EBGP VPNv4 Peering

In our last post we took a look at Option B where we had R1 and XR1 form a VPNv4 BGP peering and exchange labels, the LSP is then end to end and not broken up at the ASBRs. 

In this post we will take a look at Option C or  Multihop EBGP VPNv4 Peerings between the different ASs Route Reflectors. Not to be mistaken, we are not form RR peerings between the RRs rather using the RR as a way to propagate routing info from the remote ASs into the local AS. The configuration is pretty straightforward for the most part, it's more a matter of understanding the individual functions and the role each serves that will help bring this config altogether.

The PE-PE connectivity is the first piece, which is going to be between BGP ASN 1000 and BGP ASN 50693, this will be done in the global table with some minor modifications made later. I'm using a different topology than the last couple Inter AS rollouts but the process is the same:

R3 and XR4 need to form EBGP IPv4 Unicast peerings with each other. The send-label config is used to send BGP routes plus BGP labels to the remote PE, XR4 in this case. The labeled-unicast on XR4 does the same thing as the send-label, adds a BGP label.

R3:

router bgp 50693

 neighbor 143.0.0.14 remote-as 1000

 !

 address-family ipv4

  neighbor 143.0.0.14 activate

  neighbor 143.0.0.14 send-label

XR4:

router bgp 1000

neighbor 143.0.0.3

  remote-as 50693

  address-family ipv4 labeled-unicast

   route-policy PASS in

   route-policy PASS out

As soon as this peering is up and running, we move to the next step of advertising the route reflector loopbacks of BGP ASN 1000 and 50693 into IPv4 BGP in their respective ASN.

XR4:

RP/0/0/CPU0:XR4#sh run router bgp

router bgp 1000

 address-family ipv4 unicast

  network 4.4.4.4/32

  network 114.114.114.114/32

R4:

router bgp 1000

address-family ipv4

 network 4.4.4.4 mask 255.255.255.255

R3

router bgp 50693

address-family ipv4

 network 1.1.1.1 mask 255.255.255.255

Now, we should see on R4 and XR4, the 1.1.1.1/32 in BGP

XR4:

show route

B    1.1.1.1/32 [20/30] via 143.0.0.3, 20:35:22

B        1.1.1.1 [20/20] via 13.4.0.13, 00:10:41

One of the issues I ran into with having 2 BGP external connections is that the AD of eBGP is 20 and OSPF is 110. So I ended up having to shutdown the connection between  XR3 and R4. 

What needs to happen next is the IGP needs to redistribute the BGP Loopback /32 address into IGP. We'll use some filtering to make sure only the loopbacks are learned.

XR4:

prefix-set BGP

  1.1.1.1/32

end-set

!

route-policy BGP_TO_IGP

  if destination in BGP then

    pass

  endif

end-policy

!

router ospf 1

 redistribute bgp 1000 route-policy BGP_TO_IGP

R3:

router isis 1

 redistribute bgp 50693 route-map BGP_TO_IGP

ip prefix-list BGP seq 5 permit 4.4.4.4/32

ip prefix-list BGP seq 10 permit 114.114.114.114/32

route-map BGP_TO_IGP permit 10

 match ip address prefix-list BGP

Now to verify that R1, R4 and XR4 are learning the remote RR loopback(s).

R1:

sh ip route

i L2     4.4.4.4 [115/20] via 10.1.13.13, 20:41:53, GigabitEthernet1.113

                 [115/20] via 10.1.2.2, 20:41:53, GigabitEthernet1.12

i L2     114.114.114.114

           [115/20] via 10.1.13.13, 20:41:53, GigabitEthernet1.113

           [115/20] via 10.1.2.2, 20:41:53, GigabitEthernet1.12

XR4 is a bit unique, but it still works ;)

show route

B    1.1.1.1/32 [20/30] via 143.0.0.3, 20:42:58

R4:

show ip route

O E2     1.1.1.1 [110/1] via 10.4.14.14, 20:43:16, GigabitEthernet1.414

Now, the next step here is to verify that R1, R4 and XR4 can ping/trace to and from each other's loopback addresses.

R1:

R1#ping 4.4.4.4 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 3/8/24 ms

R1#ping 114.114.114.114 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 114.114.114.114, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 2/5/18 ms

R4#ping 1.1.1.1 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 4.4.4.4

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 2/6/20 ms

XR4:

RP/0/0/CPU0:XR4#ping 1.1.1.1 source 114.114.114.114

Fri Nov  4 21:33:53.914 UTC

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

Alright! Now we can form the eBGP VPNv4 Multihop peerings!

R1:

router bgp 50693

 neighbor 4.4.4.4 remote-as 1000

 neighbor 4.4.4.4 ebgp-multihop 255

 neighbor 4.4.4.4 update-source Loopback0

 neighbor 114.114.114.114 remote-as 1000

 neighbor 114.114.114.114 ebgp-multihop 255

 neighbor 114.114.114.114 update-source Loopback0

 address-family vpnv4

  neighbor 4.4.4.4 activate

  neighbor 4.4.4.4 send-community extended

  neighbor 114.114.114.114 activate

  neighbor 114.114.114.114 send-community extended

 exit-address-family

R4:
router bgp 1000
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 1.1.1.1 remote-as 50693
 neighbor 1.1.1.1 ebgp-multihop 255
 neighbor 1.1.1.1 update-source Loopback0
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
exit-address-family

XR4:

router bgp 1000

 neighbor 1.1.1.1

  remote-as 50693

  ebgp-multihop 255

  update-source Loopback0

  address-family vpnv4 unicast

   route-policy PASS in

   route-policy PASS out

   next-hop-unchanged

Let's verify that the BGP peerings are formed and exchanging routes.

R1:

sh bgp vpnv4 unicast all summary

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

4.4.4.4         4         1000    1407    1419      515    0    0 20:52:56        4

114.114.114.114 4         1000    1259    1394      515    0    0 20:48:00        4

R4:

sh bgp vpnv4 unicast all summary

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

1.1.1.1         4        50693    1420    1408      519    0    0 20:53:32       24

XR4:

sh bgp vpnv4 unicast summary

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd

1.1.1.1           0 50693    1421    1275     1223    0    0 20:49:06         24

Now that we have routes being learned and propagated we can now begin the next step, which is setting up XR4 for the XR specific configuration.

R3 on the peering to XR4 needs to have the "send-label" configuration under the IPv4 unicast AFI.

R3:

router bgp 50693

address-family ipv4

  neighbor 143.0.0.14 send-label

XR4:

router static

 address-family ipv4 unicast

  143.0.0.3/32 GigabitEthernet0/0/0/0.143

Needed for a /32 host route to the next hop towards R3, hence the 143.0.0.3/32 configuration. 

XR4:

router bgp 1000

 address-family ipv4 unicast

  allocate-label all

To trigger BGP to allocate labels for all global routes

We should be good to go at this point, routes should be propagated and LSPs should be built. Lets see what R7 and R5 see as route counts via BGP

R7:

show ip bgp summary

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

14.7.0.14       4         1000    3012    3285      273    0    0 2d01h          18

R5:

show ip bgp summary

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

54.0.0.4        4         1000    1641    1624       99    0    0 1d00h           6

Great! Now lets trace from R9 to R7 and see the output:

R9#traceroute 7.7.7.7 source lo0 num

Type escape sequence to abort.

Tracing the route to 7.7.7.7

VRF info: (vrf in name/id, vrf out name/id)

  1 12.9.0.12 2 msec 1 msec 0 msec

  2 10.11.12.11 [MPLS: Labels 111017/24 Exp 0] 9 msec 8 msec 7 msec

  3 10.1.11.1 [MPLS: Labels 55/24 Exp 0] 28 msec 31 msec 32 msec

  4 10.1.13.13 [MPLS: Labels 130027/24 Exp 0] 32 msec 31 msec 32 msec

  5 10.13.3.3 [MPLS: Labels 56/24 Exp 0] 71 msec 77 msec 21 msec

  6 143.0.0.14 [MPLS: Labels 24000/24 Exp 0] 22 msec 21 msec 22 msec

  7 10.4.14.4 [MPLS: Label 24 Exp 0] 22 msec 21 msec 21 msec

  8 10.4.14.14 [MPLS: Label 24025 Exp 0] 22 msec 21 msec 21 msec

  9 14.7.0.7 [AS 7] 21 msec *  74 msec

As you can see the LSP is maintained, it changes when the Inter AS link comes into play on hop 8, the VPNv4 label changes from 24 to 24025. But that is an expected outcome. What we do see but is a sub optimal path is that R4, or hop 7 is in the data plane. The reason behind that is the next hops via bgp vpnv4 unicast is R1, R4 and XR4. Since the VPNv4 next hop is the remote AS RR, that is where the LSP will terminate for 7.7.7.7, at least in this particular case. 

We can change this by issuing the next-hop-unchanged under the VPNv4 unicast AFI.

R1

router bgp 50693

address-family vpnv4

  neighbor 4.4.4.4 next-hop-unchanged

R4

router bgp 1000

address-family vpnv4

  neighbor 1.1.1.1 next-hop-unchanged

XR4

router bgp 1000

neighbor 4.4.4.4

address-family vpnv4 unicast

 next-hop-unchanged

Now we can retrace from R9 to R7 and see the difference

R9#traceroute 7.7.7.7 source lo0 num

Type escape sequence to abort.

Tracing the route to 7.7.7.7

VRF info: (vrf in name/id, vrf out name/id)

  1 12.9.0.12 1 msec 1 msec 1 msec

  2 10.11.12.11 [MPLS: Labels 111018/24025 Exp 0] 9 msec 8 msec 9 msec

  3 10.1.11.1 [MPLS: Labels 54/24025 Exp 0] 29 msec 32 msec 37 msec

  4 10.1.2.2 [MPLS: Labels 17/24025 Exp 0] 22 msec 31 msec 31 msec

  5 10.2.3.3 [MPLS: Labels 57/24025 Exp 0] 32 msec 39 msec 23 msec

  6 14.7.0.7 [AS 7] 21 msec *  8 msec

Notice now that the VPNv4 label of 24025 is now maintained end to end. This is the expected output since we aren't having to leave one LSP and join another one, we are no longer terminating on R4 and then using LDP between R4 and XR4 to label switch the VPNv4 label to XR4. 

As you can see, this is a rather involved configuration. I didn't bother showing the base setup of IGP/LDP, VPNv4 peerings, VRF configuration or the PE-CE routing. It is assumed you already know how to do that. 

Thanks for stopping by!

Rob Riker, CCIE #50693