Discussion:
Any IX willing to share their config?
James Montz
2010-11-30 15:34:25 UTC
Permalink
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
Thomas Althoff
2010-12-01 07:14:13 UTC
Permalink
Google is your friend :)

http://www.mail-archive.com/bird-***@atrey.karlin.mff.cuni.cz/msg00696.html

-Thomas




From: owner-bird-***@atrey.karlin.mff.cuni.cz [mailto:owner-bird-***@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
Vitaliy Kolodinsky
2010-12-01 09:31:50 UTC
Permalink
<html><head><title>Re: Any IX willing to share their config?</title>
<META http-equiv=Content-Type content="text/html; charset=windows-1251">
</head>
<body>
<span style=" font-family:'Courier New'; font-size: 9pt;">Dear, Thomas Althoff.<br>
<br>
Вы писали 1 декабря 2010 г., 9:14:13:<br>
<br>
Unfortunately the file is unavailable<br>
<a href="http://download.de-cix.net/bird.conf.gz">http://download.de-cix.net/bird.conf.gz</a><br>
<br>
</span><table>
<tr>
<td width=10 bgcolor= #0000ff><br>
</td>
<td width=737><span style=" font-family:'calibri'; font-size: 11pt; color: #1f497d;">Google is your friend&nbsp;<span style=" font-family:'wingdings';">J<br>
<span style=" font-family:'calibri';">&nbsp;<br>
<a href="http://www.mail-archive.com/bird-***@atrey.karlin.mff.cuni.cz/msg00696.html">http://www.mail-archive.com/bird-***@atrey.karlin.mff.cuni.cz/msg00696.html</a><br>
&nbsp;<br>
-Thomas<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
<span style=" font-family:'tahoma'; font-size: 10pt; color: #000000;"><b>From:</b>&nbsp;owner-bird-***@atrey.karlin.mff.cuni.cz [mailto:owner-bird-***@atrey.karlin.mff.cuni.cz]&nbsp;<b>On Behalf Of&nbsp;</b>James Montz<br>
<b>Sent:</b>&nbsp;den 30 november 2010 16:34<br>
<b>To:</b>&nbsp;Bird Users Mail List<br>
<b>Subject:</b>&nbsp;Any IX willing to share their config?<br>
<span style=" font-family:'times new roman'; font-size: 12pt;">&nbsp;<br>
We are a new Internet Exchange in Minneapolis, MN, USA. &nbsp; Currently evaluating BIRD as our route server.&nbsp;<br>
&nbsp;<br>
Basic config working in lab with both IPv4 &amp; IPv6 daemon.&nbsp;<br>
Would like to see another IX's configuration to see how they are handling filtering, sessions, convention, etc.<br>
&nbsp;<br>
Thank you in advance,<br>
&nbsp;<br>
James C. Montz<br>
&nbsp;<br>
Midwest Internet Cooperative Exchange<br>
<a href="http://www.micemn.net">http://www.micemn.net</a></td>
</tr>
</table>
<br><br>
<br>
<br>
<span style=" font-family:'Courier New'; font-size: 9pt;">--<br>
<br>
Best regards,<br>
Vitaliy<br>
Kolodinsky<br>
BYVK-RIPE<br>
ISP Atlant Telecom<br>
<a href="mailto:***@telecom.by">***@telecom.by</a></body>
Arnold Nipper
2010-12-02 00:01:19 UTC
Permalink
Post by Vitaliy Kolodinsky
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: ***@nipper.de phone: +49 6224 9259 299
mobile: +49 152 53717690 fax: +49 6224 9259 333
Alexander Shikoff
2010-12-24 21:07:41 UTC
Permalink
This post might be inappropriate. Click to display it.
Ondrej Zajicek
2010-12-25 00:53:23 UTC
Permalink
Post by Alexander Shikoff
Some days ago our IXP received a connection request from customer with 32bit
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.
...
Post by Alexander Shikoff
The idea is to store high 16 bits and low 16 bits of ASN separately
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: ***@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."
Alexander Shikoff
2010-12-25 03:03:46 UTC
Permalink
Post by Ondrej Zajicek
Post by Alexander Shikoff
Some days ago our IXP received a connection request from customer with 32bit
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.
...
Post by Alexander Shikoff
The idea is to store high 16 bits and low 16 bits of ASN separately
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.
Post by Ondrej Zajicek
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
Ondrej Zajicek
2010-12-25 10:57:04 UTC
Permalink
Post by Alexander Shikoff
Post by Ondrej Zajicek
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.
- 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).
Post by Alexander Shikoff
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.
Post by Alexander Shikoff
------------------- 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: ***@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."
Arnold Nipper
2010-12-25 12:19:04 UTC
Permalink
Post by Ondrej Zajicek
Post by Alexander Shikoff
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
email: ***@nipper.de phone: +49 6224 9259 299
mobile: +49 152 53717690 fax: +49 6224 9259 333
Alexander Shikoff
2010-12-25 12:50:33 UTC
Permalink
Post by Ondrej Zajicek
Post by Alexander Shikoff
Post by Ondrej Zajicek
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.
- 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.
Post by Ondrej Zajicek
Post by Alexander Shikoff
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.
Post by Ondrej Zajicek
Post by Alexander Shikoff
------------------- 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
Mikhail A. Grishin
2010-12-27 15:23:51 UTC
Permalink
Post by Alexander Shikoff
Post by Ondrej Zajicek
Post by Alexander Shikoff
Post by Ondrej Zajicek
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.
- 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.
Post by Alexander Shikoff
Post by Ondrej Zajicek
Post by Alexander Shikoff
- 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.
Post by Alexander Shikoff
Post by Ondrej Zajicek
Post by Alexander Shikoff
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.
Post by Alexander Shikoff
Post by Ondrej Zajicek
Post by Alexander Shikoff
------------------- 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.
Loading...