> On Mar 11, 2015, at 2:59 PM, Mark Tinka <[email protected]> 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
