Community for small IX - problem with 4B ASN

[Piotr Marciniak]

I will use some private 16-bit ASn as before. For filters in our local IXP 
should be ok.

Best wishes,

Piotr Marciniak

-----Oryginalna wiadomość----- 
From: Mikhail Grishin
Sent: Tuesday, January 23, 2018 8:58 AM
To: bird-users at network.cz
Subject: Re: Community for small IX - problem with 4B ASN

Hi Piotr ,
May be the most simple thing - to change your ASN number to 16bit - in
case if solid % of your customers support and use only traditional
communities (RFC 1997) .

RIPE can help.

Piotr Marciniak пишет 22.01.2018 18:46:
> Hello Ondrej,
>
> I am seeking for a way to make our small local IXP project to be a bit 
> more flexible and safe. I think we could do with implementation of 
> communities which would allow our peers to prepend or block their prefixes 
> from annoncing to specific peer or all peers.
>
> Goal is simple. Peer A should be able to send to us community to prepend 
> or block announcing his prefixes to chosen by ASn Peer B or all peers.
>
> Which community standard I would like to use? Most supported on typical, 
> (mosttly) local ISP BGP routers - from Mikrotik by Cisco to Bird. I do not 
> think it is extraordinary wish. ;-] Rather typical for most IXP of any 
> size.
>
> In our scenario we rather do not need to forward communities. Just to 
> collect info from Peer A what to do with his prefixes before announcing it 
> to others.
>
> I think the only problem I am facing now is that I can't use in known 
> config examples our AS205082. But here we face another problem if I 
> understand correcttly - what to do if not only our community is 4B? I may 
> "shrink our" to any 16-bit equivalent like 65250 I use in my examples. But 
> stil if I have a peer with AS123456 - how to accept his 4B AS in 
> communities received from our peers? Fe. old Cisco can connect to 4B ASn 
> but can't work on 4B communities I think. So it can't send me request - do 
> not announce us to AS123456.
>
> But I think second problem is not very important for me. If someone cannot 
> send 4B community so.. it is a pitty for him. My problem is to let people 
> know what we can accept and process if they wish and can send us their 
> preferences. Thus - I need to work with 4B communities in most common way 
> possible.
>
> So yes - I would be happy to find an example which would work with 4B 
> extended communities both - for myas and peeras sides. If I am right with 
> SIXT example - bgp_ext_community are supported for peeras? If yes - the 
> only problem is myas which still can't be 4B. But I may replace it with 
> fake-16bit-pseudo-myas ;-]. All should be working then?
>
> Best wishes,
>
> Peter
>
>
>
> -----Oryginalna wiadomość----- From: Ondrej Zajicek
> Sent: Monday, January 22, 2018 4:16 PM
> To: Piotr Marciniak
> Cc: bird-users at network.cz
> Subject: Re: Community for small IX - problem with 4B ASN
>
> Well, that depends on exact meaning of 'communities'. There are three
> different independent community attributes:
>
> - 'traditional' communities (RFC 1997)
> - Extended communities (RFC 4360)
> - Large communities (RFC 8092)
>
> Attribute bgp_community is for traditional communities, which are limited
> to 16 bit components. So you cannot use 32bit ASNs with them. Also, even
> if you used 16bit private ASN as myas, you cannot use them for 32bit
> peeras.
>
> You can use Extended communities (and that is usual setting in IXes),
> but they can have one component 32 bit, but not both. So if you have
> 16bit myas, you could have 32bit peeras.
>
> Or you can use new Large communities, which are fully 32bit, and ditch
> both traditional and Extended communities. But this is pretty new
> standard and i am not sure how widely is supported by other systems.
>