Any IX willing to share their config?

[Mikhail A. Grishin]

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.
>