Any IX willing to share their config?

[Alexander Shikoff]

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