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: [email protected]
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: [email protected]
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.
