[ixpmanager] Order of customers' config in the RS configuration of the IXP manager

Wed Dec 10 12:26:56 GMT 2014

Hello,

We (GR-IX) are putting two bird route servers into production, and we 
try to take advantage of the IXP manager RS functionality in order to 
produce our bird configuration.

The IXP manager does a great job creating the bird configuration through 
the skinned templates. What is missing, however, is a way to push the 
configuration to the route servers, check it, load it, and maybe notify 
the admins. For that reason we are writing a script that:
a) updates the IXP manager ASN and prefixes database
b) produces the bird configuration
c) compares with the old bird config, notify us about changes
d) push the configuration to the route servers
Then, the route servers need to get reloaded; manually or 
semi-automatically at the begging, automatically later.

As we are just putting this service in production, step C is important 
for us in order to ensure that all other parts work correct, before 
fully automating the process. This means that human will get the 
configuration changes and review them before these are loaded to the 
route servers.

And now our problem: If a customer has more that one connections (i.e, 
there are at least two different #vliid}, the order that these will be 
processed by the IXP manager is random. That is, on some runs, the 
configuration for vliid X (as produced by neighbor.cfg) may proceed the 
configuration of vliid Y, while on other runs Y proceeds to X. Although 
the configuration produced for each vliid does not change between runs, 
the order within the produced file changes. This causes diffs to appear, 
which require unnecessary human attention. (You can find our 
neighbor.cfg file at the end of this email)

Let me add that the changes in the order are very frequent, once every 
two or three runs, although nothing changes in the IXP database.

Before filing a feature request, I wonder how other IXP-manager users 
handle this: Do you use a different procedure to update the route 
servers? Do humans need to review the changes before getting applied (or 
at least they get notified)? Do you solve the problem in a different 
approach?

Also, if someone would be interested to share scripts, we would 
certainly appreciate it. And we would be glad to upload ours if such a 
repository exists somewhere.

Thank you in advance,

PS: our bird setup + IXP manager templates are described at the euro-ix 
wiki
https://wiki.euro-ix.net/index.php/BCP/Technical/Routeserver/BIRD/Samples/GR-IX. 

I understand that some of the members of this list may not have access 
there, please let me know if you are interested.

-------------

### Customer ID: {$int.cid} - Full name: {$int.cname} - Shortname: {$int.cshortname}
### AS number: {$int.autsys} - IPv4/6 address: {$int.address} - ID in peering VLAN: {$int.vliid} ({$int.fvliid})
### Full location name: {$int.location_name} - Location shortname: {$int.location_shortname} - Location tag: {$int.location_tag}
### Peering macro: {$int.peeringmacro} - Maximum # of prefixes: {$int.maxprefixes} - BGP MD5 secret: {$int.bgpmd5secret}

table t_{$int.cshortname}{$int.vliid};

filter peer_{$int.cshortname}{$int.vliid}_to_master
prefix set allnet;
int set allas;
{
	# Basic prefix validation. Do not propagate funny prefixes.
	# Check first AS in AS-PATH, esp to prevent route servers peering to each other
         if !(avoid_martians()) then reject;
         if (bgp_path.first != {$int.autsys} ) then reject;

{* Only do filtering if this is enabled per client *}
{if $int['irrdbfilter'] }
	# Check AS-PATH against the appropriate IRRDB macro
         allas = [ {foreach $irrdbAsns as $a}{$a.asn}{if not $a at last},{/if} {if $a at iteration % 10 == 0}

                   {/if}{/foreach} ];

         if !(bgp_path.last ~ allas) then reject;

{if count( $prefixes )}
	# Check each prefix against the route objects originating from the ASNs in the appropriate IRRDB macro
         allnet = [ {foreach $prefixes as $p}{$p.prefix}{if not $p at last},{/if} {/foreach} ];

         if ! (net ~ allnet) then reject;
{else}
         # Deny everything because the IRRDB returned nothing
         reject;
{/if}
{else}
         # This ASN was configured not to use IRRDB filtering
{/if}

	# Prepend 1,2,3 times, if (RSasn,65001), (RSasn,65002), (RSasn,65003) have been set
	if (RSasn,65501) ~ bgp_community then bgp_path.prepend(RSasn);
	if (RSasn,65502) ~ bgp_community then { bgp_path.prepend(RSasn); bgp_path.prepend(RSasn); }
	if (RSasn,65503) ~ bgp_community then { bgp_path.prepend(RSasn); bgp_path.prepend(RSasn); bgp_path.prepend(RSasn); }

	# Mark prefixies with "site" community
{if $int.location_shortname eq "EIE"}
	bgp_community.add ((RSasn,65101));
{/if}
{if $int.location_shortname eq "LH"}
	bgp_community.add ((RSasn,65102));
{/if}
{if $int.location_shortname eq "MED"}
	bgp_community.add ((RSasn,65103));
{/if}

	# Done filtering & manipulation. Accept!
         accept;
}

protocol pipe p_{$int.cshortname}{$int.vliid} {
	description "Pipe for {$int.cshortname}{$int.vliid} (AS{$int.autsys} - {$int.address})";
	table master;
	mode transparent;
	peer table t_{$int.cshortname}{$int.vliid};
	import filter peer_{$int.cshortname}{$int.vliid}_to_master;
	export where master_to_as({$int.autsys},"{$int.location_shortname}");
}

protocol bgp b_{$int.cshortname}{$int.vliid} from grix_rs_client {
	description "BGP for {$int.cshortname}{$int.vliid} (AS{$int.autsys} - {$int.address})";
	neighbor {$int.address} as {$int.autsys};
	route limit {$int.maxprefixes};
	table t_{$int.cshortname}{$int.vliid};
	bfd on; # This should be configured for specific peers in the future.
{if $int.bgpmd5secret}	password "{$int.bgpmd5secret}";{/if}
}

---------------------------------------

-- 
-----------------------------------------------------------------------
Andreas Polyrakis - apolyr at noc.grnet.gr
GRNET NOC Technical Manager
Greek Research & Technology Network - http://www.grnet.gr
56, Mesogion Av., Ampelokipi, 11527 Athens, Greece
Mobile: +30 6972832445    Office: +30 2107474249   Fax: +30 2107474490
-----------------------------------------------------------------------