[arin-ppml] 4-byte ASNs and BGP communities was:policy 2-byte ASN policy

[Michel Py]

Ron,

> Ron Grant wrote :
> The biggest technical problem with 4-byte ASNs that I'm aware of comes when propagating BGP communities
> - AFAIK even with extended communities, you can't specify two 4-byte ASNs in a single community. [..]
> Recently we ran into this problem when requesting an ASN for the Vancouver Internet Exchange (VANIX)
> - we were told there were no 2-byte ASNs left, so we went back to the drawing board to see how we could
> run our Route Server with a 4-byte ASN, and after wrestling with the problem for a few weeks, went back
> to ARIN and...joy!...someone had returned a 2-byte, which we obtained for the RS.

Would you have technical specifics about the problems you ran into using a 4-byte-ASN ? Such as the OS / platform / software used for the Route Server and which configurations items / scripts did not work ?

I acknowledge that 4-byte-ASN support is not what I expected it to be; it is clear / justified that people will prefer 2-byte ASNs for a while as they require no change to what they are used to. That being said, I think it would be of interest to the ARIN community to have a clear view of the technical issues using 4-byte-ASNs WRT BGP communities.

I am in the process of deprecating 65532:666 in favor of RT:4200065532:666. It is a LOT of work.
Below is my personal view using Cisco IOS 15.x and the cheat-sheet I use. I would like the cheat-sheet for other platforms.

Michel.

(config)#ip bgp-community new-format
Nothing new about that, we used it on a 2500. What it means is that the format is AS16:value, (16 bits each) instead of being a 32-bit integer.
Example : AS 65532, value 666 : the community is 65532:666; one can assign more than one community to a prefix.

(config-route-map)#set community 65532:666 65532:667 -> OK
(config-route-map)#set community 65532:666 additive  -> OK

Problem : 4-byte ASNs are 32-bit not 16, duh.
Solution, (on paper) : extended communities.

Cisco-specific issue : if the desired community is related to the originating AS, one can have only one community per prefix, which possibly is the issue you mentioned in the first place.
(config-route-map)#set extcommunity soo 4200065532:666 4200065532:667
                                                       ^ % Invalid input detected at '^' marker.
(config-route-map)#set extcommunity soo 4200065532:666 additive
                                                       ^ % Invalid input detected at '^' marker.

Way around it : use RT (target AS) instead of SoO.
(config-route-map)#set extcommunity rt 4200065532:666 4200065532:667 -> OK
(config-route-map)#set extcommunity rt 4200065532:666 additive       -> OK

#sh ip bgp x.x.x.x
BGP routing table entry for x.x.x.x/32, version 4
Paths: (1 available, best #1, table default)
  Advertised to update-groups: zz
  Local
    192.0.2.1 from y.y.y.y (y.y.y.y)
      Origin IGP, localpref 100, weight 1, valid, internal, best
      Community: 65532:666 65532:667
      Extended Community: RT:4200065532:666 RT:4200065532:667

It works, and propagates correctly (shows the same on peers).

Cheat-sheet for Cisco :
+-----------------------------------------+-----------------------------------------------+
| AS 16 bit                               | AS 32 bit                                     |
+-----------------------------------------+-----------------------------------------------+
| set community ASN16:value1 ASN16:value2 | set extcommunity RT ASN32:value1 ASN32:value2 |
| set community ASN16:value1 additive     | set extcommunity RT ASN32:value1 additive     |
| match community                         | match extcommunity                            |
| ip community-list standard              | ip extcommunity-list standard                 |
+-----------------------------------------+-----------------------------------------------+