Re: Any IX willing to share their config?
Alexander Shikoff wrote, 25.12.2010 15:50: On Sat, Dec 25, 2010 at 11:57:04AM +0100, Ondrej Zajicek wrote: On Sat, Dec 25, 2010 at 05:03:46AM +0200, Alexander Shikoff wrote: One possible way to do that is not to try handle full 32bit ASNs, but perhaps just ~ 24bit ASNs and use communities (65000..65255,*) for (65000+X,Y) - Do not announce to peer X*65536+Y and similarly communities (65256..65511,*) for: (65256+X,Y) - Announce to peer X*65536+Y only. You're right. If I remember correctly IANA currently allocates 1024 numbers for each RIR, so your variant covers them entirely for some future years. Some additional thoughts: - this way breaks RFC1997 a little - current draft Internet Exchange Route Server (http://tools.ietf.org/html/draft-jasinska-ix-bgp-route-server-01) does not propose in details how to implement handling of 32bit ASNs via communities. Developers of this draft invite to comment this document (at Euro-IX community mailing list this summer). You may send some suggestions. - there is RFC5668 (4-Octet AS Specific BGP Extended Community, http://tools.ietf.org/search/rfc5668) but it defines only 2 octets for Local Administrator field. So BGP Ext. community support will not also allow easy implementation of 32bit ASN handling. I've googled around this problem and have not find yet another ideas/discussions etc. So your way seems to be most easy and effective at present moment. Another, even simpler, way is to assign each connected client with 32bit ASN some pseudo-ASN from private range. This pseudo-ASN would be used with standard communities (0:X, MyASN:X). MSK-IX uses this way. We not expect very large number of direct connected members with ASN 65535 in few next years. Most new members still have ASN16 numbers. Some have ASN32 and then migrated to ASN16 (due various difficulties: ddos protection, direct peerings etc.) So we can wait for new RFC with Extended Communities or for some other solution. RFC1997 community 'no-export' is also supported. Other communities including RFC1997 well-known ones are not supported and stripped. That seems a bit strange to me. Not sure what the other IXPs do but i think that communities are supposed to be propagated and RS should alter only communities destined for it. RFC1997 allows modification of community attribute according to a local policy. But Internet Exchange Route Server draft _recommends_ transparate propagation. But this recommendation requires consideration of possible security or routing issues (asymmetry etc). Just because of security/routing issues almost all of our members delete all communities received from IXP or those are not listed in IXP routing policy. If other IXP engineers are reading this maillist it would be great to hear their opinions. What's about well-known communities: for example, MSK-IX propagates 'no-export' transparately to peers. I think this approach does not meet RFC1997. MSK-IX does not support 'no-advertise' (0:MyASN is used instead). We're using 'no-export' only in an approach described by RFC1997. Our customers wanted to be able to announce some routes with 'no-export' transparently to other MSK-IX participants. That was before the BIRD became our main platform and before we implemented full-featured communities to our customers. At present, you can to propagate 'no-export' with the special community: http://www.msk-ix.ru/eng/routeserver.html#bgpcommunity Btw, as I remember, among other UNIX BGP daemons also there are some transparency with 'no-export'. Any transparent Route Server at every IXP by its nature doesn't meet RFC4271 (transparent RS doesn't update as-path attribute). All current inconsistency, including RFC1997 breaks, better to consider in the RFC about Route Servers. --- Communities sent to peers -- MyASN:X - Route is received from 16-bit ASN X 6550X:Y - Route is received from 32-bit ASN 65535*X+Y What purpose have these communities? That can be easily read from AS_PATH. If certain peer makes filters based not on AS_PATH but on community then these ones can help it.
Re: Any IX willing to share their config?
On Sat, Dec 25, 2010 at 05:03:46AM +0200, Alexander Shikoff wrote: One possible way to do that is not to try handle full 32bit ASNs, but perhaps just ~ 24bit ASNs and use communities (65000..65255,*) for (65000+X,Y) - Do not announce to peer X*65536+Y and similarly communities (65256..65511,*) for: (65256+X,Y) - Announce to peer X*65536+Y only. You're right. If I remember correctly IANA currently allocates 1024 numbers for each RIR, so your variant covers them entirely for some future years. Some additional thoughts: - this way breaks RFC1997 a little - current draft Internet Exchange Route Server (http://tools.ietf.org/html/draft-jasinska-ix-bgp-route-server-01) does not propose in details how to implement handling of 32bit ASNs via communities. - there is RFC5668 (4-Octet AS Specific BGP Extended Community, http://tools.ietf.org/search/rfc5668) but it defines only 2 octets for Local Administrator field. So BGP Ext. community support will not also allow easy implementation of 32bit ASN handling. I've googled around this problem and have not find yet another ideas/discussions etc. So your way seems to be most easy and effective at present moment. Another, even simpler, way is to assign each connected client with 32bit ASN some pseudo-ASN from private range. This pseudo-ASN would be used with standard communities (0:X, MyASN:X). RFC1997 community 'no-export' is also supported. Other communities including RFC1997 well-known ones are not supported and stripped. That seems a bit strange to me. Not sure what the other IXPs do but i think that communities are supposed to be propagated and RS should alter only communities destined for it. --- Communities sent to peers -- MyASN:X - Route is received from 16-bit ASN X 6550X:Y - Route is received from 32-bit ASN 65535*X+Y What purpose have these communities? That can be easily read from AS_PATH. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) To err is human -- to blame it on a computer is even more so. signature.asc Description: Digital signature
Re: Any IX willing to share their config?
On Sat, Dec 25, 2010 at 01:53:23AM +0100, Ondrej Zajicek wrote:
On Fri, Dec 24, 2010 at 11:07:41PM +0200, Alexander Shikoff wrote:
Some days ago our IXP received a connection request from customer with
32bit
ASN. We use the same BGP policy as many other IXes do:
0:X - Do not announce route to peer X
0:MyASN - Do not announce route to all peers
MyASN:X - Announce route to peer X only
MyASN:MyASN - Announce routes to all peers. This community is
automatically added to all routes that are not
tagged with any of MyASN:X communities.
...
The idea is to store high 16 bits and low 16 bits of ASN separately
in two communities, for example:
65000:0x0003, 0:0x02D7 - Do not announce prefix to peer with ASN 0x000302D7
Then put a check of 65000:* in filter.
This could not really work. By old convention, if i would like to not
announce the route to peers 3, 5 and 7, i would add communities (0,3),
(0,5) and (0,7). But by your convention, if i would like to not announce
the route to peers 0x000201A3 and 0x000302D7, i would add
(65000,0x0002), (0,0x01A3), (65000,0x0003) and (0,0x02D7), But that
would also block announcing to 0x000301A3 and 0x000202D7.
Yep, I'm stupid.
One possible way to do that is not to try handle full 32bit ASNs, but
perhaps just ~ 24bit ASNs and use communities (65000..65255,*) for
(65000+X,Y) - Do not announce to peer X*65536+Y and similarly
communities (65256..65511,*) for: (65256+X,Y) - Announce to peer
X*65536+Y only.
You're right.
If I remember correctly IANA currently allocates 1024 numbers for each
RIR, so your variant covers them entirely for some future years.
Some additional thoughts:
- this way breaks RFC1997 a little
- current draft Internet Exchange Route Server
(http://tools.ietf.org/html/draft-jasinska-ix-bgp-route-server-01)
does not propose in details how to implement handling of 32bit ASNs
via communities.
- there is RFC5668 (4-Octet AS Specific BGP Extended Community,
http://tools.ietf.org/search/rfc5668) but it defines only 2 octets
for Local Administrator field. So BGP Ext. community support
will not also allow easy implementation of 32bit ASN handling.
I've googled around this problem and have not find yet another
ideas/discussions etc. So your way seems to be most easy and effective
at present moment.
Finally, what I have now... Policy:
Communities accepted from peers ---
* Communities affecting announces to 16-bit ASN peers
0:X - Do not announce route to peer X
MyASN:X - Announce route to peer X only
* Communities affecting announces to 32-bit ASN peers
6500X:Y - Do not announce route to peer 65536*X+Y
6510X:Y - Announce route to peer 65536*X+Y only
* Communities affecting announces to both 16-bit and 32-bit ASN peers
0:MyASN - Do not announce route to all peers
MyASN:MyASN - Announce routes to all peers. This
community is automatically added to all
routes that are not tagged with
MyASN:* or 6510X:Y communities.
RFC1997 community 'no-export' is also supported. Other communities
including RFC1997 well-known ones are not supported and stripped.
--- Communities sent to peers --
MyASN:X - Route is received from 16-bit ASN X
6550X:Y - Route is received from 32-bit ASN 65535*X+Y
And function (if someone is still interested):
function bgp_out (int peer_as)
int X;
int Y;
{
#
# Announce only BGP routes
#
if ! (source = RTS_BGP ) then return false;
#
# Do not advertise route with 0:MyASN community
# It is done for peers without no-advertise RFC1997 community support
#
if (0,MyASN) ~ bgp_community then return false;
#
# Check for 32-bit ASN
#
if peer_as 65535 then {
# Get high 16 bits of Peer's ASN
X = peer_as/65536;
# Get low 16 bits of Peer's ASN
Y = peer_as-X*65536;
# Do not advertise route with 6500X:Y community
if (65000+X,Y) ~ bgp_community then
return false;
# Advertise a route with 6510X:Y community or with MyASN:MyASN
community
if ( (65100+X,Y) ~ bgp_community ||
(MyASN,MyASN) ~ bgp_community ) then {
bgp_community.delete([ (0,0)..(65535,65535) ]);
if bgp_path.first 65535 then
bgp_community.add((65500+(bgp_path.first)/65536,
(bgp_path.first)-(bgp_path.first)/65536*65536));
else
bgp_community.add((MyASN,bgp_path.first));
