On Mar 11, 2015, at 2:59 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 11/Mar/15 20:51, Jared Mauch wrote:
NTT (2914) tags routes based on if they are a customer, peer and with geographic communities based on where the route enters our network. Many networks perform similar techniques and you can find details at various websites or this one:
http://www.onesc.net/communities/
You will likely get far more accurate data.
The trick with relying on BGP communities to map routing data is that their propagation between AS's is not always guaranteed.
True, they also can get marked, remarked, or dropped at various network edges. This is why I was suggesting taking the data directly from the MRT files at route-views. I’ve been using this for the routing leak detector just processing the updates over the years and it’s way easier to process a smaller update file than diff the entire RIB dump. (at least for that use-case). <rant=start> Many people who do BGP don’t do a good job with their policy which is how you end up with these full table leaks and seemingly random routes appear that hairpin through networks. eg: 59.188.253.0/24 2497 701 6453 45474 174 17444 It’s unlikely that 6453 or 701 should really be using 45474 to reach 174 or their customer 17444. This has a lot to do with IOS devices which by default send all routes to all configured peers. Cisco does a particularly poor job of educating it’s CCIE and other graduates of this fact. IOS-XR can be made to do the same thing, but requires explicitly enabling this problematic behavior. Similarly send-community on IOS requires beyond the basic “neighbor 1.2.3.4 remote-as 5” type config. <rant=end> - Jared