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>Search


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


Failure of NE40E to Established BGP Peer with ALU 7750

Publication Date:  2012-07-27 Views:  81 Downloads:  0
Issue Description
T operator in T country was performing cutover services from NE40EV600R001C00SPC800 equipment to NE40EV600R003C00SPC300 equipment. During the cutover, it was found that newly installed NE40E fails to establish BGP peer relationships with 16 ALU 7750 devices.
Alarm Information
N. A.

Handling Process
After examination of the ORF type and it was concluded that ORF type value of the Open packets received from the ALU devices is not in conformity with the standard of RFC 5292, where the ORF-type sent was 3. When NE40EV600R003C00SPC300 received this, it does not recognize the type and drop the session. After some discussion with the expert, it was found that ORF type 3 that ALU implements follows some recommendation in the expired old Internet draft, but was never really standardized in the RFC. Our company has not implemented the non- standard ORF type-3 hence it did not recognize the type.

But why NE80EV600R001C00SPC800 works with the existing ALU 7750 device? On further examination, it is found that is because the older version of VRP platform do not support the ORF feature and ignore the ORF type in BGP Open packet and do not process it. In order to solve this, development team in HQ has produced a temporary patch to ignore non- standard value coming from ALU7750. The BGP peer relationship becomes normal with ALU7750 after applying the patch.
Root Cause
On comparing log information before and after, it was found NE40E fails to establish BGP peer relationships with 16 ALU 7750 devices. When examine the event, we enable the bgp debugging. The following information was shown from the debug:

RM/6/RMDEBUG:(Public):Receive unsupported orf type from peer ( orf type(3), orf mode(Both)

It was apparently BGP protocol mismatch happened causing the connection to fail to setup.


For this case, both Huawei equipment and ALU7750 has it downside on this issue. For ALU7750, it implemented non- standard ORF feature. For Huawei equipment, upon recognizing that it does not support certain BGP capability, it should ignore and proceed with the normal BGP connection since ORF feature only optimize, but does not affect the normal operation of BGP. Huawei should also tested interoperability of protocol thoroughly with other vendor before deployment. This is especially for the newly implemented function, in this case, ORF function. Also, it is advisable to perform the test connection of new device NE40E in laboratory with other vendor main stream equipment before deployment to production network.