IPv6 BGP Communities

[Paul_Thornton]

Hi all,

I think I have found an issue with BGP not sending communities on IPv6 internal peers - however, before I open a TAC case, and given that this is probably a corner-case of circumstances I'm wondering if anyone else has seen this.

Two X450a switches and a Cisco router in the same AS. The X450s are originating a bunch of IPv4 routes and IPv6 routes, and setting the same community on all of them. The X450s and the Cisco then connect to another AS.

IPv4 works exactly as expected, the communities are advertised to all neighbours.

With the IPv6 peerings, on the router in the other AS, I can see the community is set on the IPv6 routes learned from the X450s, so that works as expected.
However, on the Cisco in the same AS as the X450a I don't see the community set on any of these routes.

Mirroring the port that faces the Cisco on one of the X450s, a packet capture shows the BGP update messages from the X450a do not contain any community information for the IPv6 prefixes.

I do have 'config bgp neigh x send-community both' on all IPv4 and IPv6 peerings - and it clearly works for both IPv4 and the IPv6 EBGP peers as I can see the community set on the routes at the other end. It is just the IPv6 IBGP that fails.

I've tested this with 15.3.4.6p14 (being X450a switches I can't easily run a higher code rev, and don't have any X460s in the lab to try with most recent code).

Paul.

[Dave_E_Martin]

It should be noted that you need to specify the address family with several other commands as well, i.e.:

show bgp nei x❌x::x ipv6-uni tr all
and not
show bgp nei x❌x::x tr all

which will appear to work, but you won't see your routes.

[Paul_Thornton]

Whether classified technically as a bug or not a bug, it is still counter-intuitive and the CLI is not consistent with itself. That's the bigger issue, I think.

Either the CLI should automatically do things to the BGP address families based on the IP version of the peer or it should not.

ie: right now, with an IPv6 neighbour, the ipv4-unicast and ipv4-multicast address families are automatically disabled (a sensible thing to do) - yet ipv6-unicast is not enabled, and the commands such as enable next-hop-self and send-community are address-family sensitive (also a sensible thing to do) but without v6 having priority over v4 on a v6 peer.

So either when you configure a bgp neighbor, regardless of the address of the peer, the switch should not enable/disable any particular address family and leave it up to the user to configure; or the switch should enable the "obvious" unicast address family for that peer and disable the rest. If it is going to do that, then I believe it should automatically choose the appropriate address family as a default for community/next-hop-self. And really ought to at least give a warning for an inconsistency.

This problem - and it is a problem for all vendors - stems from the fact that in a lot of places all commands of course defaulted to IPv4 as the only address family in existence. Then v6 was added afterwards and had to fit in.

Paul.

[PARTHIBAN_CHINN]

This is not a bug it's just a code change from 12.6 to 15.x . Many customers see similar problem when they did an upgrade from 12.6 to 15.x . But this Is already documented in concepts guide 15.1

[Paul_Thornton]

Hi folks,

An update on this, I've been doing some more testing - it is still probably worth a TAC case but not for an OS bug.

This is, I think, a CLI default behaviour issue, and it isn't limited to communities.

I was configuring a workaround with a route-map on the Cisco, and for this to work I needed to have next-hop-self set on the IPv6 IBGP peer. And I had that configured, or so I thought; but the next hops being received were not the peer IPv6 address. This led me to finding out what my actual issue was.

Going back to the original community problem, I had this config for the peer - this is the v4 and v6 address of the same router:

configure bgp neighbor 217.65.165.254 send-community both
configure bgp neighbor 2001:1420:a::fe send-community both

What I did not have was:

configure bgp neighbor 2001:1420:a::fe address-family ipv6-unicast send-community both

So I was enabling communities on the ipv4-unicast address family on that v6 peer (technically possible, of course, but not likely what you meant). There was also no error, despite the fact that the ipv4-unicast address family was disabled for the 2001:1420:a::fe peer.

Now when you create a V6 peer, eg:

ag2.hbr.3 # create bgp neigh 2001:1420:ffff::1 remote-as 65001

EXOS automatically disables the v4 address families:

* ag2.hbr.4 # show config | inc 2001:1420:ffff::1
create bgp neighbor 2001:1420:ffff::1 remote-AS-number 65001
disable bgp neighbor 2001:1420:ffff::1 capability ipv4-unicast
disable bgp neighbor 2001:1420:ffff::1 capability ipv4-multicast

What it doesn't do here (certainly on 15.3.4) is automatically enable ipv6-unicast, but that's a different issue.

So, in a roundabout way, what I'm saying is that you need to remember to explicitly specify the ipv6-unicast address family when enabling communities or next-hop-self on an IPv6 peer.

In my opinion, the CLI should work as follows:
For IPv4 peer, as it does now, default to ipv4-unicast and disable ipv6-unicast and ipv6-multicast.
For IPv6 peer:
a) Automatically disable ipv4-unicast and ipv4-multicast (it does this now) and enable ipv6-unicast on the neighbor (it does not do this part).
b) When commands such as enable next-hop-self or enable community are issued, default to the ipv6-unicast address family.
c) If you try and enable a feature that relies on an address-family that has been disabled, at least issue a warning.

Of course it is possible to carry ipv6 routes on an ipv4 peering session, and ipv4 routes on an ipv6 peering session; but in real life the few people actually do this - they have two sessions and carry v4 routes on one, and v6 routes on the other. It would be sensible if the defaults reflected this.

I'll check the current behaviour in latest code on an X460 and if it still behaves in this way, I'll raise a TAC case.

Paul.