RE: Plethora of UUnet outages and instabilities
I am just a multihomed customer with Two T1s running BGP4. I had no trouble with my Ts from Sprint and MCI until about two months ago. I am running a 7206 with 64meg of RAM on 11.1(12). Our customer support started getting complaints about customers not being able to reach us(AS7201) from MSN dialup in Houston. The network 153.36.0.0/14 was in my BGP tables but not my IP route table. I called Cisco and after a little work they concluded that the reason the routes were being removed was more specific routes 153.36.50.0 & 153.36.51.0 inside the CIDR were removing the 153.36.0.0/14. I didn't understand the logic but a simple distribute list ignoring announcements for the two class Cs seemed to solve the problem. Later I sent a note to Sprint, MCI, MSN, & UUNET. Spint and MCI responded quickly stating that Cisco was mistaken. Cisco wants to look into it further. I have herd nothing from MSN or UUNET. I have to update the software on the router for other reasons. I thought I would wait to see if the problem is still present after my upgrade. I have no route Damping setup and can think of no other explanation for this bizarre behavior. My point is that maybe there are other reasons that so many ASs are having problems with UUNET routes. Peter Cole of Telescan, Inc. (281)588-9155 Better computing through lack of sleep.
---------- From: Josh Beck[SMTP:jbeck@connectnet.com] Sent: Monday, June 30, 1997 4:12 PM To: nanog@merit.edu Subject: Plethora of UUnet outages and instabilities
Has everyone else been seeing the almost daily UUnet outages recently, does anyone know what the true causes of these have been?
Josh Beck jbeck@connectnet.com ---------------------------------------------------------------------- -- CONNECTNet INS, Inc. Phone: (619)450-0254 Fax: (619)450-3216 6370 Lusk Blvd., Suite F-208 San Diego, CA 92121 ---------------------------------------------------------------------- --
From: Peter Cole <Peter.Cole@telescan.com> To: nanog@merit.edu, Josh Beck <jbeck@connectnet.com> Subject: RE: Plethora of UUnet outages and instabilities Date: Tue, 1 Jul 1997 11:34:42 -0500 ... Our customer support started getting complaints about customers not being able to reach us(AS7201) from MSN dialup in Houston. The network 153.36.0.0/14 was in my BGP tables but not my IP route table. I called Cisco and after a little work they concluded that the reason the routes were being removed was more specific routes 153.36.50.0 & 153.36.51.0 inside the CIDR were removing the 153.36.0.0/14. I didn't understand the logic but a simple distribute list ignoring announcements for the two class Cs seemed to solve the problem. Later I sent a note to Sprint, MCI, MSN, & UUNET. Spint and MCI responded quickly stating that Cisco was mistaken. Cisco wants to look into it further. I have herd nothing from MSN or UUNET. I have to update the software on the router for other reasons. I thought I would wait to see if the problem is still present after my upgrade. I have no route Damping setup and can think of no other explanation for this bizarre behavior.
My point is that maybe there are other reasons that so many ASs are having problems with UUNET routes.
You can only blame UUNET for announcing 2 subnets of their Class B via BGP, especially when there is no valid reason for them to be doing so... It will not be long before most ISPs will be installing filters to deny subnets of Class B address space (nothing less than /16). You probably need "ip classless" command implemented on your Cisco 7206. The Cisco "show ip route x.x.x.x" probably assumes classfull routing, and there are bugs in it: router> sh ip route 153.36.0.0 Routing entry for 153.36.0.0/24, 2 known subnets B 153.36.51.0 [210/1] via 204.70.186.5, 13:51:42 B 153.36.50.0 [210/1] via 204.70.186.5, 13:51:42 Note that 153.36.0.0 is not a /24 (Cisco bug). If you dump the full routing table via "sh ip route" you should also find the aggregate classless route: B 153.36.0.0/14 [210/1] via 144.228.157.41, 06:02:56 This should be used if you have installed "ip classless" on your router. -- Paul Fakler.
participants (2)
-
Paul Fakler -
Peter Cole