No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

BGP MTU mismatch case by transmission issue

Publication Date:  2016-12-08 Views:  34 Downloads:  0
Issue Description

After make connection as the topology below then configure MTU  both site with MTU 4470 , between HUAWEI and Cisco has some transmission devices  the BGP can be normal astabliched but after 180 sec the peer go to IDLE state

Alarm Information

When open debug will fould error BGP changes state from ESTABLISHED to IDLE on event HOLD_TIMER


<COR-SNGEQ22new>
Apr 10 2016 02:55:56.549+07:00 COR-SNGEQ22new %%01BGP/3/DEBUG_INFO(d):VS=Admin-VS-CID=0x801304e0;
 BGP.NM(VPN 0): Sent KEEPALIVE to 195.219.83.21, Length: 19

Apr 10 2016 02:55:56.549+07:00 COR-SNGEQ22new %%01BGP/3/DEBUG_INFO(d):VS=Admin-VS-CID=0x801304e0;
 BGP(VPN 0): 19 bytes are writen to socket(1135) for 195.219.83.21.

Apr 10 2016 02:55:56.550+07:00 COR-SNGEQ22new %%01BGP/3/DEBUG_INFO(d):VS=Admin-VS-CID=0x801304e0;
         BGP(VPN 0): Sent message to 195.219.83.21
 (Displaying bytes from 1 to 19)
 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 13 04

Apr 10 2016 02:56:11+07:00 COR-SNGEQ22new %%01BGP/2/bgpBackwardTransNotification(t):VS=Admin-VS-CID=0x801304e0-OID=1.3.6.1.2.1.15.0.2;The BGP FSM moves from a higher numbered state to a lower numbered state. (BgpPeerRemoteAddr=195.219.83.21, BgpPeerLastError=40, BgpPeerState=1)

Apr 10 2016 02:56:11.558+07:00 COR-SNGEQ22new %%01BGP/3/DEBUG_INFO(d):VS=Admin-VS-CID=0x801304e0;
 BGP(VPN 0): 195.219.83.21 changes state from ESTABLISHED to IDLE on event HOLD_TIMER. (main socket)

Handling Process

As the debug massage told that the BGP state change case by HOLD_TIMER

So need to check the transmission any packet loss

after try check the transmission support MTU size only 1500

[~COR-SNGEQ22new]ping -s 1473 195.219.83.21
PING 195.219.83.21: 1473 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out

[~COR-SNGEQ22new]ping -s 1472 195.219.83.21
PING 195.219.83.21: 1472 data bytes, press CTRL_C to break
Reply from 195.219.83.21: bytes=1472 Sequence=1 ttl=64 time=186 ms
Reply from 195.219.83.21: bytes=1472 Sequence=2 ttl=64 time=184 ms
Reply from 195.219.83.21: bytes=1472 Sequence=3 ttl=64 time=185 ms
Reply from 195.219.83.21: bytes=1472 Sequence=4 ttl=64 time=185 ms
Reply from 195.219.83.21: bytes=1472 Sequence=5 ttl=64 time=185 ms

Root Cause

The transmission support MTU only 1500 so when the BGP packet with MTU 4470 sent out will drop on the transmission part make the BGP hold time out

Solution

the problem can solve by use path-mtu auto-disovery command for the cisco site it support this auto adjustment by default  or change the interface MTU size to 1500


[~COR-SNGEQ22new-bgp] peer 195.219.83.21 path-mtu auto-discovery

detail for command as below

When hosts on the same network communicate, the MTU of the network is important to both communication ends. When hosts need to communicate across multiple networks, the smallest MTU on the communication path is most important to both ends. This is because different networks along the communication path have different link-layer MTUs. The minimum MTU on the communication path is called the path MTU.

For example, if BGP packets are encapsulated in TCP packets and the default Maximum Segment Size (MSS) of a TCP packet is 536 bytes, the length of Update packets transmitted between BGP peers is 536 bytes. As a result, a large amount of BGP update information is distributed to different packets, and the number of ACK packets corresponding to the update information increases. Transmission this mode is inefficient. To improve the efficiency of transmitting BGP packets, the path MTU discovery mechanism can be used by both communication ends.

The path MTU has the following characteristics:
Uncertainty: During communication, the path MTU of hosts depends on the selected path and thus may change.
Inconsistency: The path MTUs in the inbound and outbound directions may be inconsistent because the path from the sender to the receiver may be different from the path from the receiver to the sender.

After the peer path-mtu-discovery command is run, peers learn the number of bytes of the maximum data packet on a transmission path to prevent packet fragmentation.


Suggestions

When configure MTU size on any interface should check the MTU for the hold transmission  part as well

END