cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1922
Views
0
Helpful
2
Replies

Neighbor Down: Too many retransmissions - OSPF problem with ISL trunking over SDH/PDH

gogo1982bl
Level 1
Level 1

Hello,

I have an interesting problem to establish OSPF adjacency between several routers.

Routers are interconnected via transport SDH / PDH networks, in a way that all router interfaces on the same subnet. The traffic over the transport network goes through the MUXs and Catalyst 3560 switches.

Interfaces through which the switches are connected to each other is set as ISL trunk links. Then the access ports connected to switches previously mentioned router.

Switches (which are geographically remote locations) are interconnected via MUX equipment (SDH / PDH).

In this scenario, when the router configured OSPF, OSPF routers can not be implicated to establish neighborly relations. OSPF passed  through the states: INIT, 2way, EXSTART and enter  in Exchange phase. Then from my unknown reason OSPF resets the INIT state, and again going through all the state and comes to Exchange, again reset to the INIT and so on.

Logs that are being generated in the attached file ospf_adj.txt

Mainly logs indicate that the phase EXCHANGE (where after exchanging DBD messages should be exchanged LSUpdate messages) coming to ignore the timer expiration, or until the excessive number of retransmission packets.

I suspected that the interfaces on the router the set different MTU value so as to cause mistake, but further examination I found that the MTU on all interfaces configured on the router for FastEthernet standard size of 1500 bytes.

Since ISL trunking between the switches adds another 30 bytes to the standard ETH header (26 bytes of ISL header + 4 bytes CRC), I suspected that the problem is perhaps that the phase EXCHANGE OSPF sends a very big message that comes up excess MTU which is set to MUX devices at 1536 bytes.

With the router I am sending packets of different sizes. Packages up to around 1460 bytes are properly passed and that all packets with MTU larger than 1470 have not been passed. When the frames of 1470 ISL adds 30 bytes total size of the frame's 1500th

In order to determine whether the problem in the MTU settings on the MUX equipment, the switches themselves alone, instead of the ISL trunk interface configured ACCESS interfaces. So frames in this case sent without VLAN tag.

In this case, OSPF routers without any problems establish adjacency, and converged network is working properly. Problem with the MTU was not. When the router may send packets with MTU, which is much higher than 1500 (between 2000 and 3000 byte) frames pass without any problems so I think the problem is in setting the MTU MUX equipment.

Is there any idea how to solve this problem, or some instructions for troubleshooting the problem?

Best Regards, Ognjen
2 Replies 2

maayre
Level 1
Level 1

Hi there,

Definitely an MTU issue, reduce the IP MTU to the highest successful DF ping

Ie "ping x.x.x.x size 1500 df" will fail with ISL.

You mentioned 1460 works, so if you set interface MTU with "ip MTU 1460", then when OSPF sends the DBD (exchange) it won't get forwarded as a 1500 byte packet which is dropped in the intermediate network due to being too big.

HTH,

Matt

Hi Matthew .... Thank you for your response.

Finally I solved the problem. In fact the radio-relay MUX equipment is adjusting MTU was the 1516. Since ISL encapsulation adds to the standard frame ETH new 26 +4 bytes to 1530 bytes in total.

Increasing the MTU on the MUX equipment on 1800 bytes solved the problem.

Thanks again for your response.

BR

Ogi

Best Regards, Ognjen
Review Cisco Networking products for a $25 gift card