Re: cisco.com
On Tue Aug 04, 2009, Steve Rossen wrote: Route is back 08/04 13:55:57 Withdraw 198.133.219.0/24 08/04 16:04:53 Update 198.133.219.0/24 Times are CET. German > Missing route on Internap also. > > Netraft shows cisco.com went down right at 12:00GMT. > > http://uptime.netcraft.com/perf/graph?site=www.cisco.com > > On Tue, Aug 4, 2009 at 8:48 AM, sjk wrote: > > We have seen the route for cisco withdrawn from 208 and 2828. Facebook > > seems fine > > > > Dominic J. Eidson wrote: > >> > >> Both work from Austin, TX. > >> > >> > >> > >> - d. > >> > >> On Tue, 4 Aug 2009, Alex Nderitu wrote: > >> > >>> Facebook seems to also be affected. > >>> > >>> > >>> -Original Message- > >>> From: R. Benjamin Kessler > >>> To: nanog@nanog.org > >>> Subject: cisco.com > >>> Date: Tue, 4 Aug 2009 09:34:46 -0400 > >>> > >>> > >>> Hey Gang - > >>> > >>> I'm unable to get to cisco.com from multiple places on the 'net > >>> (including downforeveryoneorjustme.com); any ideas on the cause and ETR? > >>> > >>> Thanks, > >>> > >>> Ben > >>> > >>> > >>> > >>> > >> > > > > pgp3wU4dKkoJO.pgp Description: PGP signature
Re: cisco.com
On Tue Aug 04, 2009, Jon Auer wrote: > See: https://puck.nether.net/pipermail/outages/2009-August/001386.html > I do not have a route to that IP (198.133.219.25) in BGP either.. Route is not longer in the routing table since (CET) 08/04 13:55:57 Withdraw 198.133.219.0/24> German pgpMuXvcWuWcP.pgp Description: PGP signature
Re: Cogent input
On Thu Jun 11, 2009, Alex Rubenstein wrote: > > I'm aware of some (regular?) depeering issues. The NANOG archives have > > AFAIR, there has never been a black-holing, just disappearance of routes. If > you are properly multihomed, this is irrelevant and you continue to eat your > ice cream and chuckle while they fight it out. It's amusing, really. > > I guess the blackholing could come from Cogent having a route to you but *YOU* not having a route back to Cogent as a consequence of the depeering. German > pgp7jm13rFmrc.pgp Description: PGP signature
Re: Cogent input
On Thu Jun 11, 2009, John van Oppen wrote: > NTT (2914) and GBLX (3549) both do native v6... most everyone else on > the tier1 list does tunnels. :( AS5511 runs a double stack network for at least 7 years. > > There are some nice tier2 networks who do native v6, tiscali and he.net > come to mind. > > > -John > > -Original Message- > From: Paul Timmins [mailto:p...@telcodata.us] > Sent: Thursday, June 11, 2009 4:00 PM > To: Justin Shore > Cc: NANOG > Subject: Re: Cogent input > > > > > > I hope at least some SPs make this commitment back in the states. I > > can't find any tier-1s that can provide us with native v6. Our tier-1 > > > upstream has a best effort test program in place that uses ipv6ip > > tunnels. The other upstream says that they aren't making any public > > IPv6 plans yet. It's hard to push the migration to v6 along when > > native v6 providers aren't readily available. > > GlobalCrossing told me today I can order native IPv6 anywhere on their > network. Don't know if they count as Tier 1 on your list, though. VZB > has given me tunnels for a while, hopefully they'll get their pMTU issue > > fixed so we can do more interesting things with it. > > -Paul > pgpO6W4MmO72b.pgp Description: PGP signature
Re: anyone else seeing very long AS paths?
On Tue Feb 17, 2009, Rodney Dunn wrote: Hello Rodney, It will be great if you can share with us your findings. It seems like we are hitting different bugs in different platforms. Thanks German > Ivan, > > It is confusing but from what I have tested you have it correct. > > The confusing part comes from multiple issues. > > a) The documentation about the default maxas limit being 75 appears to be >incorrect. I'll get that fixed. > > b) Prior to CSCee30718 there was a hard limit of 255. After that fix >AS sets of more than 255 should work. > > c) CSCeh13489 implemented the maxas command to mark it as invalid and >not send. > > > There does appear to be an issue when you cross the 255 boundary > and the next hop router sends a notification back. > > I've got it recreated in the lab and we are working to clearly understand > why that is. I'll post an update once we have more. > > The way to prevent it is the upstream device that crosses the 255 boundary > on sending needs to use the maxas limit command to keep it less than 255. > > It doesn't work on the device that receives the update with the AS path > larger than 255. > > Rodney > > On Tue, Feb 17, 2009 at 08:58:48PM +0100, Ivan Pepelnjak wrote: > > > We were dropping ALL prefixes and the eBGP session was still > > > resetting. > > > > Upstream or downstream? > > > > > 1) "bgp maxas-limit 75" had no effect mitigating this problem > > > on the IOS we were using. That is: it was previously verified > > > to be working just fine to drop paths longer than 75, but > > > once we started receiving paths > > > > 255 then BGP started resetting. > > > > I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The > > paths were generated by Quagga BGP daemon. > > > > 12.2SRC causes the downstream session to break when the installed AS-path > > length is close to 255 and you use downstream AS-path prepending. > > > > In your case, I'm assuming you were hit with an older bug (probably at the > > 128 AS-path length boundary). It would be very hard to generate just the > > right AS-path length to unintentionally break your upstream EBGP session (as > > I said before, it's a nice targeted attack if you know your downstream > > topology). > > > > If your IOS is vulnerable to the older bugs that break inbound processing of > > AS paths longer than 128, there's nothing you can do on your end. The > > internal BGP checks reject the inbound update before the inbound filters (or > > bgp maxas-limit) can touch it and reset the upstream BGP session. > > > > Hope this helps > > Ivan > > > > Disclaimer: as I don't have internal access to Cisco, all of the above is a > > result of lab tests. > > pgpKi14UX012c.pgp Description: PGP signature
Re: anyone else seeing very long AS paths?
On Tue Feb 17, 2009, Ivan Pepelnjak wrote: > According to publicly available bug toolkit, CSCee30718 did not touch the > maxas limit. I will double check this with Cisco pgpeuQs06hcKd.pgp Description: PGP signature
Re: anyone else seeing very long AS paths?
On Tue Feb 17, 2009, Mike Lewinski wrote: > bgp max-as will NOT protect you from this exploit (but if you are not > vulnerable it should prevent you from propogating it). Are you trying to say that the receiving bgp speaker will drop the session no matter what but it won't forward the update? Here is what I have found on Cisco's website bgp maxas-limit To configure Border Gateway Protocol (BGP) to discard routes that have a number of as-path segments that exceed the specified value, use the bgp maxas-limit command in router configuration mode. To return the router to default operation, use the no form of this command. Usage Guidelines The bgp maxas-limit command is used to limit the number of as-path segments that are permitted in inbound routes. If a route is received with an as-path segment that exceeds the configured limit, the BGP routing process will discard the route. I heard about people running this command that were not impacted > > As far as I can tell the ONLY defense for a vulnerable IOS is to not run > BGP. Dropping every received route with a filter on 0/0 does not mitigate > the attack - as soon as that bogus as-path is received the BGP session > resets, even if the route is never actually installed (and as far as I can > tell the only real effect of the "bgp maxas-limit 75" is to cause all paths > with more than 75 ASN to not be installed in the routing table). > pgphPXgUDIi6Q.pgp Description: PGP signature
Re: anyone else seeing very long AS paths?
On Tue Feb 17, 2009, Michael Ulitskiy wrote: Hello, CSCee30718 – it removes the default value of bgp max-as from the router. The solution is introduced in CSCeh13489 BGP shouldn't propogate an update w excessive AS Path > 255 Symptoms: A router may reset its Border Gateway Protocol (BGP) session. Conditions: This symptom is observed when a Cisco router that peers with other routers receives an Autonomous System (AS) path with a length that is equal to or greater than 255. Workaround: Configure the bgp maxas limit command in such as way that the maximum length of the AS path is a value below 255. When the router receives an update with an excessive AS path value, the prefix is rejected and recorded the event in the log. This workaround has been suggested previously by Hank. Anyone knows about any possible CPU impacts in case that you implement bgp maxas? Thanks German > My bgp speaking devices are a couple of 7200s running 12.2(40). > Not the newest IOS out there, but it's been doing the job just fine up until > yesterday. > Yesterday, when that malformed announcement hit my routers they didn't crash, > but they did reset bgp sessions (even though I didn't accept the route) and > they kept doing so > until I got my upstream to filter it out. > According to cisco bug toolkit CSCdr54230 should be fixed in 12.2, so > obviously it's not enough. > Does anybody know what IOS version has fix this problem, 'cause I couldn't > find this info at CCO? > Thanks, > > Michael > > On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > > Jared Mauch wrote: > > > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > > > >>"They" will keep trying and until a vast majority of ISPs implement > > >>maxas, this will keep happening. > > > > > Or until people who are still running multi-year old cisco code > > > actually upgrade? This seems to primarily impact: > > > > > > 1) Old cisco code > > > 2) PC based bgp daemons > > > > > Both of which likely just need to be upgraded. I actually suspect > > > that a lot of people who dropped their bgp sessions did not notice > > > something happened, and still will not upgrade their codeI > > > suspect these people don't even know they have a bgp speaking device > > > anymore. > > > > On the other hand, the fact that various entities have gone out of their > > way to advertise that they're running old hardware/out-of-date software > > has been noted elsewhere. I'd strongly suggest, if you're reading NANOG, > > that you update, before someone less pleasant and friendly than myself > > finds you. Please. > > > > pgptsqV6JzgBN.pgp Description: PGP signature
TeliaSonera AS1299
Hello, If anyone from TeliaSonera is around please contact me off-list Thanks German pgptdISWjhXk2.pgp Description: PGP signature
