On Tue, 17 Jan 2006, Nikolay Datchev wrote: No one. You ask politely. Either they will cooperate or not. I believe that is the basis of the Internet. :-) -Hank
Who will give us the right to ask people to change their working configs ?
-- Nikolay Datchev
On Tue, 17 Jan 2006, Hank Nussbacher wrote:
On Tue, 17 Jan 2006, Nikolay Datchev wrote:
I'm glad to know that i'm not the only one who does a show ip bgp regexp _6(4|5)..._ and does care of it.
Much easier to scroll down to the bottom of: http://bgp.potaroo.net/cidr/#Bogons
Incidentally, I've been on IHUG now for over 2 months and about 1 email a week. Some cases are just very hard to crack. I have now approached their upstream - Asiatelecom.
So, this is lot of work, and let's abandon it... No. Lot of networks are taken over by another company, and lot of configurations are just "legacy". - the lazyness and the reason "it works, don't touch" are almost everywhere. It's full in my country with such networks. Having a VALID reason to deaggregate is OK, i'm also doing this. But "avoiding blackholing" is not a valid reason.
Of course, if you just email to someone and say "please, aggregate", most of people will think "yeah, right now..." and just ignore it. But if RIR-authorized person says "I'm from RIPE working group. I cannot see a valid reason to not aggregate these networks. Please aggregate, or give a valid reason to deaggregate, or some day you will suffer from peer pressure", it's a different case. Especially with LIR's.
When I did it, Barry Greene and others volunteered their time to review configs to help ISPs fix their leakages that they may not have known how to do. The problem is those that leak because they want to leak.
To be successful, one has to not only notify the leaker but also be prepared to help him/her with their Junos/IOS configs.
Get 4-5 people willing to volunteer 5-10 hours per month and I'm on board.
Regards, Hank
-- Nikolay Datchev
On Tue, 17 Jan 2006, Hank Nussbacher wrote:
On Tue, 17 Jan 2006, Nikolay Datchev wrote:
Been there. Done that. See Oct 2002 NANOG presentation: http://www.nanog.org/mtg-0302/cidr.html
I currently have been attacking Bogon ASNs (AS64xxx) and have managed to get almost all removed over a period of 4 months. Tackling the prefix deaggregators is a much larger task and would need 3-4 dedicated volunteers in order to begin. And one can always email to some unknown whois contact. Almost all are friendly and some will say 'sorry, I deaggregate for the following reason..." and not much can be done to change their minds.
-Hank
Hello group,
I want to raise up again the question about world BGP routing table. I don't know what is the result after last discussion (Oct.2005), but maybe peer pressure is not the only way to follow regarding the solution. What a big transit provider can do about customers of it's customer, which politics is "i pay, so i want to do what i want with my AS/prefixes"? I know network administrator, who says "I advertise all my networks as /24's (few /19's...), just because i don't want somebody else to be able to advertise them as more specifics and blackhole me - this is our security policy". There are others, whit PA space, not multihomed, but with own AS number, advertising specific networks just because "it's cool to use my AS number". Or even worse - the combination of the two mentioned above. Also, there are administrators who don't know about aggregating - "I got my 8 class C networks from my LIR, and i advertise them one by one".
We have tools like CIDR-repors. Think about this scenario: volunteers spending few hours per week and catching such networks, contacting via email the network administrators, and ask them to aggregate. I have success with this, but only for administrators that i know personally. But i feel inconvenience to contact other people and to say them "Why you don't aggregate your networks? Help for stopping routing table growth!" It sounds sluggish, but it's more than nothing.
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.