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.
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.
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
No comments:
Post a Comment