BGP can't peer with 4-octet ASN with MSB set
Ofer Ben Zvi <ozvi@...>
Hi,
I tried to configure iBGP peering with ASN 2147483648, which is 2^31 (one plus 31 zeroes in Binary). OpenDaylight is sending other side cease message. It seems OpenDaylight interprets the MSB as minus. Here is the log:
2019-01-28T09:55:45,915 | WARN | epollEventLoopGroup-7-2 | AbstractBGPSessionNegotiator | 210 - org.opendaylight.bgpcep.bgp-rib-impl - 0.9.4 | Unexpected negotiation failure java.lang.IllegalArgumentException: Invalid range: -2147483648, expected: [[0..65535]]. at org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.bgp.message.rev171207.OpenBuilder.checkMyAsNumberRange(OpenBuilder.java:148) [204:org.opendaylight.bgpcep.bgp-parser-api:0.9.4] at org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.bgp.message.rev171207.OpenBuilder.setMyAsNumber(OpenBuilder.java:153) [204:org.opendaylight.bgpcep.bgp-parser-api:0.9.4] at org.opendaylight.protocol.bgp.rib.impl.AbstractBGPSessionNegotiator.startNegotiation(AbstractBGPSessionNegotiator.java:116) [210:org.opendaylight.bgpcep.bgp-rib-impl:0.9.4] at org.opendaylight.protocol.bgp.rib.impl.AbstractBGPSessionNegotiator.channelActive(AbstractBGPSessionNegotiator.java:279) [210:org.opendaylight.bgpcep.bgp-rib-impl:0.9.4] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:213) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:199) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelActive(AbstractChannelHandlerContext.java:192) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.ChannelInboundHandlerAdapter.channelActive(ChannelInboundHandlerAdapter.java:64) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:213) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:199) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelActive(AbstractChannelHandlerContext.java:192) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.ChannelInboundHandlerAdapter.channelActive(ChannelInboundHandlerAdapter.java:64) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:213) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:199) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelActive(AbstractChannelHandlerContext.java:192) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelActive(DefaultChannelPipeline.java:1422) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:213) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:199) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelActive(DefaultChannelPipeline.java:941) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:518) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:423) [106:io.netty.transport:4.1.30.Final] at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:482) [106:io.netty.transport:4.1.30.Final] at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163) [103:io.netty.common:4.1.30.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404) [103:io.netty.common:4.1.30.Final] at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:326) [107:io.netty.transport-native-epoll:4.1.30.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:897) [103:io.netty.common:4.1.30.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [103:io.netty.common:4.1.30.Final] at java.lang.Thread.run(Thread.java:748) [?:?]
The same when using ASN 1073741824 (2^30) works.
Looked in ODL Jira, and didn’t find similar open case.
ODL version: stable-oxygen 0.8.4
Steps to reproduce:
Post to <ODL_IP>:8181/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols
<protocol xmlns="http://openconfig.net/yang/network-instance"> <name>bgp-ls-example</name> <identifier xmlns:x="http://openconfig.net/yang/policy-types">x:BGP</identifier> <bgp xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions"> <global> <config> <router-id>###.###.###.###</router-id> <as>2147483648</as> </config> <afi-safis> <afi-safi> <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name> </afi-safi> <afi-safi> <afi-safi-name>LINKSTATE</afi-safi-name> </afi-safi> </afi-safis> </global> </bgp> </protocol>
Put to <ODL_IP>:8181/restconf/config/odl-bgp-peer-acceptor-config:bgp-peer-acceptor-config/default
<bgp-peer-acceptor-config xmlns="urn:opendaylight:params:xml:ns:yang:odl-bgp-peer-acceptor-config"> <config-name>default</config-name> <binding-address>0.0.0.0</binding-address> <binding-port>179</binding-port> </bgp-peer-acceptor-config>
Post to <ODL_IP>:8181/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-ls-example/bgp/neighbors
<neighbor xmlns="urn:opendaylight:params:xml:ns:yang:bgp:openconfig-extensions"> <neighbor-address>###.###.###.###</neighbor-address> <timers> <config> <hold-time>90</hold-time> <connect-retry>10</connect-retry> </config> </timers> <transport> <config> <remote-port>179</remote-port> <passive-mode>false</passive-mode> </config> </transport> <config> <peer-type>INTERNAL</peer-type> </config> <afi-safis> <afi-safi> <afi-safi-name xmlns:x="http://openconfig.net/yang/bgp-types">x:IPV4-UNICAST</afi-safi-name> </afi-safi> <afi-safi> <afi-safi-name>LINKSTATE</afi-safi-name> </afi-safi> </afi-safis> </neighbor>
Configure other side to peer to ODL.
Thanks,
|
|||||||||||
|
|||||||||||
Robert Varga
On 28/01/2019 11:34, Ofer Ben Zvi wrote:
Hi,Hello, OpenDaylight is sending other side cease message.This is the offender, the check for 4-octet ASes fails to account for overflows. Looked in ODL Jira, and didn’t find similar open case.Can you file an issue, please? ODL version: stable-oxygen 0.8.4Oxygen SR4 was the last release in that train, the soonest we can fix this is Fluorine SR2. https://git.opendaylight.org/gerrit/79965 should address that, can you perhaps give it a spin? Thanks, Robert
|
|||||||||||
|
|||||||||||
Ofer Ben Zvi <ozvi@...>
Hi Robert, and thanks for the quick reply.
I don't have a Jira user to file an issue. Can you file it for me, or lead me to how to sign up? Once Fluorine SR2 is out, I'll be happy to check it. When is it scheduled to release? Thanks, Ofer Ben Zvi QA Engineer M: +972-58-5749206 E: ozvi@... On 28/01/2019, 20:27, "Robert Varga" <nite@...> wrote: On 28/01/2019 11:34, Ofer Ben Zvi wrote: > Hi, > > > > I tried to configure iBGP peering with ASN 2147483648, which is 2^31 > (one plus 31 zeroes in Binary). Hello, > OpenDaylight is sending other side cease message. > > It seems OpenDaylight interprets the MSB as minus. Here is the log: > > > > 2019-01-28T09:55:45,915 | WARN | epollEventLoopGroup-7-2 | > AbstractBGPSessionNegotiator | 210 - > org.opendaylight.bgpcep.bgp-rib-impl - 0.9.4 | Unexpected negotiation > failure > > java.lang.IllegalArgumentException: Invalid range: -2147483648, > expected: [[0..65535]]. > > at > org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.bgp.message.rev171207.OpenBuilder.checkMyAsNumberRange(OpenBuilder.java:148) > [204:org.opendaylight.bgpcep.bgp-parser-api:0.9.4] > > at > org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.bgp.message.rev171207.OpenBuilder.setMyAsNumber(OpenBuilder.java:153) > [204:org.opendaylight.bgpcep.bgp-parser-api:0.9.4] This is the offender, the check for 4-octet ASes fails to account for overflows. > Looked in ODL Jira, and didn’t find similar open case. Can you file an issue, please? > ODL version: stable-oxygen 0.8.4 Oxygen SR4 was the last release in that train, the soonest we can fix this is Fluorine SR2. https://git.opendaylight.org/gerrit/79965 should address that, can you perhaps give it a spin? Thanks, Robert
|
|||||||||||
|
|||||||||||
Robert Varga
On 28/01/2019 19:51, Ofer Ben Zvi wrote:
Hi Robert, and thanks for the quick reply.I have filed https://jira.opendaylight.org/browse/BGPCEP-860. In order to be able to file issues (and do pretty much any kind of work on an LFN project), you need to setup an account here: https://identity.linuxfoundation.org/ Once Fluorine SR2 is out, I'll be happy to check it. When is it scheduled to release?February 7th is the projected date. Regards, Robert
|
|||||||||||
|