Any IX willing to share their config?
We are a new Internet Exchange in Minneapolis, MN, USA. Currently evaluating BIRD as our route server. Basic config working in lab with both IPv4 & IPv6 daemon. Would like to see another IX's configuration to see how they are handling filtering, sessions, convention, etc. Thank you in advance, James C. Montz Midwest Internet Cooperative Exchange http://www.micemn.net
Google is your friend :) http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg00696.htm... -Thomas From: owner-bird-users@atrey.karlin.mff.cuni.cz [mailto:owner-bird-users@atrey.karlin.mff.cuni.cz] On Behalf Of James Montz Sent: den 30 november 2010 16:34 To: Bird Users Mail List Subject: Any IX willing to share their config? We are a new Internet Exchange in Minneapolis, MN, USA. Currently evaluating BIRD as our route server. Basic config working in lab with both IPv4 & IPv6 daemon. Would like to see another IX's configuration to see how they are handling filtering, sessions, convention, etc. Thank you in advance, James C. Montz Midwest Internet Cooperative Exchange http://www.micemn.net
On 01.12.2010 10:31 Vitaliy Kolodinsky wrote
Unfortunately the file is unavailable http://download.de-cix.net/bird.conf.gz
has moved to http://download.de-cix.net/bird.tar.gz HTH, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333
On Tue, Nov 30, 2010 at 09:34:25AM -0600, James Montz wrote:
We are a new Internet Exchange in Minneapolis, MN, USA. Currently evaluating BIRD as our route server.
Basic config working in lab with both IPv4 & IPv6 daemon.
Would like to see another IX's configuration to see how they are handling filtering, sessions, convention, etc.
Hello, We have one configuration issue in our IXP that can be interesting for those who use BIRD as route server. 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:XXXXX - Do not announce route to peer XXXXX 0:MyASN - Do not announce route to all peers MyASN:XXXXX - Announce route to peer XXXXX only MyASN:MyASN - Announce routes to all peers. This community is automatically added to all routes that are not tagged with any of MyASN:XXXXX communities. We had no customers with 32bit ASNs before and that request made us a bit confused: we're using BIRD as route-server and it does not support BGP extended communities. And now we're wondering how to include support for 32bit ASNs into such policy? 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. The function below implements described policy. In addition, it marks outgoing prefixes from route-server in the same way. function bgp_out (int peer_as) int asn_h; int asn_l; int t; { # # Announce only BGP routes # if ! (source = RTS_BGP ) then return false; # # Do not advertise route with 0:MyASN community # 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 asn_h = peer_as/65536; # Get low 16 bits of Peer's ASN asn_l = peer_as-asn_h*65536; # Do not advertise route with [ 65000:asn_h, 0:asn_l ] communities if ( (65000,asn_h) ~ bgp_community && (0,asn_l) ~ bgp_community) then return false; # Advertise a route with [ 65000:asn_h, MyASN:asn_l ] communities or with MyASN:MyASN community if ( ( (65000,asn_h) ~ bgp_community && (MyASN,asn_l) ~ bgp_community) || (MyASN,MyASN) ~ bgp_community ) then { bgp_community.delete([ (0,0)..(65535,65535) ]); if bgp_path.first > 65535 then { # Bug (?) Workarond. # bgp_community.add((MyASN,bgp_path.first-bgp_path.first/65536*65536)); - does not work t = bgp_path.first/65536; bgp_community.add((65000,t)); t = t * 65536; bgp_community.add((MyASN,bgp_path.first-t)); } else bgp_community.add((MyASN,bgp_path.first)); return true; } return false; # We should never reach this... } else { if ((MyASN,peer_as) ~ bgp_community || (MyASN,MyASN) ~ bgp_community) then { bgp_community.delete([ (0,0)..(65535,65535) ]); if bgp_path.first > 65535 then { # Bug (?) Workarond. # bgp_community.add((MyASN,bgp_path.first-bgp_path.first/65536*65536)); - does not work t = bgp_path.first/65536; bgp_community.add((65000,t)); t = t * 65536; bgp_community.add((MyASN,bgp_path.first-t)); } else bgp_community.add((MyASN,bgp_path.first)); return true; } else return false; } # Do not advertise route in any another cases return false; } Comments, optimizations are heartily appreciated! -- MINO-RIPE
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:XXXXX - Do not announce route to peer XXXXX 0:MyASN - Do not announce route to all peers MyASN:XXXXX - Announce route to peer XXXXX only MyASN:MyASN - Announce routes to all peers. This community is automatically added to all routes that are not tagged with any of MyASN:XXXXX 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. 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". -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
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:XXXXX - Do not announce route to peer XXXXX
> > 0:MyASN - Do not announce route to all peers
> > MyASN:XXXXX - Announce route to peer XXXXX only
> > MyASN:MyASN - Announce routes to all peers. This community is
> > automatically added to all routes that are not
> > tagged with any of MyASN:XXXXX 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));
return true;
} else
return false;
} else {
# Do not advertise a route with 0:peer_as community
if (0,peer_as) ~ bgp_community then return false;
# Advertise a route with MyASN:peer_as community or with MyASN:MyASN community
if ((MyASN,peer_as) ~ 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));
return true;
} else
return false;
}
# Do not advertise route in any another cases
return false;
}
--
MINO-RIPE
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: santiago@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."
Am 25.12.2010 11:57, schrieb Ondrej Zajicek:
On Sat, Dec 25, 2010 at 05:03:46AM +0200, Alexander Shikoff wrote:
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).
unfortunately there is no one-to-one and onto mapping between 32bit ASN and ASN from private range which makes it impossible to come up with a general solution. Otoh a first come first serve assignment at each IXP will for sure lead to different mappings 32bit ASN <-> private ASN which makes it really cumbersome for ISP's connected to more than one IXP. A better approach might be to use extended communities. However iirc the problem there is that you only have 48 bits left. You could work around that by splitting the range in 24bit/24bit which would of course be sufficient for nowadays ASN in use, but make it cumbersome to calculate the values to set. Best regards and happy holidays, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany
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. > > - 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. > > 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. > > ------------------- 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. -- MINO-RIPE
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. >
participants (7)
-
Alexander Shikoff -
Arnold Nipper -
James Montz -
Mikhail A. Grishin -
Ondrej Zajicek -
Thomas Althoff -
Vitaliy Kolodinsky