Archives for posts with tag: wireshark

Did you know that OSPF neighbors do not move to the  FULL state with mismatched MTU?

I found this out at the weekend when I was working on some Data Centre switches, within the fabric these switches use jumbo MTU. So when I tried to peer a device that was not part of the fabric, I got stuck in EXSTART.

At first I was wondering if I had the OSPF configuration. I checked and double checked but all looked good.


run “debug ip ospf adj” you will get a message similar to this.

*Nov 16 21:30:45.551: OSPF-1 ADJ Gi0/0: Nbr has smaller interface MTU

Answer: match the MTU on both sides.
I had a read through TCP/IP Volume 1, It doesn’t mention MTU size anywhere. RFC 2328 does mention it.

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.

This is where wireshark comes in handy, I had to see this for myself.

The MTU isnt sent in the Hello packet its sent in the type 2 DBD packet, this is after the neighbors acknowledge each other (2WAY). See below.




4-Byte Autonomous System Number provides us with 4.3billion unique ASN’s , going far beyond the original 2-Byte range of 65536.

So what happens when you have a router that doesn’t yet support 4-Byte ASN? I’ll show you what to do.

You wouldn’t necessarily be configuring all 3 routers in the real world.

First see the simple topology below

4-Byte ASN

4-Byte ASN

R3 in the middle is still using a 2-Byte ASN and the IOS doesn’t support 4-Byte ASN. So for this exact purpose IANA assigned a placeholder, AS23456 which is used by the older routers to communicate with new 4-Byte AS numbers.

This is achieved by using a transitive BGP attribute  NEW_AS_PATH and NEW_AGGREGATOR, much like the ATOMIC_AGGREGATOR used when summarising similar routes. This stores like a small note of the actual 4-Byte ASN which is then used by the 4-Byte capable router. Something you might want to note is the AS_PATH length is also maintained, I will demonstrate this.

This particular method is known as AS-PLAIN

So on R2 and R3 setup BGP, the only difference is on R3 instead of using the actual AS number use the placeholder AS23456.

R2#sh run | sec router bgp
router bgp 132678
 bgp log-neighbor-changes
 network mask
 neighbor remote-as 500
no auto-summary
R3#sh run | sec router bgp
router bgp 500
 no synchronization
 bgp log-neighbor-changes
 neighbor remote-as 23456
 neighbor remote-as 23456
 no auto-summary

Now on R1 I’ve used AS_PATH Prepend to demonstrate the fact that the AS_PATH length doesn’t change, On my route map I prepended the AS path 4 times

R1#sh run | sec router bgp
router bgp 131456
 bgp log-neighbor-changes
 neighbor remote-as 500
 neighbor route-map prepend-AS out
no auto-summary

Now lets confirm the configurations above, using the commands SH IP BGP” from R3. We will expect to see the placeholder ASN23456

   Network          Next Hop            Metric LocPrf Weight Path
*>              0             0 23456 i
*>              0             0 23456 23456 23456 23456 23456 i

Now  let’s do the same from R2 , we should now expect to see the 4-Byte ASN in the AS_PATH.

     Network          Next Hop            Metric LocPrf Weight Path
 *>                  0         32768 i
 *>                            0 500 131456 131456 131456 131456 131456 i

To see exactly what is sent between the router’s I’ve used Wireshark to capture the packets, you can see the message sent from R3, AS_PATH and NEW_AS_PATH

Wireshark Capture

Wireshark Capture


If you need to work out the ASDOT version of an ASPLAIN 4-Byte ASN use the examples below.

4-Byte ASN-194534
1. 194534 / 65535 = 2 (integer)
2. 194534 – ( 65535 * 2) = 63464
3. 63464 – 2 (integer) = 63462
4  ASDOT = 2.63462

Here is a different example this time with an even longer ASN

4-Byte ASN-2394951
1. 2394951 / 65535 = 36 (integer)
2. 2394951 -(65535*36) = 2394951-2359260 = 35691
3. 35691-36 (integer) = 35655
4. ASDOT =36.35655