Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Bronze

MPLS , DF bit set

 

Hi everybody

 

According to my book, if an LSR can not fragment the labelled packet because of DF bit, following will occur:

 

  Only if the IP header has the Don’t Fragment (DF) bit set does the LSR not fragment the IP packet, but it drops the packet and returns an ICMP error message “Fragmentation needed and do not fragment bit set” (ICMP type 3, code 4) to the originator of the IP packet. As with the ICMP message “time exceeded” (type 11, code 0), which is sent when the TTL expires of a labeled packet, the “Fragmentation needed and do not fragment bit set” ICMP message is sent, using a label stack that is the outgoing label stack for the packet that caused the ICMP message to be created. This means that the ICMP message travels further down the LSP until it reaches the egress LSR of that LSP. Then it is returned to the originator of the packet with the DF bit set.

 

 

However, when i put this claim  to test, i do not see that behavior.

 

R5---R1 f0/1-----R2----R3---R4

 

 

Above R1 f0/1  mpls mtu 1400

 

 

On R5, i generated a ping of 1500 , DF bit set.   R1 should send ICMP error towards R4 which then send it to R5.

 

 

R5#debug ip icmp
ICMP packet debugging is on

 

R5#ping
Protocol [ip]:
Target IP address: 4.4.4.4
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)

 

 

 

I do not see such ICMP errors message being received. Wireshark capture between R1--R2, does not show that any ICMP error message from R1 either. 

 

I suspect the packets with DF bit are silently discarded by LSR ( R1). If this is true, then my book is pretty wrong. 

 

thanks

 

 

 

 

 

 

 

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Hi Sarah,ICMP error message

Hi Sarah,

ICMP error message with fragment required code plays a key role in Path MTU discovery. Per RFC3032, the LSR will generate ICMP error message and will forward towards the source. 

I did a quick try and can see the ICMP error message triggered. What version are you running on node where MTU is mismatched?.

 

-Nagendra

 

 

 

2 REPLIES
Cisco Employee

Hi Sarah,ICMP error message

Hi Sarah,

ICMP error message with fragment required code plays a key role in Path MTU discovery. Per RFC3032, the LSR will generate ICMP error message and will forward towards the source. 

I did a quick try and can see the ICMP error message triggered. What version are you running on node where MTU is mismatched?.

 

-Nagendra

 

 

 

Bronze

Thanks Nagendra   R4#show

Thanks Nagendra

 

 

 

R4#show version
Cisco IOS Software, 2600 Software (C2691-ADVIPSERVICESK9-M), Version 12.4(15)T6, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Mon 07-Jul-08 04:30 by prod_rel_team

ROM: ROMMON Emulation Microcode
ROM: 2600 Software (C2691-ADVIPSERVICESK9-M), Version 12.4(15)T6, RELEASE SOFTWARE (fc2)

R4 uptime is 46 minutes
System returned to ROM by unknown reload cause - suspect boot_data[BOOT_COUNT] 0x0, BOOT_COUNT 0, BOOTDATA 19
System image file is "tftp://255.255.255.255/unknown"

 

563
Views
0
Helpful
2
Replies
CreatePlease login to create content