BGP - invalid or corrupt AS path

[Eric Snijders]

Hi all,

We're trying to set up a eBGP connection between a Cisco C3850 (our side) and a Nexus 7000 (customer side).

First i got "mal-formatted" messages from the Nexus 7000. The Nexus side configured "dont-capability-negotiate" and now i'm getting the following error:

Nov  7 08:03:21.580: %BGP-3-NOTIFICATION: received from neighbor 172.24.254.168 3/11 (invalid or corrupt AS path) 7 bytes 40020402 01FFFF

Neighbor configuration for this one is configured as followed:

 neighbor 172.24.254.168 remote-as 65011
 neighbor 172.24.254.168 description eBGP XYZ
 neighbor 172.24.254.168 password 7 ABCDEFGHIJKLMNOP
 neighbor 172.24.254.168 version 4
 neighbor 172.24.254.168 next-hop-self
 neighbor 172.24.254.168 soft-reconfiguration inbound
 neighbor 172.24.254.168 prefix-list Prefix-XYZ in
 neighbor 172.24.254.168 prefix-list YXZ-Prefix out

Does anyone have a suggestion what we could try, i'm lost right now...

Thanks in advance!

Eric

[Georg Pauwen]

Hello,

my first thought is, the line below is the culprit, can you take that out ?

--> neighbor 172.24.254.168 version 4

[paul driver · Accepted solution]

Hello

neighbor 172.24.254.168 dont-capability-negotiate  <-- This is used when two peers have conflicting capabilities , but i don't see this applied?

[Eric Snijders]

Hi Paul,

You were right, i just applied dont-capability-negotiate to this neighbor and BGP is established. I thought that command only had to be applied to the sending side (in this case the peer), but it appears you need it on both sides.

Problem solved!

Thanks all!

[paul driver]

Hello Eric

Glad it worked for you.

FYI - As the routers try to establish a peering they need to negotiate each other capabilities and if they cannot then they wnt establish

Example:
sh ip bgp neighbors | s Neighbor capabilities
 Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received   <------------------------- advertised and received means  both sides are supporting
    Address family IPv4 Unicast: advertised and received<------------------------- advertised and received means  both sides are supporting
    Multisession Capability:

  Neighbor capabilities:
    Route refresh: advertised <------------------------- Trying to negotiate with neighbor
    Four-octets ASN Capability: advertised <------------------------- Trying to negotiate with neighbor
    Address family IPv4 Unicast: advertised and received  <-------------------------Both sides are supporting
    Multisession Capability:

Applying neighbor x.x.x.x dont-capability-negotiate - negates this conflicting capability so allows peering