MPLS VPN basics – Getting it all started.

I guess I should start first things first. With VRFs (Virtual Routing and Forwarding), there can multiple instances of separate tables to exist on the same routers. Each ones of these VRF is independent and provides separation for these networks. Since they are separate routing tables, VRFs allow for overlapping space. Look at the topology I have been using.

There are 2 VRFs configured in this topology, RED and BLUE. Each VRF has a east and west router in there. VRFs would allow the PE routers (west and east) to have isolated routing tables for each customer. Therefore, is both BLUE and RED are using the 10.0.0.0/8 address space. Not a problem. Each /8 network is part of a different VRF and traffic will remain isolated between sites.

Now, the PE routers needs to exchange information to the CEs can communicate. Welcome to the service of MPLS VPN. Here are a few items which need to be known for MPLS VPN.

For MPLS VPN, a RD (route distinguisher) of 64 bits is prepended to the customer’s 32 bit ipv4 address to create what is known as a VPNv4 route ( 96 bits ). RDs are only locally significant to a router, but since its part of the VPNv4 route it does have global significance.

RT (route target) is a 64 byte extended BGP community attached to a VPNv4 route. There can be multiple RTs attached to a single route, but can not exceed the packet size of 4096. These RT are used to import and export VNPv4 routes into and out of VRFs.  RT can be filtered both inbound and outbound for route control. Examples to come.

RD and RTs are usually in the format of ASN:nn or IPADDRESS:nn  where nn equals any number.

One other item I wanted to mention is the labels.  With MPLS VPN, there are 2 labels in the label stack. There is a top label which is used to switch the packets through the MPLS network. This is often called the LDP label and is the next hop of the BGP route, usually the loopback from the peering sessions. The bottom label is the VPN label is used to separate the outgoing interface on the PE router. This is propagated with M-BGP.

M-BGP (Multiprotocol Extensions for BGP-4) is defined in RFC 2858. The RFC introduces two new BGP attributes MP_REACH_NLRI or MP_UNREACH_NLRI. These new attributes contain an AFI (Address Family Identifier) and SAFI (Subsequent Address Family Identifier). The AFI carries the identity of the Network Layer Protocol and the SAFI provides additional information about the type of NLRI.

- AFIs can be either IPv4 or IPv6.

- SAFIs can be either Unicast, Multicast, Unicast and Multicast, MPLS Label, MPLS Labled VPN.

To start the configuration, lets make sure our LSP is working between PE_WEST and PE_WEST. For brevity, I am only going to go from WEST->EAST, but I verified both ways.

PE_WEST#traceroute 200.200.200.200

Type escape sequence to abort.
Tracing the route to 200.200.200.200

1 10.10.11.2 [MPLS: Label 25 Exp 0] 36 msec 24 msec 20 msec
2 10.13.13.3 [MPLS: Label 25 Exp 0] 16 msec 48 msec 20 msec
3 10.30.33.10 16 msec 52 msec *

PE_WEST#show mpls forwarding-table 200.200.200.200
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
26     25            200.200.200.200/32   \
0             Fa2/0      10.10.11.2
25            200.200.200.200/32   \
0             Fa2/1      10.20.22.2

P1#show mpls forwarding-table 200.200.200.200
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
25     25            200.200.200.200/32   \
950           Fa1/1      10.13.13.3

P3#show mpls forwarding-table 200.200.200.200
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
25     Pop Label     200.200.200.200/32   \
0             Fa1/1      10.30.33.10

Now, let’s get M-BGP set up and ready to go.

PE_WEST(config)#router bgp 100
PE_WEST(config-router)#neighbor 200.200.200.200 remote-as 100
PE_WEST(config-router)#neighbor 200.200.200.200 update-source lo0

PE_EAST(config)#router bgp 100
PE_EAST(config-router)#neighbor 100.100.100.100 remote-as 100
PE_EAST(config-router)#neighbor 100.100.100.100 update-source lo0

PE_WEST(config-router)#address-family vpnv4 unicast
PE_WEST(config-router-af)#neighbor 200.200.200.200 activate
PE_WEST(config-router-af)#neighbor 200.200.200.200 send-community both

PE_EAST(config-router)#address-family vpnv4 unicast
PE_EAST(config-router-af)#neighbor 100.100.100.100 activate
PE_EAST(config-router-af)#neighbor 100.100.100.100 send-community both

Look at the config afterwards and you’ll notice now the router bgp process is broken down to address family. Under the main router bgp process is all the connection information, and under the address family’s are the specifics for that family. Remember to active the neighbor of each address family you want to use. The ipv4 vrf address families are created as well, as these will be needed for PE/CE routing.

router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 200.200.200.200 remote-as 100
neighbor 200.200.200.200 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 200.200.200.200 activate
neighbor 200.200.200.200 send-community both
exit-address-family
!
address-family ipv4 vrf RED
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf BLUE
no auto-summary
no synchronization
exit-address-family

Check to make sure the vpnv4 address family is working between BGP peers.

PE_WEST#show bgp vpnv4 unicast all summary
BGP router identifier 100.100.100.100, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
200.200.200.200 4   100    1076    1076        1    0    0 00:00:10        0

Now time to set up from PE-CE routing.

MPLS LDP Conditional Label Advertisement

MPLS LDP Conditional Label Advertisement enables the ability to advertise labels for a certain FECs to a selected group of LDP peers. For instance, if all you need are LSPs for M-BGP peering sessions, the PE router can be configured to only advertise these loopback labels to a specific (or all) LDP neighbors.

In this topology I will configure PE_WEST to only advertise the label for its local loopback to P1 and not P2.

First, I’ll create ACL 50 to match P1 and 51 to match the loopback.

PE_WEST(config)#access-list 50 permit 1.1.1.1
PE_WEST(config)#access-list 51 permit 100.100.100.100

Before we apply conditional advertisement, let’s looks at P2 and look at the LIB and LFIB for 10.10.11.0/24. This is the connected subnet between PE_WEST and P1.

P2#show mpls ldp bindings 10.10.11.0 24
lib entry: 10.10.11.0/24, rev 10
local binding:  label: 19
remote binding: lsr: 4.4.4.4:0, label: 19
remote binding: lsr: 100.100.100.100:0, label: imp-null
remote binding: lsr: 1.1.1.1:0, label: imp-null

P2#show mpls forwarding-table 10.10.11.0 24
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
19     Pop Label     10.10.11.0/24     0             Fa2/0      10.12.12.1
Pop Label     10.10.11.0/24     0             Fa1/0      10.20.22.10

I can see PE_WEST its it sending the binding for this FEC for a imp-null (label 3). Once we enable conditional advertise for only the loopback address, I expect this entry to be removed from the LIB.

PE_WEST(config)#no mpls ldp advertise-labels
PE_WEST(config)#mpls ldp advertise-labels for 51 to 50

Now check P2 again.

P2#show mpls ldp bindings 10.10.11.0 24
lib entry: 10.10.11.0/24, rev 10
local binding:  label: 19
remote binding: lsr: 4.4.4.4:0, label: 19
remote binding: lsr: 1.1.1.1:0, label: imp-null

P2#show mpls forwarding-table 10.10.11.0 24
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
19     Pop Label     10.10.11.0/24     0             Fa2/0      10.12.12.1
No Label      10.10.11.0/24     0             Fa1/0      10.20.22.10

Excellent. P2 no longer gets this binging from PE_WEST. If you look in the LIB in PE_WEST, the labels are still applied, just not advertised to P2.

MPLS LDP Autoconfig

How many times has someone had to enable a protocol (such as ospf, eigrp, ldp, etc) on many interfaces and for did not noticed one was missed after hours of troubleshooting? I know I have done this numerous times. In fact, to many in which I would like to admit.

By default, mpls ip needs to be entered on every IGP interface to start LDP. MPLS LDP autoconfiguration is a feature which will globally configure LDP on every interface associated with a specified IGP. One thing to note, this feature if only supported with OSPF and IS-IS IGPs.

Configuration of this feature is real straight forward. I set up one router to have 10 ospf interfaces brought into ospf process 1.

R1#show ip ospf int bri
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa2/0        1     0               10.2.10.1/24       1     WAIT  0/0
Fa1/0        1     0               10.11.10.1/24      1     WAIT  0/0
Fa0/1        1     0               10.1.10.1/24       10    WAIT  0/0
Fa0/0        1     0               10.0.10.1/24       10    DR    0/0
Se0/1        1     1               172.16.1.1/24      64    DOWN  0/0
Se0/0        1     1               172.16.0.1/24      64    DOWN  0/0
Se0/3        1     3               172.16.3.1/24      64    DOWN  0/0
Se0/2        1     3               172.16.2.1/24      64    DOWN  0/0
Se0/4        1     4               172.16.4.1/24      64    DOWN  0/0
Se0/5        1     5               172.16.5.1/24      64    DOWN  0/0

Checking, nothing shows up in the mpls interface list.

R1#show mpls int
Interface              IP            Tunnel   Operational
R1#

Let’s enable this for all the interfaces under ospf 1.

R1(config)# router ospf 1
R1(config-router)#mpls ldp autoconfig

Now check the mpls interface list and all the interfaces with ospf enabled have mpls enabled now as well.

R1(config-router)#do show mpls int
Interface              IP            Tunnel   Operational
FastEthernet0/0        Yes (ldp)     No       Yes
FastEthernet0/1        Yes (ldp)     No       Yes
Serial0/0              Yes           No       No
Serial0/1              Yes           No       No
Serial0/2              Yes           No       No
Serial0/3              Yes           No       No
Serial0/4              Yes           No       No
Serial0/5              Yes           No       No
FastEthernet1/0        Yes (ldp)     No       Yes
FastEthernet2/0        Yes (ldp)     No       Yes

If you only want it for one area. This can be done as well.

R1(config-router)#no mpls ldp autoconfig
R1(config-router)#mpls ldp autoconfig area 0

Now only the interfaces in area 0 have mpls enabled.

R1(config-router)#do show mpls int
Interface              IP            Tunnel   Operational
FastEthernet0/0        Yes (ldp)     No       Yes
FastEthernet0/1        Yes (ldp)     No       Yes
FastEthernet1/0        Yes (ldp)     No       Yes
FastEthernet2/0        Yes (ldp)     No       Yes

If I remove an interface from ospf area 0, it automatically stops LDP on that interface.

R1(config)# int fa0/0
R1(config-if)# no ip ospf 1 area 0
R1(config-if)#do show mpls int
Interface              IP            Tunnel   Operational
FastEthernet0/1        Yes (ldp)     No       Yes
FastEthernet1/0        Yes (ldp)     No       Yes
FastEthernet2/0        Yes (ldp)     No       Yes

You can add multiple areas. If only Area 0 and 1 are to run mpls, there would be two autoconfig lines, one with each area.

MPLS LDP Inbound Label Filtering

MPLS LDP inbound label filtering can be used to reduce the size of the LIB by filtering label bindings that are advertised by other routers. This can save memory needed on a router to participate in the MPLS domain.

In this scenario, I want to filter all the bindings from P2 except for the loopback of PE_EAST, which is 200.200.200.200. The reason I choose only to permit the loopback of PE_EAST is this label will be the only one needed when I set up my iBGP peering for MP-BGP, when I get to the VRFs.

This is the topology used.
Checking the current LIB

PE_WEST#show mpls ldp bindings neighbor 2.2.2.2
lib entry: 1.1.1.1/32, rev 30
remote binding: lsr: 2.2.2.2:0, label: 16
lib entry: 2.2.2.2/32, rev 4
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 3.3.3.3/32, rev 6
remote binding: lsr: 2.2.2.2:0, label: 17
lib entry: 4.4.4.4/32, rev 8
remote binding: lsr: 2.2.2.2:0, label: 18
lib entry: 10.10.11.0/24, rev 10
remote binding: lsr: 2.2.2.2:0, label: 19
lib entry: 10.12.12.0/24, rev 12
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 10.13.13.0/24, rev 14
remote binding: lsr: 2.2.2.2:0, label: 20
lib entry: 10.20.22.0/24, rev 16
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 10.24.24.0/24, rev 18
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 10.30.33.0/24, rev 20
remote binding: lsr: 2.2.2.2:0, label: 21
lib entry: 10.34.34.0/24, rev 22
remote binding: lsr: 2.2.2.2:0, label: 22
lib entry: 10.40.44.0/24, rev 24
remote binding: lsr: 2.2.2.2:0, label: 23
lib entry: 100.100.100.100/32, rev 26
remote binding: lsr: 2.2.2.2:0, label: 24
lib entry: 200.200.200.200/32, rev 28
remote binding: lsr: 2.2.2.2:0, label: 25

I need to create an ACL to match the label bindings permitted into the LIB. When creating the ACL, be sure to note that inbound label filtering only supports standard ACLs, not extended ACLs.

PE_WEST(config)#access-list 1 permit 200.200.200.200

Now, apply the ACL to the label via the mpls ldp neighbor command.

PE_WEST(config)#mpls ldp neighbor 2.2.2.2 labels accept 1

Verify that LDP is filtering inbound for that LDP neighbor.

PE_WEST#show mpls ldp neighbor 2.2.2.2 detail
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 100.100.100.100:0
TCP connection: 2.2.2.2.646 - 100.100.100.100.11033
State: Oper; Msgs sent/rcvd: 2921/2918; Downstream; Last TIB rev sent 30
Up time: 1d18h; UID: 8; Peer Id 0;
LDP discovery sources:
FastEthernet2/1; Src IP addr: 10.20.22.2
holdtime: 15000 ms, hello interval: 5000 ms
Addresses bound to peer LDP Ident:
10.20.22.2      10.24.24.2      10.12.12.2      2.2.2.2
Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab
LDP inbound filtering accept acl: 1

Finally, check the current LIB from P2.

PE_WEST#show mpls ldp bindings neighbor 2.2.2.2
lib entry: 200.200.200.200/32, rev 28
remote binding: lsr: 2.2.2.2:0, label: 25
PE_WEST#

Great! Exactly what expect. The only LIB entry from 2.2.2.2 is the label for 200.200.200.200/32.

LDP Targeted Hellos.

I wanted to lab up MPLS LDP session protection to reduce the time needed for LDP convergence in the event of a link failure. However, having targeted hellos is a prerequisite. So lets configure it.

Still working off the same topology, I’ll set up and test targeted hello sessions between PE_WEST and P1.

First I am going to shut down the link a P1 towards PE_WEST. The LDP neighbors drop as expected.

P1(config)#int fa1/0
P1(config-if)#shut
4d01h: %OSPF-5-ADJCHG: Process 1, Nbr 100.100.100.100 on FastEthernet1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
4d01h: %LDP-5-NBRCHG: LDP Neighbor 100.100.100.100:0 is DOWN

3d22h: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 is DOWN

Even though that link is down, connectivity between the loopbacks still work fine.

PE_WEST#ping 1.1.1.1 so 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 100.100.100.100
!!!!!

I brought the link back up, and configured targeted hellos between PE_WEST and P1

PE_WEST(config)#mpls ldp neigh 1.1.1.1 targeted ldp

P1(config)#mpls ldp neigh 100.100.100.100 targeted ldp

Now shutting down the link again, the neighbors stay up.

P1#show ip int fa1/0 | i 1/0
FastEthernet1/0 is administratively down, line protocol is down

P1#show mpls ldp neighbor 100.100.100.100 detail
Peer LDP Ident: 100.100.100.100:0; Local LDP Ident 1.1.1.1:0
TCP connection: 100.100.100.100.11194 - 1.1.1.1.646
State: Oper; Msgs sent/rcvd: 35/32; Downstream; Last TIB rev sent 34
Up time: 00:13:26; UID: 10; Peer Id 0;
LDP discovery sources:
Targeted Hello 1.1.1.1 -> 100.100.100.100, active, passive;
holdtime: infinite, hello interval: 10000 ms
Addresses bound to peer LDP Ident:
10.10.11.10     10.20.22.10     100.100.100.100
Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab
Clients: Dir Adj Client

PE_WEST#show mpls ldp discovery
 Local LDP Identifier:
    100.100.100.100:0
    Discovery Sources:
    Interfaces:
        FastEthernet2/0 (ldp): xmit/recv
        FastEthernet2/1 (ldp): xmit/recv
            LDP Id: 2.2.2.2:0
    Targeted Hellos:
        100.100.100.100 -> 1.1.1.1 (ldp): active/passive, xmit/recv
            LDP Id: 1.1.1.1:0

In the output shows the targeted hello between 1.1.1.1 <-> 100.100.100.100. Turn debug up and verify the transport protocol and port for these hellos.

PE_WEST(config)#access-list 103 permit ip host 100.100.100.100 host 1.1.1.1
PE_WEST(config)#access-list 103 permit ip host 1.1.1.1 host 100.100.100.100

PE_WEST#debug ip packet detail 103

3d22h: IP: s=1.1.1.1 (FastEthernet2/1), d=100.100.100.100, len 62, rcvd 23d22h:     UDP src=646, dst=646
3d22h: IP: s=1.1.1.1 (FastEthernet2/1), d=100.100.100.100, len 62, stop process pak for forus packet
3d22h:     UDP src=646, dst=646
3d22h: IP: s=100.100.100.100 (local), d=1.1.1.1 (FastEthernet2/1), len 62, sending
3d22h:     UDP src=646, dst=646
3d22h: IP: s=1.1.1.1 (FastEthernet2/1), d=100.100.100.100, len 62, rcvd 2
3d22h:     UDP src=646, dst=646

It used UDP with src/dst port for the hellos as before. Only instead of the all routers multicast address they are targeted.

With targeted hellos working, next post I can MPLS LDP session protection.

MPLS LDP Neighbor peering – Router ID address not routeable.

By default, the LDP TCP session is established by using the LDP router ID. In most all cases, this will be from a loopback IP address. But what if the a neighbor can not route to the loopback address. Let’s lab it up.

First, I’m going to create a prefix list to block the loopback of P1 into the PE_WEST routing table an see what happens using the same topology.

PE_WEST(config)#ip prefix-list DENY_R1_LOOPBACK deny 1.1.1.1/32
PE_WEST(config)#ip prefix-list DENY_R1_LOOPBACK permit 0.0.0.0/0 le 32

PE_WEST(config)# router ospf 1
PE_WEST(config-router)#distribute-list prefix DENY_R1_LOOPBACK in

PE_WEST#clear mpls ldp neighbor *

After we clear the neighbors, the LDP neighbor to P2 comes back, but not to P1.

PE_WEST# show mpls ldp neighbor | i Peer
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 100.100.100.100:0

Looking at the show mpls ldp discovery command, let’s see if there is anything discovered on the interface to P1.

PE_WEST# show mpls ldp discovery detail
Local LDP Identifier:
100.100.100.100:0
Discovery Sources:
Interfaces:
FastEthernet2/0 (ldp): xmit/recv
Hello interval: 5000 ms; Transport IP addr: 100.100.100.100
LDP Id: 1.1.1.1:0; no route to transport addr
Src IP addr: 10.10.11.2; Transport IP addr: 1.1.1.1
Hold time: 15 sec; Proposed local/peer: 15/15 sec
FastEthernet2/1 (ldp): xmit/recv
Hello interval: 5000 ms; Transport IP addr: 100.100.100.100
LDP Id: 2.2.2.2:0
Src IP addr: 10.20.22.2; Transport IP addr: 2.2.2.2
Hold time: 15 sec; Proposed local/peer: 15/15 sec

There it shows the problem. There is no route to the establish the TCP sessions as shown above. Its pretty easy to see when it says “no route to transport address”. Verify in the routing table.

PE_WEST#show ip route 1.1.1.1
% Network not in table

I know the router can not route to 1.1.1.1 due to the distribute list placed on the router.

By default the transport ip address is that of the LDP router ID. Can this be changed? Sure it can. The interface command mpls ldp discovery transport-address interface will use the ip address of that specific interface for LDP session negotiation, instead of the loopback ip. In this scenario, not being able to route to 1.1.1.1 is the problem. Therefore, I need to change the transport address FROM P1 to PE_WEST. I’ll place that command on the fa1/0 interface of P1 and see what happens.

P1(config)#int fa1/0
P1(config-if)#mpls ldp discovery transport-address interface

After this command is entered the LDP neighbor comes up. Looking at the mpls ldp discovery details.

PE_WEST# show mpls ldp discovery detail
Local LDP Identifier:
100.100.100.100:0
Discovery Sources:
Interfaces:
FastEthernet2/0 (ldp): xmit/recv
Hello interval: 5000 ms; Transport IP addr: 100.100.100.100
LDP Id: 1.1.1.1:0
Src IP addr: 10.10.11.2; Transport IP addr: 10.10.11.2
Hold time: 15 sec; Proposed local/peer: 15/15 sec

That’s what I expected. The Transport IP address changed from 1.1.1.1 to 10.10.11.2. Since 10.10.11.2 is routable at PE_WEST, the session is established. Check the TCP session for this connection.

PE_WEST#show mpls ldp nei | i Peer|TCP
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 100.100.100.100:0
TCP connection: 2.2.2.2.646 - 100.100.100.100.11033
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 100.100.100.100:0
TCP connection: 10.10.11.2.646 - 100.100.100.100.11187

There is another item to note. Putting the mpls ldp discovery transport-address interface on one interface only changed the TCP sessions establishment from that side. The connection is from 10.10.11.2 <-> 100.100.100.100.

MPLS LDP Authentication

LDP sessions can be protected by using MD5 Authentication, and can be configured between a pair of specific neighbors. Going back to the topology in setting basic mpls ldp peering I am going to configure LDP authentication between PE_WEST <-> P1 and between PE_WEST <-> P2.

Authentication is done with the global mpls ldp neighbor command.

mpls ldp neighbor [vrf vpn-name] ip-address [password [0-7] password-string]

This commands makes the router generate an MD5 digest key for on the TCP connections and check the MD5 digest key for segment received from the TCP connection.

To make these passwords mandatory you need the mpls ldp password required command.

Configure PE_WEST with for authentication.

PE_WEST(config)#mpls ldp neighbor 1.1.1.1 password CISCO
PE_WEST(config)#mpls ldp neighbor 2.2.2.2 password CISCO

As soon as the commands are entered, the LDP neighbors drop.

2d01h: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 is DOWN
2d01h: %TCP-6-BADAUTH: No MD5 digest from 1.1.1.1(646) to 100.100.100.100(11003) (RST)
2d01h: %LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 is DOWN
2d01h: %TCP-6-BADAUTH: No MD5 digest from 2.2.2.2(646) to 100.100.100.100(11005) (RST)

Also, errors showing bad TCP Auth are seen in the logs.

2d01h: %TCP-6-BADAUTH: No MD5 digest from 1.1.1.1(646) to 100.100.100.100(11004)
2d01h: %TCP-6-BADAUTH: No MD5 digest from 2.2.2.2(646) to 100.100.100.100(11005)

Looking at the logs on P1 and P2, the only log seen is the LDP neighbor went down. These TCP BadAuth messages are not seen on those logs. Now configure LDP auth on P1 and P2.

P1(config)#mpls ldp neighbor 100.100.100.100 password CISCO

P2(config)#mpls ldp neighbor 100.100.100.100 password CISCO

Verify the LDP neighbors came back up on PE_WEST.

PE_WEST#show mpls ldp neighbor
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 100.100.100.100:0
TCP connection: 2.2.2.2.646 - 100.100.100.100.11030
State: Oper; Msgs sent/rcvd: 22/22; Downstream
Up time: 00:04:31
LDP discovery sources:
FastEthernet2/1, Src IP addr: 10.20.22.2
Addresses bound to peer LDP Ident:
10.20.22.2      10.24.24.2      10.12.12.2      2.2.2.2
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 100.100.100.100:0
TCP connection: 1.1.1.1.646 - 100.100.100.100.11031
State: Oper; Msgs sent/rcvd: 20/20; Downstream
Up time: 00:03:10
LDP discovery sources:
FastEthernet2/0, Src IP addr: 10.10.11.2
Addresses bound to peer LDP Ident:
10.10.11.2      10.13.13.1      10.12.12.1      1.1.1.1

In this lab I am running 12.2(25)S14. In newer IOS releases the authentication can be confirmed between neighbors with the show mpls ldp neighbor password command.

Setting Basic MPLS LDP peering

In the next series of post I want to go through setting up a MPLS VRF system, and work on from MPLS TE, which is a subject which I have not worked on. Yeah, I read through a couple of docs but have never implemented it myself. My goal at the end of their series of post it to cover the MPLS TE topics as I learn them.

Before setting up a anything to do with MPLS TE, the basic MPLS network needs to be created. This is the topology I have set up.

All of the layer 2 and 3 work as been completed. PE_WEST has a loopback of 100.100.100.100 and PE_EAST has a loopback of 200.200.200.200.

Testing end to end.

PE_WEST#ping 200.200.200.200 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.200.200.200, timeout is 2 seconds:
Packet sent with a source address of 100.100.100.100
!!!!!

Now, time to enable basic MPLS.

On all P/PE routers, we’ll enable MPLS and force the router-ID to be loopback0.

mpls ip
mpls ldp router-id lo0 force

After this, enable MPLS on all if the links withing the P network.

PE_WEST(config)#interface FastEthernet2/0
PE_WEST(config-if)# mpls ip
PE_WEST(config-if)#

Let’s verify on PE_WEST that the links are up.

PE_WEST#show mpls int
Interface              IP            Tunnel   BGP Static Operational
FastEthernet2/0        Yes (ldp)     No       No  No     Yes
FastEthernet2/1        Yes (ldp)     No       No  No     Yes

Looking at the LDP neighbors from PE_WEST.

PE_WEST#show mpls ldp nei
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 100.100.100.100:0
TCP connection: 2.2.2.2.646 - 100.100.100.100.11001
State: Oper; Msgs sent/rcvd: 1669/1665; Downstream
Up time: 1d00h
LDP discovery sources:
FastEthernet2/1, Src IP addr: 10.20.22.2
Targeted Hello 100.100.100.100 -> 2.2.2.2, active, passive
Addresses bound to peer LDP Ident:
10.20.22.2      10.24.24.2      10.12.12.2      2.2.2.2
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 100.100.100.100:0
TCP connection: 1.1.1.1.646 - 100.100.100.100.11002
State: Oper; Msgs sent/rcvd: 1668/1669; Downstream
Up time: 1d00h
LDP discovery sources:
FastEthernet2/0, Src IP addr: 10.10.11.2
Addresses bound to peer LDP Ident:
10.10.11.2      10.13.13.1      10.12.12.1      1.1.1.1

 

Another item to note is how LDP is established. In this case when two neighbors are directly connected, the router sends out a hello message via UDP to the multicast address for all routers on a subnet (224.0.0.2). To initiate the TCP sessions, the router with the higher transport address (in this case loopback ID) will take the active role and and initiate the TCP sessions. This can be seen in the output above by the target hello line showing the active and passive router. Also, look at the TCP connection < TCP connection: 2.2.2.2.646 – 100.100.100.100.11001 >. From this we know 100.100.100.100 is initiating the session.

 

Next I finished enabling MPLS across the SP network. All the checks should be done across the SP network. In our case all the LDP peers are up. I won’t post them for brevity.

Home lab being revamped

One item I wanted to do lately is to revamp my lab. I am not really sure at the moment what I want to do, but I am thinking of setting up a core network with servers, and then set up 2 “branch” offices. I have my whole basement wired with RJ-45 from my rack. So, I can create a small office with a router/switch anywhere in the basement. Currently I have about 6 switches to use, so I am thinking about 4 for the core and 1 for each remote office.

My lab is currently configured for the INE workbook layout, and am thinking about leaving it the same. Something its not bad to throw one of their labs on there just as a small refresher. But, I really have no need to frame relay in my lab except for cert testing. I might just remove it. Not sure.

There are about 6 computers I have ready to go as well. Two with windows XP, two with Ubuntu, and two with Fedora. I think the windows ones will be for each end user in a remote office, and the linux machines running services.There are a few things I have not done in a while which I will need to do, such as setting up a DNS server for my lab.

I’ll keep the blog up to date with what I am working on in the lab.

BGP Influencing Inbound Routing – Med

In this post I’ll continue from BGP Influencing Inbound Routing – AS Path. The topology and initial setup are identical. However this time we’ll use MED to influence.

MED is an BGP optional-nontransitive attribute and is not always known by peers. In fact, peers can ignore updates which it is included, and not pass it along to peers. The lower MED value is preferred.

Start with a sanity check to ensure the system is back to its default state.

R4#show ip bgp | b Network

Network          Next Hop            Metric LocPrf Weight Path
*  100.1.1.1/32     10.1.34.3                              0 100 i
*>                  10.1.14.1                0             0 100 i
*  100.2.2.2/32     10.1.14.1                              0 100 i
*>                  10.1.34.3                              0 100 i
*  100.3.3.3/32     10.1.14.1                              0 100 i
*>                  10.1.34.3                0             0 100 i
*> 100.4.4.4/32       0.0.0.0                0             32768 i

Lets say all routers from even routers (R2) should come in to R1, and from odd routers (R1, R3) should come in R3. No we will use MED to perform this.

To do this, we’ll set the MED higher for odd routes from R1, and set the MED higher to even routes from R3.

**** R1 Configuration

R1(config)#ip prefix-list ODD_ROUTER_ROUTES seq 10 permit 100.1.1.1/32
R1(config)#ip prefix-list ODD_ROUTER_ROUTES seq 20 permit 100.3.3.3/32

R1(config)#route-map TO_R4_OUT per 10
R1(config-route-map)#match ip add prefix-list ODD_ROUTER_ROUTES
R1(config-route-map)#set metric 1111
R1(config-route-map)#route-map TO_R4_OUT per 100
R1(config-route-map)#set metric 1

R1(config-route-map)#router bgp 100
R1(config-router)#neighbor 10.1.14.4 route-map TO_R4_OUT out

***** R3 Configuration

R3(config)#ip prefix-list EVEN_ROUTER_ROUTES per 100.2.2.2/32

R3(config)#route-map TO_R4_OUT per 10
R3(config-route-map)#match ip address prefix-list EVEN_ROUTER_ROUTES
R3(config-route-map)#set metric 3333
R3(config-route-map)#route-map TO_R4_OUT per 100
R3(config-route-map)#set metric 3

R3(config)#router bgp 100
R3(config-router)#neighbor 10.1.34.4 route-map TO_R4_OUT out

Check the results.

R4#show ip bgp | b Net
Network          Next Hop            Metric LocPrf Weight Path
*> 100.1.1.1/32     10.1.34.3                  3             0 100 i
*                             10.1.14.1             1111             0 100 i
*> 100.2.2.2/32     10.1.14.1                  1             0 100 i
*                             10.1.34.3             3333             0 100 i
*  100.3.3.3/32          10.1.14.1             1111             0 100 i
*>                       10.1.34.3                  3             0 100 i
*> 100.4.4.4/32        0.0.0.0                  0             32768 i

All is working as expected. The even router routes prefer the next hop of 10.1.14.1 and the odd one prefer 10.1.34.3. The paths can be verified with the traceroute command if desired.

The same results were accomplished in the end with both MED and AS perpend, however is most commercial deployments MED is never used.