Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise routes for whatever IP addresses they want?
route-views.oregon-ix.net>sh ip bgp 173.45.110.0 | i 13768
2905 701 3561 13768
1221 4637 3561 13768
3549 3561 13768
3277 3267 174 3561 13768
6539 3561 13768
16150 3549 3561 13768
701 3561 13768
3267 174 3561 13768
6453 3561 13768
3582 3701 3356 3561 13768
This is probably a fairly major problem...
-Drew
Anyone know why SAAVIS would be allowing PEER1 (AS 13768) to advertise routes for whatever IP addresses they want?
sadly savvis didn't learn the pccw lesson, which is also the
turk-telecom lesson which is also the as7007 lesson which is... fairly
sad really in 2009.
for the sake of $diety put a prefix-filter on your customer bgp
sessions, it ain't hard!
-chris
sounds too much like "work" to me. not interested.
-Dan
The irony is that MCI had (and C&W maintained for quite some time)
a functional, highly automated IRR-based customer filtering system
[props to the Cary team]. Somewhere along the M&A highway, the
work to maintain it was substituted with the work to dismantle it.
Sad to see crap emitted with 3561 in the path.
I've come to the conclusion that if someone put a nice web2.0+ interface on creating and managing these objects it would be a lot easier.
If there were a customer portal where you could visit to say "update my prefix-list/acl to include the following new prefix(es), and push the change /now/" I presume that would drive customer utilization of these services and allow people to manage things "better".
There are lots of leaks all the time, as can be evidenced by the leak detection stuff I set up here:
http://puck.nether.net/bgp/leakinfo.cgi
- Jared
Jared Mauch wrote:
I've come to the conclusion that if someone put a nice web2.0+ interface on creating and managing these objects it would be a lot easier.
I've looked into IRR several times, usually after events like PCCW. Each time the amount of work to 1) figure out how to implement IRR and 2) actually implementing it far outweighed the benefit of doing it for my network. I would love to implement it and looking towards the future I will someday have to. Until it becomes much easier to do so, I don't foresee smaller SPs like myself allocating the necessary resources to an IRR project until we're forced to because of our individual growth or an idiot PCCW-type event that generates lots of bad PR.
There are lots of leaks all the time, as can be evidenced by the leak detection stuff I set up here:
Crossing fingers hoping I'm not in that list...
Justin
Agreed, this is one of the projects I've been working on just haven't
had the time to finish it. But please allow me to put in a shameless
plug for IRR PowerTools, which many networks (including a couple tier
1s) use to do their IRR:
http://sourceforge.net/projects/irrpt/
The highlights are:
* Automated retrieval of prefixes registered behind an IRR Object.
* Automatic exclusion of bogon or other configured undesirable routes.
* Tracking and long-term recording of prefix changes over time.
* Automatic aggregation to optimize data and reduce unnecessary changes.
* E-mail updates, letting users know that their change was processed.
* E-mail alerts to the ISP, letting them know of new routing changes.
* E-mail alerts to non-IRR using networks, with plain text changes.
* Router config generation, for easy automated config deployment.
I'm also in the process of beta testing a new 2.0 version which will be
significantly rewritten for easier more scalable use, have a lot fewer
dependencies, integrate better with db backend systems to customer
prefix-list management, and fully support IPv6. Oh and there might just
be a web gui for managing and using it too, if I can find a decent web
developer who will do it for free. 
I'm hoping to have this out in the
next couple of months.
That's fine... until you learn the hard way 9 times out of 10, the person heading to such a thing is a clueless moron. As much as it is a pain in the rear, having *people* proofing and editing the BGP configuration is far less work than creating the AI needed to keep idiots from doing idiotic things.
I've never worked for any of the tier-1 beasts, but I have had to manage dozens of customer BGP sessions. Over a decade, I never dealt with a clueful customer... we cannot announce address space that doesn't belong to you; you cannot announce *our* address space to other ISPs; you have one f'ing link, why do you need BGP? (note: never actually ask that question or mute your phone immediately after asking.)
How often do your prefixes change? In my experience adding new netblocks and/or customers, taking a few weeks to get things setup wasn't a problem; it'd take that long to get their connection turned up. (and if they were talking about BGP, sales would be talking to us before the contract was signed.)
--Ricky
Richard A Steenbergen wrote:
I've come to the conclusion that if someone put a nice web2.0+ interface on creating and managing these objects it would be a lot easier.
Agreed, this is one of the projects I've been working on just haven't had the time to finish it. But please allow me to put in a shameless plug for IRR PowerTools, which many networks (including a couple tier 1s) use to do their IRR:
http://sourceforge.net/projects/irrpt/
The highlights are:
* Automated retrieval of prefixes registered behind an IRR Object.
* Automatic exclusion of bogon or other configured undesirable routes.
* Tracking and long-term recording of prefix changes over time.
* Automatic aggregation to optimize data and reduce unnecessary changes.
* E-mail updates, letting users know that their change was processed.
* E-mail alerts to the ISP, letting them know of new routing changes.
* E-mail alerts to non-IRR using networks, with plain text changes.
* Router config generation, for easy automated config deployment.I'm also in the process of beta testing a new 2.0 version which will be
significantly rewritten for easier more scalable use, have a lot fewer
dependencies, integrate better with db backend systems to customer
prefix-list management, and fully support IPv6. Oh and there might just
be a web gui for managing and using it too, if I can find a decent web
developer who will do it for free.
The longer a network develops without using or maintaining IRR data, the more difficult the transition becomes. A truly awesome capability would be to have some way to slurp in current configuration and output IRR objects that can then generate a functionally identical configuration.
Even without that, I would happily settle for any improvements to irr tools, powertools or toolsets. I am sort of disappointed that there seemed to be far less then deserved support from those with a stake in this, the registries and vendors.
Joe
"the pccw lesson, which is also the
turk-telecom lesson"
tangent here: what was the pccw and turk-telecom thing?
is the turk telco thing the Youtube fiasco?
"the pccw lesson, which is also the
turk-telecom lesson"tangent here: what was the pccw and turk-telecom thing?
is the turk telco thing the Youtube fiasco?
pccw + pktelecom == youtube incident
turk-telecom leaked covad + a bunch of other things ... 4 years back
at either the time of NANOG or a US Holiday (Christmas??)
Both incidents were: "Providers who didn't filter their customer(s)"
-chris
