[BGPCEP-676] Unable to handle Encapsulation extended community with subsequent EC Created: 09/Jun/17  Updated: 29/Jul/22

Status: Open
Project: bgpcep
Component/s: BGP
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Giles Heron Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: pick-next, pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 8651

 Description   

when receiving an update with the Encapsulation extended community and a subsequent extended community (MAC mobility) ODL logs an error that the Encapsulation extended community had an unexpected length of 14:

2017-06-09 22:49:02,534 | WARN  | ntLoopGroup-11-1 | BGPSessionImpl                   | 333 - org.opendaylight.bgpcep.bgp-rib-impl - 0.6.3.Boron-SR3 | BGP session encountered error
io.netty.handler.codec.DecoderException: org.opendaylight.protocol.bgp.parser.BGPDocumentedException: Could not parse BGP attributes.
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)[138:io.netty.codec:4.0.44.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)[138:io.netty.codec:4.0.44.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:343)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:336)[137:io.netty.transport:4.0.44.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)[138:io.netty.codec:4.0.44.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:280)[138:io.netty.codec:4.0.44.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:396)[138:io.netty.codec:4.0.44.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)[138:io.netty.codec:4.0.44.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:343)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:336)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1294)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:343)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:911)[137:io.netty.transport:4.0.44.Final]
        at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:934)[141:io.netty.transport-native-epoll:4.0.44.Final]
        at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:397)[141:io.netty.transport-native-epoll:4.0.44.Final]
        at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:302)[141:io.netty.transport-native-epoll:4.0.44.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)[136:io.netty.common:4.0.44.Final]
        at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)[136:io.netty.common:4.0.44.Final]
        at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Caused by: org.opendaylight.protocol.bgp.parser.BGPDocumentedException: Could not parse BGP attributes.
        at org.opendaylight.protocol.bgp.parser.impl.message.BGPUpdateMessageParser.parseMessageBody(BGPUpdateMessageParser.java:135)[321:org.opendaylight.bgpcep.bgp-parser-impl:0.6.3.Boron-SR3]
        at org.opendaylight.protocol.bgp.parser.impl.message.BGPUpdateMessageParser.parseMessageBody(BGPUpdateMessageParser.java:46)[321:org.opendaylight.bgpcep.bgp-parser-impl:0.6.3.Boron-SR3]
        at org.opendaylight.protocol.bgp.parser.spi.pojo.SimpleMessageRegistry.parseBody(SimpleMessageRegistry.java:31)[320:org.opendaylight.bgpcep.bgp-parser-spi:0.6.3.Boron-SR3]
        at org.opendaylight.protocol.bgp.parser.spi.AbstractMessageRegistry.parseMessage(AbstractMessageRegistry.java:66)[320:org.opendaylight.bgpcep.bgp-parser-spi:0.6.3.Boron-SR3]
       at org.opendaylight.protocol.bgp.rib.impl.BGPByteToMessageDecoder.decode(BGPByteToMessageDecoder.java:49)[333:org.opendaylight.bgpcep.bgp-rib-impl:0.6.3.Boron-SR3]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)[138:io.netty.codec:4.0.44.Final]
        ... 21 more
Caused by: java.lang.IllegalArgumentException: Wrong length of array of bytes. Passed: 14.
        at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)[60:com.google.guava:18.0.0]
        at org.opendaylight.protocol.bgp.parser.impl.message.update.extended.communities.EncapsulationEC.parseExtendedCommunity(EncapsulationEC.java:39)[321:org.opendaylight.bgpcep.bgp-parser-impl:0.6.3.Boron-SR3]
        at org.opendaylight.protocol.bgp.parser.spi.pojo.SimpleExtendedCommunityRegistry.parseExtendedCommunity(SimpleExtendedCommunityRegistry.java:55)[320:org.opendaylight.bgpcep.bgp-parser-spi:0.6.3.Boron-SR3]
        at org.opendaylight.protocol.bgp.parser.impl.message.update.ExtendedCommunitiesAttributeParser.parseAttribute(ExtendedCommunitiesAttributeParser.java:41)[321:org.opendaylight.bgpcep.bgp-parser-impl:0.6.3.Boron-SR3]
        at org.opendaylight.protocol.bgp.parser.spi.AttributeParser.parseAttribute(AttributeParser.java:42)[320:org.opendaylight.bgpcep.bgp-parser-spi:0.6.3.Boron-SR3]
        at org.opendaylight.protocol.bgp.parser.spi.pojo.SimpleAttributeRegistry.parseAttributes(SimpleAttributeRegistry.java:138)[320:org.opendaylight.bgpcep.bgp-parser-spi:0.6.3.Boron-SR3]
        at org.opendaylight.protocol.bgp.parser.impl.message.BGPUpdateMessageParser.parseMessageBody(BGPUpdateMessageParser.java:131)[321:org.opendaylight.bgpcep.bgp-parser-impl:0.6.3.Boron-SR3]
        ... 26 more

the BGP message is:

ffffffffffffffffffffffffffffffff00780200000061900e002c001946040a00000b00022100010a00000b000600000000000000000000000000003012ccae8942e90000009e400101005002000e02030000fdeb0000fde80000fde9c010180002fde90000009e030c0000000000080600000000000004

the relevant part is the final 16 bytes:

030C000000000080600000000000004

030C is the encapsulation EC. This carries 6 bytes of data: (00000000008) and is followed by a MAC mobility EC (0600) which also has 6 bytes of data (000000000004).

From looking at the code (EncapsulationEC.java)it seems we only handle the case where the encapsulation EC is the last EC as the code does precondition checks that the buffer is not-null, readable and the right length. None of the other EC cases do this.

I'd suggest removing the preconditions and doing better checks in ExtendedCommunitiesAttributeParser.java (basically check there are at least 6 bytes of buffer left before calling any given handler).

 Comments   
Comment by Giles Heron [ 12/Jun/17 ]

verified the issue by replacing the precondition check for "== CONTENT_SIZE" with ">= CONTENT_SIZE" and was able to bring up EVPN BGP to Cumulus.

Like I say though - we really ought to do the checks in ExtendedCommunitiesAttributeParser.java.

Comment by Yrineu Felipe Rodrigues [ 25/Sep/17 ]

Could you please provide the steps to reproduce it? and could you please verify if it still happens at Master branch?

Comment by Giles Heron [ 26/Sep/17 ]

Looks like the bug is still there in Master. I keep meaning to do a proper fix but never finding the time. To reproduce you could fire up the Cumulus code (they have a vagrant) and then configure EVPN VXLAN.

Comment by Robert Varga [ 29/Jul/22 ]

The info should be enough to create a test case.

Generated at Wed Feb 07 19:13:48 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.