MPLS networking case description

Source: Internet
Author: User
Tags bit set

Networking requirements:
1. Configure the basic information of each vro
2. Configure OSPF specifications and change the network type to point-to-point
3. All routers run OSPF, RT4 E3/0, RT5 E3/0 network to OSPF, RT1E3/0 re-publish directly to OSPF
4. All routers run MPLS, And the Label Distribution Protocol is LDP.
5. Run IBGP in RT4 and RT5 and publish E3/1 to BGP.
Previous Configuration
The IGP configuration is as follows:
RT1:
Router ospf 1
Router-id 1.1.1.1
Passive-interface default
No passive-interface Serial0/1
No passive-interface Serial0/2
Redistribute connected metric 1000 subnets
Network 1.1.1.1 0.0.0.0 area 0
Network 10.0.12.0 0.0.0.3 area 0
Network 10.0.20.0.0.0.3 area 0
RT2:
Router ospf 1
Router-id 2.2.2.2
Passive-interface default
No passive-interface Serial0/0
No passive-interface Serial0/1
No passive-interface FastEthernet1/0
Network 2.2.2.2 0.0.0.0 area 0
Network 10.0.12.0 0.0.0.3 area 0
Network 10.0.23.0 0.0.0.3 area 0
Network 10.0.24.0 0.0.0.3 area 0
Interface f1/0
Ip ospf network point-to-point
RT3:
Router ospf 1
Router-id 3.3.3.3
Passive-interface default
No passive-interface Serial0/0
No passive-interface Serial0/1
No passive-interface FastEthernet1/0
Network 3.3.3.3 0.0.0.0 area 0
Network 10.0.20.0.0.0.3 area 0
Network 10.0.23.0 0.0.0.3 area 0
Network 10.0.35.0 0.0.0.3 area 0
Interface f1/0
Ip ospf network point-to-point
RT4:
Router ospf 1
Router-id 4.4.4
Passive-interface default
No passive-interface Serial0/0
Network 4.4.4.4 0.0.0.0 area 0
Network 10.0.24.0 0.0.0.3 area 0
Network 172.16.4.0 0.0.0.255 area 0
RT5:
Router ospf 1
Router-id 5.5.5
Passive-interface default
No passive-interface Serial0/0
Network 5.5.5.5 0.0.0.0 area 0
Network 10.0.35.0 0.0.0.3 area 0
Network 172.16.5.0 0.0.0.255 area 0
MPLS Configuration:
RT1, RT2, RT3, RT4, and RT5 are configured as follows:
Global configuration mode:
Ip cef // CEF must be enabled to run MPLS
Mpls ip // enable MPLS
Mpls label protocol ldp // select MPLS label Distribution protocol as LDP (TDP by default, CISCO private)
Enable MPLS on all interfaces in the MPLS network.
RT1:
Int s0/1
Mpls ip
Int s0/2
Mpls ip
RT2 S0/0, F1/0, S0/1, RT3 S0/0, F1/0, S0/1, RT4, RT5 S0/1 do the above Configuration
IBGP Configuration:
RT4:
Router bgp 65000
No synchronization
Network 172.17.4.0 mask 255.255.255.0
Neighbor 5.5.5 remote-as 65000
Neighbor 5.5.5.5 update-source Loopback0
Neighbor 5.5.5.5 next-hop-self
No auto-summary
RT5:
Router bgp 65000
No synchronization
Network 172.17.5.0 mask 255.255.255.0
Neighbor 4.4.4 remote-as 65000
Neighbor 4.4.4 update-source Loopback0
Neighbor 4.4.4 next-hop-self
No auto-summary

RT1 # show ip cef detail // view CEF details
4.4.4.4/32, version 23, epoch 0, cached adjacency to Serial0/1
0 packets, 0 bytes
Tag information set
Local tag: 23 // local tag 18, that is, incoming tag, SWAP)
Fast tag rewrite with Se0/1, point2point, tags imposed: {22} // press tag PUSH 22
Via 10.0.12.2, Serial0/1, 0 dependencies
Next hop 10.0.12.2, Serial0/1
Valid cached adjacency
Tag rewrite with Se0/1, point2point, tags imposed: {22}
RT1 # show mpls ldp discovery // view LDP found messages
Local LDP Identifier:
1.1.1.1: 0 // The local LDP is identified as 1.1.1.1
Discovery Sources:
Interfaces: // LDP indicates the source of the message.
Serial0/1 (ldp): xmit/recv // send or receive LDP found messages from S0/1 Interface
LDP Id: 2.2.2.2: 0 // ldp id is 2.2.2.2
Serial0/2 (ldp): xmit/recv // send or receive LDP found messages from S0/2 Interface
LDP Id: 3.3.3.3: 0 // ldp id is 3.3.3.3
RT1 # show mpls ldp neighbor // view LDP neighbor Information
Peer LDP Ident: 3.3.3.3: 0; Local LDP Ident 1.1.1.1: 0 // Peer LDP ID3.3.3.3 and Local ldp id 1.1.1.1
TCP connection: 3.3.3.3.37601-1.1.1.1.646 // TCP connection IP + port number
State: running; Msgs sent/rcvd: 30/31; Downstream // status: Running
Up time: 00:14:16
LDP discovery sources:
Serial0/2, Src IP addr: 10.0.13.2 // LDP finds the source and IP of the message
Addresses bound to peer LDP Ident: // address where the peer LDP needs to bring up the MPLS Label
10.0.13.2 3.3.3.3 10.0.23.2 10.0.35.1
Peer LDP Ident: 2.2.2.2: 0; Local LDP Ident 1.1.1.1: 0
TCP connection: 2.2.2.2.54420-1.1.1.1.646
State: enabled; Msgs sent/rcvd: 20/20; Downstream
Up time: 00:04:34
LDP discovery sources:
Serial0/1, Src IP addr: 10.0.12.2
Addresses bound to peer LDP Ident:
10.0.12.2 2.2.2.2 10.0.23.1 10.0.24.1
Note: MPLS Label Distribution is random (from 16 to ascending, 0-15 is recognized as system label). You may have different tags than me!
Let's analyze the propagation of the route 172.16.4.0 of RT4 In the MPLS network:
When MPLS is run on RT4, labels are distributed to all IGP route tables (no label is assigned for BGP routes). RT2 receives the labels distributed by RT4.
RT2 # show mpls ldp bindings // display the label information library
Tib entry: 172.16.4.0/24, rev 18 // route entry
Local binding: tag: 20 // The local distribution label is 20 (sent to all LDP neighbors)
Remote binding: tsr: 4.4.4.4: 0, tag: imp-null // special tag 3 distributed by 4.4.4.4 (used for the last-to-last hop pop-up)
Remote binding: tsr: 3.3.3.3: 0, tag: 20 // 3.3.3.3 distributed tag 20
Remote binding: tsr: 1.1.1.1: 0, tag: 24 // 1.1.1.1 The distribution label is 24
RT2 # show mpls forwarding-table // view the MPLS forwarding table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
Tag or VC or Tunnel Id switched interface
20 Pop tag 172.16.4.0/24 0 Se0/1 point2point
Local tag 20 outbound tag 3 network prefix 0 indicates IPV4 outbound interface next hop (point-to-point)
RT2 # show ip route
O 172.16.4.0 [110/110] via 10.0.24.2, 00:09:31, Serial0/1
As can be seen from the above, the MPLS Router receives Multiple labels of the same route and takes priority, mainly based on the next hop in the IGP route table, the next hop selected by MPLS is the same as the IGP route table.
RT3 # show mpls ldp bindings
Tib entry: 172.16.4.0/24, rev 18
Local binding: tag: 20 // The local distribution label is 20 (sent to all LDP neighbors)
Remote binding: tsr: 5.5.5.5: 0, tag: 23
Remote binding: tsr: 2.2.2.2: 0, tag: 20 // you can see from RT2 that the label it distributes for this route is 20
Remote binding: tsr: 1.1.1.1: 0, tag: 24
RT3 # show mpls forwarding-table // view the MPLS forwarding table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
Tag or VC or Tunnel Id switched interface
20 20 172.16.4.0/24 0 Fa1/0 10.0.23.1
172.16.4.0 is 20 (local label). The outbound label is 20, the next hop is 10.0.23.1, And the next hop is F1/0.
RT3 # show ip route
O 172.16.4.0 [110/210] via 10.0.23.1, 00:11:23, FastEthernet1/0
It can be seen that the first hop of MPLS selection is based on the IGP route table. If the IGP route table does not have this route, it will not enter the MPLS Forwarding Table.
RT5:
RT5 # show mpls ldp bindings
Tib entry: 172.16.4.0/24, rev 24
Local binding: tag: 23
Remote binding: tsr: 3.3.3.3: 0, tag: 20 // The tag sent by RT3.
RT5: show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
Tag or VC or Tunnel Id switched interface
23 20 172.16.4.0/24 0 Se0/0 point2point
RT5 # show ip route
O 172.16.4.0 [110/310] via 10.0.35.1, 02:00:34, Serial0/0
Similar to the above, we will not describe it here!
MPLS does not distribute labels for BGP routes. If the received route does not exist in IGP, MPLS Forwarding is not performed!
For example, there are two BGP routes in RT5, one generated by itself and the other learned:
RT5 (config-if) # do show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> I172.17.4.0/24 4.4.4.4 0 100 0 I
*> 172.17.5.0/24 0.0.0.0 0 32768 I
We can view the tag information library on RT4.
RT3 # show mpls ldp bindings
Tib entry: 172.17.5.0/24, rev 34
Remote binding: tsr: 5.5.5.5: 0, tag: imp-null // we can see that RT5 has assigned a label 3 for this route (the label will be distributed here because it is a direct connection route ,) the distribution label 172.17.4.0/24 is not seen here, because it is a BGP Route, MPLS is not a BGP Route distribution label
RT3 # show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
Tag or VC or Tunnel Id switched interface
16 Pop tag 1.1.1.1/32 0 Se0/0 point2point
17 Pop tag 2.2.2.2/32 0 Fa1/0 10.0.23.1
18 Pop tag 10.0.12.0/30 0 Fa1/0 10.0.23.1
Pop tag 10.0.12.0/30 0 Se0/0 point2point
19 Pop tag 10.0.24.0/30 0 Fa1/0 10.0.23.1
20 22 4.4.4.4/32 30679 Fa1/0 10.0.23.1
21 Pop tag 5.5.5.5/32 5459 Se0/1 point2point
22 23 172.16.4.0/24 31211 Fa1/0 10.0.23.1
23 Pop tag 172.16.5.0/24 0 Se0/1 point2point
We did not see the 172.17.5.0/24 CIDR Block in the MPLS Forwarding of RT3. Because the route table in RT3 does not exist, it will not enter the MPLS Forwarding Table!
Let's analyze the communication process between RT5 172.16.5.1 and 172.16.4.1:
First, RT5 queries the MPLS Forwarding Table and finds the corresponding route entry with the label number 20 (see the previous section for the forwarding table involved ), therefore, a four-byte MPLS label is added before the IP header of the packet. The label number is 20, the EXP bit is 0, and the stack base bit is 1, at the same time, copy the TTL in the IP address to the MPLS label (which is sent here as 255), and then encapsulate it as the HDLC frame sending. After RT3 is received from the S0/1 interface, remove the layer-2 frame header, view the MPLS label incoming label number 20, find the MPLS Forwarding Table outgoing label number 20, the outbound interface is F1/0, the MPLS label number is 20, the EXP bit is 0, and the stack bottom is 1, at the same time, the TTL-1 (forwarding an MPLS TTL-1 but the TTL in the IP is unchanged, it only involves two layers), and then encapsulated into Ethernet frame transmission, RT2 receives data from F1/0, split the layer-2 encapsulation, check the MPLS incoming label number as 20, and then find the MPLS Forwarding Table. The outgoing label is the Pop tag (the last-to-second hop of the special label 3 is displayed) delete the MPLS label and copy the TTL In the MPLS label to the TTL of the IP Message. Then, find the Global IP route table, TTL-1 = 253 encapsulated into an Ethernet frame, and then forwarded to the next hop, RT4 received data directly forwarded to the corresponding interface, and then sent to RT5 response packet, the above process of the inverse process!
Supplement: several tags that the E-LSR may distribute when the last-to-second hop pops up
Label 3 is implicitly empty label (no label is added for upstream LSR, And the outermost layer MPLS label is displayed)
Label 0 IPV4 display empty label (upstream LSR will add label 0, after the E-LSR receives, directly pop up label for IVP4 forwarding)
Label 2 IPV6 displays empty labels (upstream LSR adds label 0, after the E-LSR receives it, the label pops up directly for IVP6 forwarding)
MTU in MPLS:
Question 1:
RT5 # ping 172.16.4.1 source 172.16.5.1 size 1500 df-bit
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.5.1
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
Here, I can PING the full package 1500 and cannot pass the test without sharding,
RT5 # ping 172.16.4.1 source 172.16.5.1 size 1496 df-bit
Type escape sequence to abort.
Sending 5, 1496-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.5.1
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/88/132 MS
RT5 # ping 172.16.4.1 source 172.16.5.1 size 1497 df-bit
PING packet 1496 is not sharded but can pass
Type escape sequence to abort.
Sending 5, 1497-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.5.1
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
PING packet 1497 is not sharded but cannot pass
Analysis: When an IP packet is forwarded on the MPLS link, the length of the packet increases as the MPLS label is pressed. The original 1500 bytes are changed to 1504 (1497 + 4 = 1501) all of them exceed the default MTU1500 byte of MPLS, so it doesn't work. However, 1496 + 4 = 1500 does not pass through sharding, so it can pass!
Question 2:
Modify the mpls mtu of all interfaces on the link to 1600
R5S0/0, RT3S0/1, F1/0, RT2S0/1, F1/0, and R4S0/0 are all modified as follows:
Int s0/0
Mpls mtu 1600
Other similar
RT5 # ping 172.16.4.1 source 172.16.5.1 size 1500 df-bit
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.5.1
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/104/164 MS
PING now!
RT5 # ping 172.16.4.1 source 172.16.5.1 size 1501 df-bit
Type escape sequence to abort.
Sending 5, 1501-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.5.1
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)
If I ping packet 1501 and don't split it, why can't I do it!
Analysis: 1501 + 4 = 1505 should be less than 1600! I started to apply this error. Note that the MTU of another interface is 1500 bytes by default, that is, the packet size of the network layer is 1500 bytes without sharding, 1501 the package size is greater than 1500 when no parts are sharded. Therefore, if it is encapsulated as a Layer 2 package, the system will prompt that the package is too large, leading to encapsulation failure! If it is 1500, it can be encapsulated, and then the MPLS label is greater than 1500, it has nothing to do with this interface MTU, it only has three layers, it does not matter if you add a few more MPLS labels, as long as mpls mtu is greater than or equal to it!
Question 3:
If I do not change the MPLS MTU of all interfaces on this link, only R5S0/0, RT3S0/1, RT2S0/1, and R4S0/0 are modified.
The MTU of the port is 1600, And the mpls mtu of F1/0 and RT2F1/0 of RT3 is 1600. can ping packet 500 fail to be split?
The configuration is as follows:
RT4 and RT5 are configured as follows:
Int s0/0
Mtu 1600
RT2 and RT3 are configured as follows:
Int s0/1
Mtu 1600
Int f1/0
Mpls mtu 1600
RT5 # ping 172.16.4.1 source 172.16.5.1 size 1500 df-bit
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.5.1
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/88/136 MS
Obviously, it is also accessible! The reason is that the MTU of the interface is modified at the same time. Because I used a simulator for experiment, maybe IOS is too low to modify the MTU of the Ethernet interface, so I cannot demonstrate PNG more than 1500 unsharded packages.
RT2 # show mpls int s0/1 detail // view detailed information of the MPLS Interface
Interface Serial0/1:
IP labeling enabled (ldp ):
Interface config
LSP Tunnel labeling not enabled
BGP tagging not enabled
Tagging operational
Fast Switching Vectors:
IP to MPLS Fast Switching Vector
MPLS Turbo Vector
MTU = 1600 // I only modified the MTU of the interface
Question 4:
S0/2 of RT5pingRT1
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.0.13.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/63/92 MS
Why can't I make any changes! Because they all do the penultimate hop pop-up, there is no MPLS Forwarding. IP Forwarding! You can capture packets!

Author: "Mortal World"

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.