Configuring MTU Size

As mentioned previously in this chapter, the addition of one or more labels to a packet traversing an MPLS network might cause the violation of the MTU size parameter. This is one of the most common issues experienced in MPLS deployments and should not be taken lightly by any means. The introduction of jumbo frames, giants, or baby giants, however one might wish to name them, into a LAN environment can have far-reaching effects.

This is typically only an issue on LAN interfaces where the MTU size is usually around 1500 bytes. Most WAN types today have much larger MTU sizes by default, with many of them taking on a dynamic ability to adjust.

The MTU size must be increased by a value equal to or greater than the additional byte count of the imposed label stack. Given that a label is 4 bytes in length, an MTU of 1504 may be feasible so long as only a single label is imposed. When MPLS Traffic Engineering (MPLS-TE) or MPLS VPNs have been deployed, additional size is needed. In cases where both are in use, an MTU size of 1512 is needed.

The alteration of the MTU is simple, though not typical of an MTU change. This MTU change is MPLS specific. At interface configuration mode, enter

BM2851(config-if)#mpls mtu 1512

This command sets an MTU on the interface that is specific to label switching rather than setting it for all traffic types. The valid range of MTU sizes is 64 to 65,535 bytes.

With the MTU modified, the configuration example previously presented has obviously changed. The interface configuration itself now looks like what Example 10-3 shows.

Example 10-3 MTU Configuration interface GigabitEthernet0/1 ip address 10.10.1.1 255.255.255.0 duplex full speed 1000

mpls label protocol ldp mpls ip mpls mtu 1512

Figure 10-1 provides some additional clarity in the setting of the MTU size.

Figure 10-1 MPLS MTU Configuration Requirements p cef nterface GigabitEthernet0/1 ip address 10.10.1.1 255.255.255.0 duplex full speed 1000 mpls label protocol Idp mpls ip mpls mtu 1512

As evident in Figure 10-1, the typical MPLS configuration that has been discussed up to this point is entered on both MPLS routers. However, the switch must also be configured for jumbo frames. The command set that needs to be entered into the configuration depends on whether the switch runs CatOS or IOS software.

To ensure that LDP adjacencies have been established, the show mpls ldp neighbor command can be entered. Example 10-4 shows sample output from this command.

Example 10-4 show mpls ldp neighbor Command Output BM2851#sh mpls ldp neighbor

Peer LDP Ident: 192.168.1.1:0; Local LDP Ident 3.3.3.3:0 TCP connection: 192.168.1.1.17080 - 3.3.3.3.646 State: Oper; Msgs sent/rcvd: 17/18; Downstream Up time: 00:07:01 LDP discovery sources:

GigabitEthernet0/1, Src IP addr: 10.10.1.2 Addresses bound to peer LDP Ident:

Jumbo frames must be enabled on the switch as well.

ip cef interface GigabitEthernet0/0 ip address 10.10.1.2 255.255.255.0 duplex full speed 1000 mpls label protocol Idp mpls ip mpls mtu 1512

BM2851#

In the example, only a single peer is established. The output shows that the state of the connection is operational. Also shown are the peer LDP identifiers for the remote peer.

If it becomes necessary to monitor the label exchange in real time, the debug mpls ldp bindings command is available. Example 10-5 provides sample output from this command.

Example 10-5 debug mpls ldp bindings Command Output

BM2851#debug mpls ldp bindings

LDP Label Information Base (LIB) changes debugging is on BM2851#

000049: Apr 20 19:18:33.271: tib: find route tags: 10.10.1.0/24, Gi0/1, nh 0.0.0.0, res nh 0.0.0.0

000050: Apr 20 19:18:33.271: tagcon: announce labels for: 10.10.1.0/24; nh 0.0.0.0, Gi0/

1, inlabel imp-null, outlabel unknown (from 0.0.0.0:0), find route tags 000051: Apr 20 19:18:33.271: tagcon: tc_iprouting_table_change: 10.10.1.0/255.255.255.0, event 0x1

000052: Apr 20 19:18:33.271: tagcon: rib change: 10.10.1.0/255.255.255.0; event 0x1; ndb attrflags 0x1000220; ndb->pdb_index 0x0 000053: Apr 20 19:18:33.271: tib: find route tags: 1.1.1.1/32, Lo1, nh 0.0.0.0, res nh 0.0.0.0

000054: Apr 20 19:18:33.271: tagcon: announce labels for: 1.1.1.1/32; nh 0.0.0.0, Lo1, inlabel imp-null, outlabel unknown (from 0.0.0.0:0), find route tags

000055: Apr 20 19:18:33.271: tagcon: tc_iprouting_table_change: 1.1.1.1/255.255.255.255, event 0x1

000056: Apr 20 19:18:33.271: tagcon: rib change: 1.1.1.1/255.255.255.255; event 0x1; ndb attrflags 0x1000220; ndb->pdb_index 0x0 000057: Apr 20 19:18:33.271: tib: find route tags: 2.2.2.2/32, Lo2, nh 0.0.0.0, res nh 0.0.0.0

000058: Apr 20 19:18:33.271: tagcon: announce labels for: 2.2.2.2/32; nh 0.0.0.0, Lo2, inlabel imp-null, outlabel unknown (from 0.0.0.0:0), find route tags 000059: Apr 20 19:18:33.271: tagcon: tc_iprouting_table_change: 2.2.2.2/255.255.255.255, event 0x1

000060: Apr 20 19:18:33.271: tagcon: rib change: 2.2.2.2/255.255.255.255; event 0x1; ndb attrflags 0x1000220; ndb->pdb_index 0x0

000061: Apr 20 19:18:33.271: tib: find route tags: 3.3.3.3/32, Lo3, nh 0.0.0.0, res nh 0.0.0.0

000062: Apr 20 19:18:33.271: tagcon: announce labels for: 3.3.3.3/32; nh 0.0.0.0, Lo3, inlabel imp-null, outlabel unknown (from 0.0.0.0:0), find route tags 000063: Apr 20 19:18:33.271: tagcon: tc_iprouting_table_change: 3.3.3.3/255.255.255.255, event 0x1

000064: Apr 20 19:18:33.275: tagcon: rib change: 3.3.3.3/255.255.255.255; event 0x1; ndb attrflags 0x1000220; ndb->pdb_index 0x0 000065: Apr 20 19:18:33.275: tib: find route tags: 172.16.0.0/16, Gi0/1, nh 10.10.1.2, res nh 10.10.1.2

000066: Apr 20 19:18:33.275: tagcon: announce labels for: 172.16.0.0/16; nh 10.10.1.2, Gi0/ 1, inlabel 16, outlabel imp-null (from 192.168.1.1:0), find route tags

000067: Apr 20 19:18:33.275: tagcon: tc_iprouting_table_change: 172.16.0.0/255.255.0.0, event 0x1

000068: Apr 20 19:18:33.275: tagcon: rib change: 172.16.0.0/255.255.0.0; event 0x1; ndb attrflags 0x0; ndb->pdb_index 0x2 000069: Apr 20 19:18:33.275: tib: find route tags: 192.168.1.0/24, Gi0/1, nh 10.10.1.2, res nh 10.10.1.2

000070: Apr 20 19:18:33.275: tagcon: announce labels for: 192.168.1.0/24; nh 10.10.1.2,

Gi0/1, inlabel 17, outlabel imp-null (from 192.168.1.1:0), find route tags 000071: Apr 20 19:18:33.275: tagcon: tc_iprouting_table_change: 192.168.1.0/255.255.255.0, event 0x1

Example 10-5 debug mpls ldp bindings Command Output (Continued)

000072: Apr 20 19:18:33.275: tagcon: rib change: 192.168.1.0/255.255.255.0; event 0x1; ndb attrflags 0x1000000; ndb->pdb_index 0x2 000073: Apr 20 19:18:33.279: tib: find route tags: 192.168.1.2/32, Gi0/1, nh 10.10.1.2, res nh 10.10.1.2

000074: Apr 20 19:18:33.279: tagcon: announce labels for: 192.168.1.2/32; nh 10.10.1.2,

Gi0/1, inlabel 18, outlabel imp-null (from 192.168.1.1:0), find route tags 000075: Apr 20 19:18:33.279: tagcon: tc_iprouting_table_change: 192.168.1.2/

255.255.255.255, event 0x1 000076: Apr 20 19:18:33.279: tagcon: rib change: 192.168.1.2/255.255.255.255; event 0x1; ndb attrflags 0x1000000; ndb->pdb_index 0x2

BM2851#

The output shows the exchange of label information regarding each network prefix in the routing table. The highlighted portion shows an inlabel of 17 and an outlabel of imp-null (value = 3). This signifies that the label should be popped.

Was this article helpful?

0 0

Post a comment