As I think we are done talking about DNS, I have been looking at our routing tables as of late. I am seeing that many providers with blocks of address space do not aggregate the addresses. I think that if this is so, there needs to be something done to fix it. Once again, we are not even getting a full BGP table and know that if I see problems on a smaller scale, their most be more of these problems out there. thanks Christian Nielsen Vyzynz International Inc. cnielsen@vii.com,CN46,KB7HAP Phone 801-568-0999 Fax 801-568-0953 Private Email - Christian@Nielsen.Net BOFH - cnielsen@one.dot PS :)
As I think we are done talking about DNS, I have been looking at our routing tables as of late. I am seeing that many providers with blocks of address space do not aggregate the addresses. I think that if this is so, there needs to be something done to fix it.
Once again, we are not even getting a full BGP table and know that if I see problems on a smaller scale, their most be more of these problems out there.
thanks
Take a look at http://www.routes.netaxs.com for the output of an aggregation suggestor we use. Obviously, there are cases where it's desired to advertise more specific routes, but we do see many route advertisements that are probably superfluous.
Christian Nielsen
Avi
There is a HUGE problem with regards to this. When I look at "certain" providers and the way they are advertising, this is very common: 206.79.0.0/16 206.79.108.0/24 206.79.224.0/22 etc etc. They are advertising their 16 right, and then are putting more specific routes in afterwards. Doesn't make much sense, however I can see certain situations why it is happening.. In certain circumstances, the people will advertise every class C in a /16 as well as advertising the /16. It's turned into something worse than pre-CIDR. The above addresses are Exodus Communications. I don't want to turn this into a pointing of fingers thread. Robert Bowman Sr. Hole Plugger Exodus Communications Inc. rob@exodus.net (408) 522-8473
As I think we are done talking about DNS, I have been looking at our routing tables as of late. I am seeing that many providers with blocks of address space do not aggregate the addresses. I think that if this is so, there needs to be something done to fix it.
Once again, we are not even getting a full BGP table and know that if I see problems on a smaller scale, their most be more of these problems out there.
thanks
Christian Nielsen Vyzynz International Inc. cnielsen@vii.com,CN46,KB7HAP Phone 801-568-0999 Fax 801-568-0953 Private Email - Christian@Nielsen.Net BOFH - cnielsen@one.dot PS :)
Sounds like a good reason to agressively aggregate, unless people indicate that there are reasons (like part of the /16 is dual homed) for not doing so for specific blocks. I prefer this over most of the "not routing larger prefixes" thing.
In certain circumstances, the people will advertise every class C in a /16 as well as advertising the /16. It's turned into something worse than pre-CIDR.
Sometimes more-specifics are needed to compete against more-specifics being incorrectly advertised by other people. Sometimes folks _insist_ on cutouts, and you have to go route-to-route against them if you want to keep your block intact. I hate this, it's bad business, I don't do it myself, I don't let my customers do it, but I've seen it often enough to have it be worth mentioning.
Sometimes more-specifics are needed to compete against more-specifics being incorrectly advertised by other people. Sometimes folks _insist_ on cutouts, and you have to go route-to-route against them if you want to keep your block intact. I hate this, it's bad business, I don't do it myself, I don't let my customers do it, but I've seen it often enough to have it be worth mentioning.
If you've got a larger block (say, a /16) and a customer with a /24 becomes dual-homed and wants to split the incoming traffic on his links, you're stuck advertising the /24 as well as the /16; otherwise, their 2nd provider will always win for incoming traffic from most of the 'net... However, the 2nd path to a route consumes a LOT less memory than an additional path. We do this for 1 customer right now, and possibly 1 in the near future. Luckily, the demand for this is mostly limited to ISPs rather than other types of companies... Avi
In message <199604280751.AAA00306@elite.exodus.net>, Robert Bowman writes:
There is a HUGE problem with regards to this. When I look at "certain" providers and the way they are advertising, this is very common:
206.79.0.0/16 206.79.108.0/24 206.79.224.0/22
etc etc.
Note that only 206.79.0.0/16 is registered in the IRR. 206.79.0.0/17, 206.40.64.0/19 are also registered but not announced. I don't know the situation in this case but they may be intending to aggreagate but not entirely suceeding. For example, the /24 may be a DMZ between providers which another provider needs for management. I'm working on some routing evaluation software and a secondary benefit of this may be to get some stats on this sort of problem. There may be over 1,000 such more specific prefixes, not registered in the and covered by aggregates that are registered in the IRR and announced. There are still bugs in the radix tree code but ones I've checked manually this morning indicate that the bugs may be reducing the estimate rather than inflating it. Curtis
participants (6)
-
Avi Freedman -
Christian Nielsen -
Curtis Villamizar -
jon＠branch.com -
Paul A Vixie -
Robert Bowman