OSPF and MTU _ Cisco Technical Support Forum

Language: EnglishEnglish日本語 (Japanese)Español (Spanish)Português (Portuguese)Pусский (Russian)简体中文 (Chinese)Contact UsHelp

Follow Us

Facebook

Twitter

Google +

LinkedIn

YouTube

Newsletter

Community DirectoryExpert CornerSolutionsCommunity Corner

Community ResourcesCisco

Community Directory

WAN, Routing and SwitchingLAN, Switching and Routing

VPNSecurity Management

×

Please help us improve your CiscoSupport Community experience bygiving us feedback

OSPF and MTU | Cisco Technical Support Forum https://supportforums.cisco.com/document/56556/ospf-and-mtu

1 of 21 4/10/2014 11:41 AM

Expert CornerTop ContributorsLeaderboardsKnowledge SharingExperts BureauCisco Live! Events

SolutionsCisco On DemandOnDemand Solutions

Community CornerAwards & RecognitionsBehind the ScenesCisco CafeCisco.com Idea CenterCommunity Ideas

Network ManagementRemote AccessOptical NetworkingGetting Started with LANsIPv6 Integration and TransitionEEM ScriptingOther Subjects

FirewallingIntrusion Prevention Systems/IDSAAA, Identity and NACPhysical SecurityMARSEmail SecurityWeb SecurityOther Subjects

MetroMPLSVoice Over IPXR OS andPlatformsVideoOther SubjectsIP TelephonyVideo Over IPJabber ClientsUnifiedCommunicationsApplicationsTelePresenceDigital MediaSystemContact CenterConferencingUC MigrationsOther Subjects

Security and Network ManagementWireless IP Voice and VideoGetting Started with WirelessWLCCAOther Subjects

Partner Support ServiceSmart Call HomeSmart CareCisco TS Premium ServicesCustomer Premises Equipment (CPE) SupportCompliance Management and Configuration ServiceSmart Net Total CareOperations Exchange

Cisco ProximityCisco Technical Support Cisco Bug

DiscussionsTechnicalDocumentationIdeasSupportCommunity Help

Application NetworkingServer NetworkingStorage NetworkingUnified ComputingWide Area Application Services (WAAS)Other Subjects

Network StorageRoutersSecuritySurveillanceSwitchesVoice and ConferencingWireless

BorderlessNetworksCollaborationData Center andVirtualization

Seattle CiscoUser Group(SEACUG)Silicon ValleyCisco UserGroup (SVCUG)SouthernCalifornia CiscoUser Group(SCCUG)


2 of 21 4/10/2014 11:41 AM

Feedback ForumMobile Community

Login | Register

Home/Service Providers

Additional CommunitiesCommunity CornerData CenterMobile ApplicationsNetwork InfrastructureWireless - MobilityCollaboration, Voice and VideoSmall Business Support CommunitySecuritySolutions and ArchitecturesServicesTop ContributorsCisco User GroupsOn DemandOnline Tools and ResourcesPrivate

Language: EnglishEnglish日本語 (Japanese)Español (Spanish)Português (Portuguese)Pусский (Russian)简体中文 (Chinese)Contact UsHelp

Follow Us

Facebook

Twitter

Google +

LinkedIn

YouTube

Newsletter


3 of 21 4/10/2014 11:41 AM

Luc De Ghein 3 years ago

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt;mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt;font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Links on routers have an MTU. The outgoing packets, including OSPF packets cannot have a bigger sizethan the interface MTU. Let’s have a look at the behavior of OSPF and packets.

This is what RFC 2328 (OSPF version 2 specification) says about OSPF packets and MTU.

A.1 Encapsulation of OSPF packets

OSPF runs directly over the Internet Protocol's network layer. OSPF

packets are therefore encapsulated solely by IP and local data-link

headers.

OSPF does not define a way to fragment its protocol packets, and

depends on IP fragmentation when transmitting packets larger than

the network MTU. If necessary, the length of OSPF packets can be up

to 65,535 bytes (including the IP header). The OSPF packet types

that are likely to be large (Database Description Packets, Link

State Request, Link State Update, and Link State Acknowledgment

packets) can usually be split into several separate protocol

packets, without loss of functionality. This is recommended; IP

fragmentation should be avoided whenever possible.

Remember that there could be one LSA in one Link State (LS) Update packet, but there can also be manyLSAs in one LS Update packet. This is called packing LSAs into one LS Update packet.

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt;

Document Jan 17, 2011 4:24 AM


4 of 21 4/10/2014 11:41 AM

mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt;font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Here’s a DBD or Database Description packet, specified in RFC 2328. This packet describes the contents of the OSPF link-state database.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Version # | 2 | Packet length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Router ID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Area ID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Checksum | AuType |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Authentication |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Authentication |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Interface MTU | Options |0|0|0|0|0|I|M|MS

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| DD sequence number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+- -+

| |

+- An LSA Header -+

| |

+- -+

| |

+- -+

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ... |

Interface MTU is defined as: “The size in bytes of the largest IP datagram that can be sent out


5 of 21 4/10/2014 11:41 AM

the associated interface, without fragmentation”. So, routers attached to a link exchange their interface MTU value in DBD packets when the OSPF adjacency is initialized.

Section 10.6 of RFC 2328 says:

If the Interface MTU field in the Database Description packet

indicates an IP datagram size that is larger than the router can

accept on the receiving interface without fragmentation, the

Database Description packet is rejected.

When "debug ip ospf adj" is turned on, we can see the arrival of these DBD packets. In the followingexample, we can see that there is a mismatch in MTU values between two OSPF neighbors. This router hasMTU 1600, while the neighboring OSPF router has interface MTU 2000.

On this router:

OSPF: Rcv DBD from 10.100.1.2 on GigabitEthernet0/1 seq 0x2124 opt 0x52 flag 0x2 len1452 mtu 2000 state EXSTART

OSPF: Nbr 10.100.1.2 has larger interface MTU

On the neighboring router:

OSPF: Rcv DBD from 10.100.100.1 on GigabitEthernet0/1 seq 0x89E opt 0x52 flag 0x7 len32 mtu 1600 state EXCHANGE

OSPF: Nbr 10.100.100.1 has smaller interface MTU

The DBD packets are retransmitted continuously and eventually, the OSPF adjacency is torn down.

OSPF: Send DBD to 10.100.1.2 on GigabitEthernet0/1 seq 0x9E6 opt 0x52 flag 0x7 len 32

OSPF: Retransmitting DBD to 10.100.1.2 on GigabitEthernet0/1 [10]

OSPF: Send DBD to 10.100.1.2 on GigabitEthernet0/1 seq 0x9E6 opt 0x52 flag 0x7 len 32

OSPF: Retransmitting DBD to 10.100.1.2 on GigabitEthernet0/1 [11]

%OSPF-5-ADJCHG: Process 1, Nbr 10.100.1.2 on GigabitEthernet0/1 from EXSTART to DOWN,Neighbor Down: Too many retransmissions

Before CSCse01519, OSPF in IOS would build OSPF packets up to a maximum of 1500 bytes. This is a


6 of 21 4/10/2014 11:41 AM

regardless of the interface MTU. So, if the interface MTU is bigger than 1500 bytes, OSPF would still packonly up to 1500 bytes into an OSPF packet. This is somewhat inefficient because OSPF could send biggerpackets on the link and achieve a greater throughput. There is one exception to this: if the LSA is so big thatone LSA holds more than 1500 bytes, then OSPF builds that packet, no matter what the size (OSPF cannotfragment one LSA). The IP stack of the router then fragments it to fit the MTU of the outgoing interface.This typically occurs when an OSPF router has many links and hence the router LSA because bigger than thelink MTU.

Equally so, if the MTU of the outgoing interface is smaller than 1500 bytes, then the OSPF process wouldstill build or pack OSPF packets up 1500 bytes and the IP stack of the router would fragment this into smallerIP packets in order to fit the MTU of the outgoing link. One example where this typically occurs, is an IPSectunnel between 2 routers running OSPF. The added overhead of the encapsulation bytes of the tunnel leads toan MTU which is lower than 1500 bytes. OSPF builds OSPF packets up to 1500 bytes and they then getfragmented before the router transmits them. This is another inefficiency.

After CSCse01519, OSPF in IOS can pack OSPF packets to be greater than 1500 bytes. This occurs if theMTU of the outgoing interface is greater than 1500 bytes. This will make the transmissions more efficient asmore information can be packed into one larger packet. For example, if one OSPF router needs to transmit alot of external LSAs to an OSPF neighbor, it can pack more external LSAs into one LS Update packet, if thatrouter runs IOS with CSCse01519 implemented.CSCse01519 also allows OSPF to build packets lower than 1500 bytes. In some scenarios, the MTU between2 OSPF neighbors is lower than 1500 bytes. See the example above with an IPSec tunnel. In that case, OSPFtransmits OSPF packets which are smaller than 1500 bytes, avoiding IP fragmentation, except in the case ofone large LSA, bigger than the interface MTU

Example of an issue due to the behavior change of OSPF and

packing LSAs into a LS Update packet

Here's a specific example of what can go wrong when upgrading an OSPF router and discovering an OSPFMTU issue due to CSCse01519.

Many networks have OSPF neighbors which are connected through a Layer 2 switched network, or transportnetwork, comprised of L2VPN service or a SDH/SONET network. These transport networks can havedifferent MTU settings than the routers running OSPF.

While the MTU setting should be correct on all routers, reflecting the true MTU, there are often mistakes andthey can go unnoticed.

Here's an example network, with two routers R1 and R2 running OSPF and they are connected through aLayer 2 switch.


7 of 21 4/10/2014 11:41 AM

The issue occurs a lot if the routers have MTU-settable Ethernet interfaces. In this case, they are. Theinterfaces are GigabitEthernet interfaces and have an MTU set to 2000. The MTU of the Layer 2 switch isonly 1500 bytes.Assume that the size of the data traffic is never bigger than 1500 bytes, then there is no problem running IOSwithout CSCse01519. The OSPF packets will never be larger than 1500 bytes. Except if there is one LSAwhich is larger than 1500 bytes, in which case the OSPF process on router R1 or R2 builds a Link StateUpdate packet larger than 1500 bytes and transmits it. Assume this packet is 1800 bytes, then it will getdropped by the Layer 2 switch between the routers.

Assume we have an OSPF database on R2 that has enough networks so that the locally originated LSAs areso big that a LS Update packet can be potentially larger than the interface MTU.If these networks are originated by the covering network command, then the networks show up in the routerLSA of R2. R2 builds a router LSA which is bigger than 2000 bytes and transmits it, but IP fragments itdown to 2000, the interface MTU. The Layer 2 switch however will drop these packets. OSPF will thenretransmit this packet endlessly and the OSPF adjacency is never full. So, the issue is immediatelydiscovered, even when running IOS without CSCse01519.

If these networks are originated by "redistribute connected", then they will show up in external LSAs. OSPFwill only try to pack external LSAs into one LS Update packet up to 1500 bytes big.

In this case, because the interface MTU is 2000, the OSPF adjacency reaches the FULL state. The issue of


8 of 21 4/10/2014 11:41 AM

the underlying MTU -which is not adequate- is not immediately discovered.When we upgrade one router to IOS with CSCse01519, then the issue will be discovered.Let's see what happens.

First both routers run IOS without CSCse01519.When the adjacency builds, we see that R1 never receives an OSPF packet bigger than 1500 bytes, even ifthe MTU of the interfaces is 2000.We enable "debug ip ospf packets".

OSPF: rcv. v:2 t:1 l:48 rid:10.100.1.2 aid:0.0.0.0 chk:72CF aut:0 auk: from GigabitEthernet0/1

...

OSPF: rcv. v:2 t:4 l:1468 rid:10.100.1.2 aid:0.0.0.0 chk:8389 aut:0 auk: from GigabitEthernet0/1OSPF: rcv. v:2 t:4 l:136 rid:10.100.1.2

...

L: xx in the debug output shows us the length of the OSPF packet. The biggest OSPF packet sent out was1468 bytes.t: 4 means that the type of the OSPF packet is "Link State Update". Refer to this table from RFC 2328,section 4.3, for the

different OSPF packet types.

Type Packet name Protocol function __________________________________________________________ 1 Hello Discover/maintain neighbors 2 Database Description Summarize database contents 3 Link State Request Database download 4 Link State Update Database update 5 Link State Ack Flooding acknowledgment

We see that the OSPF adjacency reaches the full state.

R1#show ip ospf neighbor gigabitEthernet 0/1

Neighbor ID Pri State Dead Time Address Interface10.100.1.2 0 FULL/ - 00:00:34 10.1.1.2 GigabitEthernet0/1


Neighbor ID Pri State Dead Time Address Interface


9 of 21 4/10/2014 11:41 AM

10.100.100.1 0 FULL/ - 00:00:34 10.1.1.1 GigabitEthernet0/1

We upgrade IOS on R2 to an IOS with CSCse01519.


Neighbor ID Pri State Dead Time Address Interface10.100.100.1 0 LOADING/ - 00:00:33 10.1.1.1 GigabitEthernet0/1

R2#show ip ospf neighbor gigabitEthernet 0/1 detailNeighbor 10.100.100.1, interface address 10.1.1.1 In the area 0 via interface GigabitEthernet0/1 Neighbor priority is 0, State is LOADING, 5 state changes DR is 0.0.0.0 BDR is 0.0.0.0 Options is 0x12 in Hello (E-bit L-bit ) Options is 0x52 in DBD (E-bit L-bit O-bit) LLS Options is 0x1 (LR) Dead timer due in 00:00:39 Neighbor is up for 00:00:49 Index 1/1, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec Number of retransmissions for last link state request packet 9 Poll due in 00:00:00

R2#show ip ospf neighbor gigabitEthernet 0/1 detailNeighbor 10.100.100.1, interface address 10.1.1.1 In the area 0 via interface GigabitEthernet0/1 Neighbor priority is 0, State is LOADING, 5 state changes DR is 0.0.0.0 BDR is 0.0.0.0 Options is 0x12 in Hello (E-bit L-bit ) Options is 0x52 in DBD (E-bit L-bit O-bit) LLS Options is 0x1 (LR) Dead timer due in 00:00:33 Neighbor is up for 00:02:06 Index 1/1, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec Number of retransmissions for last link state request packet 25 Poll due in 00:00:03


10 of 21 4/10/2014 11:41 AM

Average Rating: 4.8 (9 ratings)

%OSPF-5-ADJCHG: Process 1, Nbr 10.100.100.1 on GigabitEthernet0/1 from LOADING to DOWN,Neighbor Down: Too many retransmissions

The OSPF adjacency does not reach the FULL state. We see retransmissions. The OSPF adjacency is stuck inLOADING state. OSPF gave up after 25 retransmissions, after which, it will try to establish the adjacencyagain, but will run into the same issue. So, this continues endlessly.We see that by only upgrading one router (R2) we uncover a previsouly hidden issue: the underlying MTU issmaller than the one used by the OSPF routers.When the switch changes MTU to pass 2000 bytes packets, we see an OSPF packet which is bigger than1500 bytes being transmitted fine.

R1#OSPF: rcv. v:2 t:3 l:1980 rid:10.100.1.2 aid:0.0.0.0 chk:AC5B aut:0 auk: from GigabitEthernet0/1

To check underlying MTU issues, always ping the OSPF neighbor IP address with a size equal to MTU andthe df-bit set.

To discover the value of the underlying MTU, perform this ping and sweep the size. Then count the numberof "!" we see in the output and you'll get the real MTU. In this case, the last echo reply we got back from theping command has size 1500 bytes.

R2#pingProtocol [ip]:Target IP address: 10.1.1.1Repeat count [5]: 1Datagram size [100]:Timeout in seconds [2]:Extended commands [n]: yesSource address or interface:Type of service [0]:Set DF bit in IP header? [no]: yesValidate reply data? [no]:Data pattern [0xABCD]:Loose, Strict, Record, Timestamp, Verbose[none]:Sweep range of sizes [n]: yesSweep min size [36]: 1460Sweep max size [18024]: 1540Sweep interval [1]:Type escape sequence to abort.Sending 81, [1460..1540]-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:Packet sent with the DF bit set!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!........................................Success rate is 49 percent (40/81), round-trip min/avg/max = 1/1/4 ms

Rating


11 of 21 4/10/2014 11:41 AM

Jan.Ferre 3 years ago

A very good article describing the problems.

One subtle thing to notice is the definition of MTU's especially on L3-switches:

MTU size is for 10-100 Mbit interfaces

Jumbo MTU is for 1-10 Gbit interfaces

Routing MTU is for OSPF (guess for other routing protocols as well)

Especially on the L3 switches you may need extended MTU for switching/trunking purposes while it may be nescessaryto reduce the routing MTU. This is especially important when mixing switch-models - like C3550, C3560, C3750 as theybehave differently.

Any way - this article does give a good understanding of _why_ the problem exists.

Nandan Mathure 2 years ago

Nice and helpful post. Thanks :-)

siddhartham 11 months ago


12 of 21 4/10/2014 11:41 AM

great explanation, thanks for the article.

shreerampardhy 11 months ago

Hello Luc,

I have a bit of different understanding on the above topic for the type 1 and type 2 LSAs. I agree to the point that the maxsize of the type 1 and type 2 lsa can be 65K ( as we have length field of 2 bytes ). I also agree that the device needs tobuild the complete LSA ( router and Network ) without fragmenting it. But i dont think that the IP layer can then fragmentthis packet, if the interface MTU is less than the LSA MTU. There is no field in teh type 1 and type 2 LSA that canreassemble the fragmented LSA.

For example, if the size of the Type 1 LSA generated by the device is more than 1500 bytes and the link is of only 1500bytes, then the IP header cannot just fragement the packet. Even if it does, the LSA would be corrupted when it isreceived at the receiving end.

I think this can be done only in ISIS ( just speaking about the link state protocols ). LSP for ISIS supports max of 255fragments which can be reassembled at the receiving end. Since each fragment has its own checksum, they can also beindividually verified

Regards,

Shreeram

See More

Luc De Ghein 11 months ago (reply to shreerampardhy)

Hi Shreeram,

IP can fragment OSPF packets.

Here's two routers, R1 and R2 with both MTU 1500 on the ethernet interface between them.

R1 has many OSPF-enabled interfaces, so that the Router LSA of R1 becomes bigger than 1500 bytes.


13 of 21 4/10/2014 11:41 AM

R1#show ip int et 0/0

Ethernet0/0 is up, line protocol is up

Internet address is 10.1.1.1/24

Broadcast address is 255.255.255.255

Address determined by setup command

MTU is 1500 bytes <<<<<<

A capture on the wire when OSPF exchanges the router LSA of R1 shows:

Frame 37 (1514 bytes on wire, 1514 bytes captured)

Ethernet II, Src: aa:bb:cc:00:01:00, Dst: 01:00:5e:00:00:05

Internet Protocol, Src Addr: 10.1.1.1 (10.1.1.1), Dst Addr: 224.0.0.5 (224.0.0.5)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)

Total Length: 1500 <<<<<<

Identification: 0x0184 (388) <<<<<<

Flags: 0x02

.0.. = Don't fragment: Not set

..1. = More fragments: Set <<<<<<

Fragment offset: 0

Time to live: 1

Protocol: OSPF IGP (0x59)

Header checksum: 0xa67e (correct)

Source: 10.1.1.1 (10.1.1.1)

Destination: 224.0.0.5 (224.0.0.5)

Open Shortest Path First

OSPF Header

OSPF Version: 2

Message Type: LS Update (4)

Packet Length: 1528 <<<<<<

Source OSPF Router: 10.100.1.1 (10.100.1.1)

Area ID: 0.0.0.0 (Backbone)


14 of 21 4/10/2014 11:41 AM

Packet Checksum: 0xf490

Auth Type: Null

Auth Data (none)

[Unreassembled Packet: OSPF]

Frame 38 (82 bytes on wire, 82 bytes captured)

Ethernet II, Src: aa:bb:cc:00:01:00, Dst: 01:00:5e:00:00:05

Internet Protocol, Src Addr: 10.1.1.1 (10.1.1.1), Dst Addr: 224.0.0.5 (224.0.0.5)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)

Total Length: 68

Identification: 0x0184 (388) <<<<<<

Flags: 0x00

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 1480

Time to live: 1

Protocol: OSPF IGP (0x59)

Header checksum: 0xcb5d (correct)

Source: 10.1.1.1 (10.1.1.1)

Destination: 224.0.0.5 (224.0.0.5)

Data (48 bytes)

0000 0a c8 01 03 ff ff ff ff 03 00 00 01 0a c8 01 02 ................

0010 ff ff ff ff 03 00 00 01 0a c8 01 01 ff ff ff ff ................

0020 03 00 00 01 0a 64 01 01 ff ff ff ff 03 00 00 01 .....d..........

The router LSA of R1 is bigger than 1500 bytes and was fragmented by IPv4.

The router LSA of R1 will be stored on R2. We can see that the size of the LSA is bigger than 1500 bytes.

R2#show ip ospf database router 10.100.1.1

OSPF Router with ID (10.100.1.2) (Process ID 1)

Router Link States (Area 0)

LS age: 4


15 of 21 4/10/2014 11:41 AM

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 10.100.1.1

Advertising Router: 10.100.1.1

LS Seq Number: 80000022

Checksum: 0x2CF4

Length: 1536 <<<<<<

Number of Links: 126

The difference between OSPF and ISIS is that OSPF runs on top of IP, while ISIS runs directly on Layer 2.

ISIS builds one LSP per level per router. With OSPF, IP can fragment the packet.

The OSPF LSA header does have a checksum field. The re-assembled LSA can be verified.

RFC 2328:

4.3. Routing protocol packets

The OSPF protocol runs directly over IP, using IP protocol 89.

OSPF does not provide any explicit fragmentation/reassembly

support. When fragmentation is necessary, IP

fragmentation/reassembly is used. OSPF protocol packets have

been designed so that large protocol packets can generally be

split into several smaller protocol packets. This practice is

recommended; IP fragmentation should be avoided whenever

possible.

A.1 Encapsulation of OSPF packets

OSPF does not define a way to fragment its protocol packets, and

depends on IP fragmentation when transmitting packets larger than

the network MTU. If necessary, the length of OSPF packets can be up

to 65,535 bytes (including the IP header).

The issues with the OSPF adjacency not forming is related to a mismatch in MTU settings or another problem withthe MTU.

Either the MTU is set differently on either side of the link or there is a Layer 2 device in the middle with a lowerMTU than what the routers have on the interface.

In the example above, the router LSA of R1 is fragmented, but the OSPF adjacency forms fine.

I hope this clarifies things.


16 of 21 4/10/2014 11:41 AM

Thanks,

Luc

siddhartham 11 months ago

I do have a question..If the IP layer can frgment the packets then why do we get a OSPF neighbourship issue when thereis a interface MTU mismatch.

shreerampardhy 11 months ago

Hello Luc,

Many thanks for the detailed explaination. My confusion was if the type 1 and type 2 LSAs can be fragmented or not as Iwas looking at the way ospf packet can identify the fragments. Your outputs seem to precisely clarify this.:)

Thank you once again for the explaination.

Regards,

Shreeram

[email protected] 8 months ago


17 of 21 4/10/2014 11:41 AM

Actions

Login or Register to take actions

This Document

Posted January 17, 2011 at 4:24 AMBy Luc De GheinStats:

Comments: 9 Avg. Rating: 4.8

Views: 25898 Contributors: 7

Shares: 1

Hi Luc

Thanks for this document, it is very clear and precise in his explanation.

I tested in the laboratory and could repeat several times the failure.

Best regard

Christian

CSCO11508096 6 months ago

Hi,

To resolve this issue.

use the command under ospf process " Ip ospf mtu-ignore" on the router that is having lower mut set on the interface.

Regards

Shashi


18 of 21 4/10/2014 11:41 AM

Show

Tags: ospf, mtu+

FollowShortcutAbuseSave

Related Content

DiscussionVRF Lite and OSPF strange Behaviourarunprabhu20 hours 59 min ago7 viewsDiscussionWhat ASA Version has Dynamic Route Table Replication to Failoverhypnotoad3 days 1 hour ago12 viewsDiscussionOSPF over Link Agg LACP / [email protected] week 2 days ago19 viewsDiscussionOSPF over Frame Relay problem !Kingvu19882 weeks 4 hours ago43 viewsDiscussionRouting query on EIGRP and OSPFGanalagu073 weeks 3 days ago69 views


19 of 21 4/10/2014 11:41 AM

All Time Monthly

Rank Username Points

1 abrajan 20

2 Chetan Kumar Ress 11

3 inderdeeps 10

4 ddondilip 10

5 Thanveer Mohd 5

View Full Leaderboards

Information ForSmall BusinessMidsize BusinessExecutivesHomeService ProviderIndustriesContactsContact CiscoFind a Reseller

News & Alerts


20 of 21 4/10/2014 11:41 AM

NewsroomBlogsField NoticesSecurity AdvisoriesTechnology TrendsCloudIPv6MobilityOpen Network EnvironmentTrustworthy Systems

SupportDownloadsDocumentationCommunitiesDeveloper NetworkLearning NetworkSupport CommunityVideo Portal

About CiscoInvestor RelationsCorporate Social ResponsibilityEnvironmental SustainabilityTomorrow Starts HereCareer OpportunitiesProgramsCisco Designated VIP ProgramCisco PowereredFinancing Options

Terms & ConditionsPrivacy StatementCookie PolicyTrademarks of Cisco Systems, Inc.


21 of 21 4/10/2014 11:41 AM

OSPF and MTU _ Cisco Technical Support Forum

Documents

Transcript of OSPF and MTU _ Cisco Technical Support Forum