spork@inch.COM (Charles Sprickman) writes:
Yes, it appears Qwest was leaking routes, but they are fixing it...
Am I just silly to assume that it shouldn't take so long for such well-funded companies to communicate with each other? AS286 is EUNet, right? This all started sometime yesterday... I still see this:
BGP routing table entry for 206.97.128.0/19, version 10233204 Paths: (1 available, best #1) 3847 1239 1800 209 286 3561 207.240.48.45 from 207.240.48.45 (207.240.48.1) Origin IGP, localpref 100, valid, external, best
Have you tried asking your upstream, Sprint (AS 1239) why they are still listening to, and re-announcing the route? Was it the old cisco bug, where routes sometimes get stuck in the route table due to dropping the withdrawl? Or some other reason? As part of the post-mortum, was everyone able to easily reach the correct people at the responsible NOC's of other providers to resolve this problem? I've been told in the past there are no communication difficulties between the billion dollar providers, and bi-lateral processes work well. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
On Oct 27, 10:46, Sean Donelan <SEAN@SDG.DRA.COM> wrote:
still listening to, and re-announcing the route? Was it the old cisco bug, where routes sometimes get stuck in the route table due to dropping the withdrawl?
Yes. The leak (through 1800) was fixed rather quickly, but the routes stuck. The fact that many (most?) of them were more specific routes made the whole thing as "eventful" as it was; normally, selection by path length means that leaks like that don't have any particular effect. Hence, you actually had three things go wrong at the same time: 1) Wrong filtering. 2) More specific routes. 3) The routes stuck after withdrawal. -- ------ ___ --- Per G. Bilse, Director Network Eng & Ops ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at domain
On Tue, 27 Oct 1998, Sean Donelan wrote:
Have you tried asking your upstream, Sprint (AS 1239) why they are still listening to, and re-announcing the route? Was it the old cisco bug, where routes sometimes get stuck in the route table due to dropping the withdrawl? Or some other reason?
My upstream is actually Genuity/GTEI (AS 3847). I've opened a ticket with them, but it seems that the old Genuity parts of the network are suffering from a certain amount of neglect. I used to have some direct contact with the folks left at Genuity, but now my only route to support/help is GTE/BBN's noc. The last response from them amounted to asking questions about connectivity, what IP was I coming from and going to, etc. They apparently ignored the little 'sh ip bgp' snippet I sent. They said it was normal to transit sprint to get to mci/cw. I wouldn't think so, as they have peering with mci/cw, but who knows. FWIW, I still see this today, and I'm guessing this is the IOS bug you are speaking of, either upstream or at my router... Time to poke around the bug database... Thanks, Charles
As part of the post-mortum, was everyone able to easily reach the correct people at the responsible NOC's of other providers to resolve this problem? I've been told in the past there are no communication difficulties between the billion dollar providers, and bi-lateral processes work well. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
=-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=
participants (3)
-
Charles Sprickman -
Per Gregers Bilse -
Sean Donelan