Re: sort by agony
On Thu, 2010-08-26 at 22:46 -0700, JC Dill wrote: > William Herrin wrote: > > On Thu, Aug 26, 2010 at 6:36 PM, wrote: > > > >> sorry for the off topic post - but since a few of us travel about some... > >> http://www.hipmunk.com/ > >> > > Cool link! I'm actually shopping for a flight tonight, this has already > come in quite handy. > > > > > How do they quantify agony? Also it's not clear if the sort is > > ascending or descending... > > http://www.hipmunk.com/faq > > What is Agony, and why would I want to sort by it? > Agony is our way of sorting flights to take into account price, > duration, and number of stops. There's more to a flight than its price, > so we provide this sort to give you better all-around results. > Very cool indeed. I'd think that to some the travel time would be weighed much more heavily than the price of the ticket. I hate to fly for work (having been injured in a plane crash) and a bit nervous anyway, but if I am flying for work then then a few hundred bucks is trivial compared to what is riding on the deal. It might be neat of you could adjust the weight of the components of "agony". For kicks, I looked at the most agonizing trip options... I chose a trip from San Diego to New York City... the worst were: 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost over $1k. 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a 1.5hr layover to New York LGA. Holy crappy flights Batman! -- Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more
Re: sort by agony
On Fri, Aug 27, 2010 at 8:25 AM, Michael J McCafferty wrote: > For kicks, I looked at the most agonizing trip options... I chose a trip > from San Diego to New York City... the worst were: > > 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost > over $1k. > > 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a > 1.5hr layover to New York LGA. Made all the more agonizing when you arrive in NY and customs express interest in your decission to stop over south of the border for a couple of hours. As others have said -- agony's a nice idea, but the real value gets added when you can weight the elements according to your personal preferences (and the site can then capture how people choose to weight various inconveniences in order to (i) improve their own algorithms, and (ii) sell on to other interested parties). C
Re: Idea's for donating/recycling server hardware [Off-Topic]
On Thu, Aug 26, 2010 at 04:05:33PM -0700, Wil Schultz wrote: > I apologize for being somewhat off topic... > > I've got a fair amount of SPARC hardware (v210 through v490) and 32bit HP > DL360-380 hardware that I'm looking for creative ways to dispose of or to > donate. > > It seems like a waste to send it to metal scrap, if anyone has a more > creative way of disposal please contact me off list. Local to San Francisco. > > *disclaimer, contributions cannot go to religious or political organizations > per corp policy* > > Thanks! > It may not be as widespread in the US, but certainly over here, the average university will have some kind of (computer|networking) society who'd generally bite your arm off for old gear. > -wil >
Fwd: Re: [oss-security] CVE Request -- Quagga (bgpd) [two ids] -- 1, Stack buffer overflow by processing crafted Refresh-Route msgs 2, NULL ptr deref by parsing certain AS paths by BGP update request
for those who missed it... kind regards, niko Original Message Subject: Re: [oss-security] CVE Request -- Quagga (bgpd) [two ids] -- 1, Stack buffer overflow by processing crafted Refresh-Route msgs 2, NULL ptr deref by parsing certain AS paths by BGP update request Date: Wed, 25 Aug 2010 10:21:59 -0400 From: Josh Bressers Reply-To: oss-secur...@lists.openwall.com To: oss-secur...@lists.openwall.com CC: CERT-FI Vulnerability Co-ordination ,Chris Hall ,Denis Ovsienko ,"Steven M. Christey" - "Jan Lieskovsky" wrote: > Hi Steve, vendors, > >Quagga upstream has released latest vQuagga 0.99.17 version, >addressing two security flaws: > > A, Stack buffer overflow by processing certain Route-Refresh messages > >A stack buffer overflow flaw was found in the way Quagga's bgpd daemon >processed Route-Refresh messages. A configured Border Gateway Protocol >(BGP) peer could send a Route-Refresh message with specially-crafted >Outbound Route Filtering (ORF) record, which would cause the master >BGP daemon (bgpd) to crash or, possibly, execute arbitrary code with >the privileges of the user running bgpd. > >Upstream changeset: >[1] > http://code.quagga.net/?p=quagga.git;a=commit;h=d64379e8f3c0636df53ed08d5b2f1946cfedd0e3 > >References: >[2] https://bugzilla.redhat.com/show_bug.cgi?id=626783 >[3] http://www.quagga.net/news2.php?y=2010&m=8&d=19#id1282241100 Use CVE-2010-2948 for this one. > > B, DoS (crash) while processing certain BGP update AS path messages > >A NULL pointer dereference flaw was found in the way Quagga's bgpd >daemon parsed paths of autonomous systems (AS). A configured BGP peer >could send a BGP update AS path request with unknown AS type, which >could lead to denial of service (bgpd daemon crash). > >Upstream changeset: >[4] > http://code.quagga.net/?p=quagga.git;a=commit;h=cddb8112b80fa9867156c637d63e6e79eeac67bb > >References: >[5] https://bugzilla.redhat.com/show_bug.cgi?id=626795 >[6] http://www.quagga.net/news2.php?y=2010&m=8&d=19#id1282241100 > Use CVE-2010-2949 for this one. Thanks. -- JB
Re: Idea's for donating/recycling server hardware [Off-Topic]
Hi > It seems like a waste to send it to metal scrap, if anyone has a more > creative way of disposal please contact me off list. Local to San Francisco. What about http://www.freecycle.org/ ?
Re: sort by agony
On 8/27/2010 4:33 AM, Callum Finlayson wrote: On Fri, Aug 27, 2010 at 8:25 AM, Michael J McCafferty wrote: For kicks, I looked at the most agonizing trip options... I chose a trip from San Diego to New York City... the worst were: 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost over $1k. 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a 1.5hr layover to New York LGA. Made all the more agonizing when you arrive in NY and customs express interest in your decission to stop over south of the border for a couple of hours. As others have said -- agony's a nice idea, but the real value gets added when you can weight the elements according to your personal preferences (and the site can then capture how people choose to weight various inconveniences in order to (i) improve their own algorithms, and (ii) sell on to other interested parties). C right and be able to crank the agony up based on a given airport (ATL... I am looking at you here) Andrew
Re: sort by agony
On Aug 27, 2010, at 1:33 AM, Callum Finlayson wrote: > On Fri, Aug 27, 2010 at 8:25 AM, Michael J McCafferty > wrote: >> For kicks, I looked at the most agonizing trip options... I chose a trip >> from San Diego to New York City... the worst were: >> >> 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost >> over $1k. >> >> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >> 1.5hr layover to New York LGA. > > Made all the more agonizing when you arrive in NY and customs express > interest in your decission to stop over south of the border for a > couple of hours. > Except neither flight would involve customs in NY. In the first case, you would clear customs in Newark. In the second, you would clear customs in Atlanta. > As others have said -- agony's a nice idea, but the real value gets > added when you can weight the elements according to your personal > preferences (and the site can then capture how people choose to weight > various inconveniences in order to (i) improve their own algorithms, > and (ii) sell on to other interested parties). > I suspect it might not be that hard for them to add and would be worthy of requesting as a feature. Owen > > C
Re: sort by agony
On 08/27/2010 01:46 EDT, JC Dill wrote: > What is Agony, and why would I want to sort by it? > Agony is our way of sorting flights to take into account price, > duration, and number of stops. There's more to a flight than its price, > so we provide this sort to give you better all-around results. I wonder if I could persuade it to take round trip agony into account. For example on CO I can get from here to PEK easily, but on the way back I would have to spend the night in Newark.
Re: sort by agony
On Aug 27, 2010, at 6:30 AM, Andrew Kirch wrote: > On 8/27/2010 4:33 AM, Callum Finlayson wrote: >> On Fri, Aug 27, 2010 at 8:25 AM, Michael J McCafferty >> wrote: >>> For kicks, I looked at the most agonizing trip options... I chose a trip >>> from San Diego to New York City... the worst were: >>> >>> 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost >>> over $1k. >>> >>> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >>> 1.5hr layover to New York LGA. >> Made all the more agonizing when you arrive in NY and customs express >> interest in your decission to stop over south of the border for a >> couple of hours. >> >> As others have said -- agony's a nice idea, but the real value gets >> added when you can weight the elements according to your personal >> preferences (and the site can then capture how people choose to weight >> various inconveniences in order to (i) improve their own algorithms, >> and (ii) sell on to other interested parties). >> >> >> C >> > right and be able to crank the agony up based on a given airport (ATL... I am > looking at you here) Agony can frequently be made more specific. For example, one big problem in ATL at this time of year is thunderstorms, and these are likely to happen in the afternoon. (A late summer afternoon in North Georgia is almost certain to have some thunderstorms moving through.) So, a flight in August with a 10:00 AM change in ATL, I don't worry about. A flight with a 4:00 PM change, I assume I am likely to be late if not bumped to the next day. There are many airports with similar time variability (LHR at 9:00 AM!), and all of this data is out there. It would be a powerful selling point if the agony index included such granularity. Regards Marshall > > Andrew > >
Re: sort by agony
On Fri, 27 Aug 2010 00:25:43 PDT, Michael J McCafferty said: > 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a > 1.5hr layover to New York LGA. I once got booked Roanoke-Pittsburgh-Chicago-St Louis-Columbia MO. All layovers *short* enough to induce "run through the airport" panic behavior (and stopping for food was out of the question). Oh, and I *hate* takeoffs and landings. pgpoMyqzYhRKu.pgp Description: PGP signature
Re: sort by agony
On Aug 27, 2010, at 10:08 AM, valdis.kletni...@vt.edu wrote: > On Fri, 27 Aug 2010 00:25:43 PDT, Michael J McCafferty said: > >> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >> 1.5hr layover to New York LGA. > > I once got booked Roanoke-Pittsburgh-Chicago-St Louis-Columbia MO. All > layovers > *short* enough to induce "run through the airport" panic behavior (and > stopping for > food was out of the question). > A _really_ intelligent airline scheduling system would (IMHO) be able to offer you options like "there is a direct flight Pittsburgh -> Kansas City, and from there it is a 2 hour drive to Columbia, so that will save you 5 hours travel time" Regards Marshall > Oh, and I *hate* takeoffs and landings.
RE: sort by agony
My favorite is Detroit to Chicago, via ATL! -Original Message- From: Marshall Eubanks [mailto:t...@americafree.tv] Sent: Friday, August 27, 2010 10:32 AM To: valdis.kletni...@vt.edu Cc: NANOG list Subject: Re: sort by agony On Aug 27, 2010, at 10:08 AM, valdis.kletni...@vt.edu wrote: > On Fri, 27 Aug 2010 00:25:43 PDT, Michael J McCafferty said: > >> 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a >> 1.5hr layover to New York LGA. > > I once got booked Roanoke-Pittsburgh-Chicago-St Louis-Columbia MO. All layovers > *short* enough to induce "run through the airport" panic behavior (and stopping for > food was out of the question). > A _really_ intelligent airline scheduling system would (IMHO) be able to offer you options like "there is a direct flight Pittsburgh -> Kansas City, and from there it is a 2 hour drive to Columbia, so that will save you 5 hours travel time" Regards Marshall > Oh, and I *hate* takeoffs and landings.
Re: sort by agony
On Fri, 27 Aug 2010 10:32:17 EDT, Marshall Eubanks said: > A _really_ intelligent airline scheduling system would (IMHO) be able to > offer you options like > > "there is a direct flight Pittsburgh -> Kansas City, and from there it > is a 2 hour drive to Columbia, so that will save you 5 hours travel > time" Yeah, would have been nice, except the policy says "travel at minimum total cost". The paperwork involved for a rental car was even scarier than a DCA takeoff/landing. ;) pgpzLFcmMYv6q.pgp Description: PGP signature
Looking for Fiber Plant Management software
Good morning, NANOGers. My colleague at work wonders if anyone has suggestions for software to database all our fiber plant that we're constructing. We started out with paper, then Excel spreadsheets in a folder and on paper in a book, but clearly as our plant grows and we do more splicing this is not going to scale. We have started a MySQL database with a few tables, but wonder if someone has already invented this wheel. What do the "big boys" use? Homegrown solutions developed in-house and jealously guarded? Something standard? Expensive or cheap? Free open- source? He'd like to see... outside plan facilities: cables, fibers, splice points, poles; copper and fiber, preferably, but fiber is more important "circuit" or "DLR" that knows what elements are involved in a circuit GIS integration so that cables can be drawn on a map automagically low cost, of course Thanks in advance, everyone. -- Jeff Saxe, Network Engineer Blue Ridge InternetWorks, Charlottesville, VA 434-817-0707 ext. 2024 / js...@briworks.com
Re: Looking for Fiber Plant Management software
I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > Good morning, NANOGers. My colleague at work wonders if anyone has > suggestions for software to database all our fiber plant that we're > constructing. We started out with paper, then Excel spreadsheets in a folder > and on paper in a book, but clearly as our plant grows and we do more > splicing this is not going to scale. We have started a MySQL database with a > few tables, but wonder if someone has already invented this wheel. > > What do the "big boys" use? Homegrown solutions developed in-house and > jealously guarded? Something standard? Expensive or cheap? Free open-source? > He'd like to see... > > outside plan facilities: cables, fibers, splice points, poles; copper and > fiber, preferably, but fiber is more important > "circuit" or "DLR" that knows what elements are involved in a circuit > GIS integration so that cables can be drawn on a map automagically > low cost, of course > > Thanks in advance, everyone. > > -- Jeff Saxe, Network Engineer > Blue Ridge InternetWorks, Charlottesville, VA > 434-817-0707 ext. 2024 / js...@briworks.com > > > >
Did your BGP crash today?
Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? Kim
Re: Did your BGP crash today?
I did see some attribute 99 stuff go around earlier today and have not yet researched it. Unknown BGP attribute 99 (flags: 240) Unknown BGP attribute 99 (flags: 240) Unknown BGP attribute 99 (flags: 240) Unknown BGP attribute 99 (flags: 240) Unknown BGP attribute 99 (flags: 240) - Jared On Aug 27, 2010, at 1:27 PM, Kasper Adel wrote: > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? > > > Kim
Re: Did your BGP crash today?
On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? If it in fact "crashed the internet", as opposed to "gave a few buggy routers here and there indigestion", you wouldn't be posting to NANOG looking for confirmation. :) pgpDM0tt5WPYV.pgp Description: PGP signature
re: Did your BGP crash today?
No down time here, Would have been all over the news and everything if it really do "crash" the internet. Nick Olsen Network Operations (321) 205-1100 x106 From: "Kasper Adel" Sent: Friday, August 27, 2010 1:27 PM To: "NANOG list" Subject: Did your BGP crash today? Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? Kim
Re: Did your BGP crash today?
Well played, Sir. Nick Olsen Network Operations (321) 205-1100 x106 From: valdis.kletni...@vt.edu Sent: Friday, August 27, 2010 1:32 PM To: "Kasper Adel" Subject: Re: Did your BGP crash today? On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? If it in fact "crashed the internet", as opposed to "gave a few buggy routers here and there indigestion", you wouldn't be posting to NANOG looking for confirmation. :)
Re: Did your BGP crash today?
Looking at the graph of at least one of the european exchange where RIS connect, it had an impact. Now saying it was nothing is like saying that the YouTube incident was nothing as you were not affected as you do not use YouTube. Some people did feel the pain - lucky it was not you :) Thomas --- from my iPhone On 27 Aug 2010, at 19:31, "Nick Olsen" wrote: > No down time here, Would have been all over the news and everything if it > really do "crash" the internet. > > Nick Olsen > Network Operations > (321) 205-1100 x106 > > > > From: "Kasper Adel" > Sent: Friday, August 27, 2010 1:27 PM > To: "NANOG list" > Subject: Did your BGP crash today? > > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? > > Kim >
RE: Did your BGP crash today?
Ignoring the fact that the original poster has a thing for the dramatic, of those who did feel minor pain from this what hardware platforms were affected and what software versions just for curiosity sake. -Original Message- From: Thomas Mangin [mailto:thomas.man...@exa-networks.co.uk] Sent: Friday, August 27, 2010 11:44 AM To: n...@brevardwireless.com Cc: Subject: Re: Did your BGP crash today? Looking at the graph of at least one of the european exchange where RIS connect, it had an impact. Now saying it was nothing is like saying that the YouTube incident was nothing as you were not affected as you do not use YouTube. Some people did feel the pain - lucky it was not you :) Thomas --- from my iPhone On 27 Aug 2010, at 19:31, "Nick Olsen" wrote: > No down time here, Would have been all over the news and everything if > it really do "crash" the internet. > > Nick Olsen > Network Operations > (321) 205-1100 x106 > > > > From: "Kasper Adel" > Sent: Friday, August 27, 2010 1:27 PM > To: "NANOG list" > Subject: Did your BGP crash today? > > Havent seen a thread on this one so thought i'd start one. > > Ripe tested a new attribute that crashed the internet, is that true? > > Kim >
Re: Did your BGP crash today?
On 27-08-10 19:31, valdis.kletni...@vt.edu wrote: On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? If it in fact "crashed the internet", as opposed to "gave a few buggy routers here and there indigestion", you wouldn't be posting to NANOG looking for confirmation. :) https://www.ams-ix.net/statistics/ Not whole internet, but a part. And the "few buggy routers here and there" were mostly Cisco CRS-1's which didn't understand the new attribute and sent a malformed message to all peers, causing them to close the BGP session. I think most of the impact was limited to Europe, especially Amsterdam area. -- Grzegorz Janoszka
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Aug, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 329510 Prefixes after maximum aggregation: 151625 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 161906 Total ASes present in the Internet Routing Table: 34686 Prefixes per ASN: 9.50 Origin-only ASes present in the Internet Routing Table: 30086 Origin ASes announcing only one prefix: 14608 Transit ASes present in the Internet Routing Table:4600 Transit-only ASes present in the Internet Routing Table:106 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 1590 Unregistered ASNs in the Routing Table: 797 Number of 32-bit ASNs allocated by the RIRs:748 Prefixes from 32-bit ASNs in the Routing Table: 962 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:170 Number of addresses announced to Internet: 2293803456 Equivalent to 136 /8s, 184 /16s and 169 /24s Percentage of available address space announced: 61.9 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 84.5 Total number of prefixes smaller than registry allocations: 156020 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:80080 Total APNIC prefixes after maximum aggregation: 27494 APNIC Deaggregation factor:2.91 Prefixes being announced from the APNIC address blocks: 77020 Unique aggregates announced from the APNIC address blocks:33981 APNIC Region origin ASes present in the Internet Routing Table:4178 APNIC Prefixes per ASN: 18.43 APNIC Region origin ASes announcing only one prefix: 1167 APNIC Region transit ASes present in the Internet Routing Table:640 Average APNIC Region AS path length visible:3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 541736480 Equivalent to 32 /8s, 74 /16s and 62 /24s Percentage of available APNIC address space announced: 76.9 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:135692 Total ARIN prefixes after maximum aggregation:69900 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108438 Unique aggregates announced from the ARIN address blocks: 42670 ARIN Region origin ASes present in the Internet Routing Table:13878 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix:5319 ARIN Region transit ASes present in the Internet Routing Table:1380 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addr
Re: Did your BGP crash today?
On 27 Aug 2010, at 19:27, Grzegorz Janoszka wrote: > On 27-08-10 19:31, valdis.kletni...@vt.edu wrote: >> On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: >>> Havent seen a thread on this one so thought i'd start one. >>> >>> Ripe tested a new attribute that crashed the internet, is that true? >> >> If it in fact "crashed the internet", as opposed to "gave a few buggy routers >> here and there indigestion", you wouldn't be posting to NANOG looking for >> confirmation. :) > > https://www.ams-ix.net/statistics/ > > Not whole internet, but a part. And the "few buggy routers here and there" > were mostly Cisco CRS-1's which didn't understand the new attribute and sent > a malformed message to all peers, causing them to close the BGP session. In a way it remind me of the ASN4 bug .. Until a vendor fix is available I guess that the details are better left off public mailing lists. http://www.uknof.org.uk/uknof12/Davidson-4_byte_asn.pdf > I think most of the impact was limited to Europe, especially Amsterdam area. Yes, It had an effect on ISPs which are connected to RIS. http://www.ripe.net/ris/ AFAIK this mean ASes at LINX and AMS-IX . The LINX graph shows a similar (but smaller) dip of 50-60 GB. Thomas
Re: Did your BGP crash today?
FYI: -- Dear Colleagues, On Friday 27 August, from 08:41 to 09:08 UTC, the RIPE NCC Routing Information Service (RIS) announced a route with an experimental BGP attribute. During this announcement, some Internet Service Providers reported problems with their networking infrastructure. Investigation -- Immediately after discovering this, we stopped the announcement and started investigating the problem. Our investigation has shown that the problem was likely to have been caused by certain router types incorrectly modifying the experimental attribute and then further announcing the malformed route to their peers. The announcements sent out by the RIS were correct and complied to all standards. The experimental attribute was part of an experiment conducted in collaboration with a group from Duke University. This involved announcing a large (3000 bytes) optional transitive attribute, using a modified version of Quagga. The attribute used type code 99. The data consisted of zeros. We used the prefix 93.175.144.0/24 for this and announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers. Reports from affected ISPs showed that the length of the attribute in the attribute header, as seen by their routers, was not correct. The header stated 233 bytes and the actual data in their samples was 237 bytes. This caused some routers to drop the session with the peer that announced the route. We have built a test set-up which is running identical software and configurations to the live set-up. From this set-up, and the BGP packet dumps as made by the RIS, we have determined that the length of the data in the attribute as sent out by the RIS was indeed 3000 bytes and that all lengths recorded in the headers of the BGP updates were correct. Beyond the RIS systems, we can only do limited diagnosis. One possible explanation is that the affected routers did not correctly use the extended length flag on the attribute. This flag is set when the length of the attribute exceeds 255 bytes i.e. when two octets are needed to store the length. It may be that the routers may not add the higher octet of the length to the total length, which would lead, in our test set-up, to a total packet length of 236 bytes. If, in addition, the routers also incorrectly trim the attribute length, the problem could occur as observed. It is worth noting that the difference between the reported 233 and 237 bytes is the size of the flags, type code and length in the attribute. We will be further investigating this problem and will report any findings. We regret any inconvenience caused. Kind regards, Erik Romijn Information Services RIPE NCC ___ tech-l mailing list tec...@ams-ix.net http://melix.ams-ix.net/mailman/listinfo/tech-l - Lucy On Fri, 27 Aug 2010, Grzegorz Janoszka wrote: On 27-08-10 19:31, valdis.kletni...@vt.edu wrote: On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? If it in fact "crashed the internet", as opposed to "gave a few buggy routers here and there indigestion", you wouldn't be posting to NANOG looking for confirmation. :) https://www.ams-ix.net/statistics/ Not whole internet, but a part. And the "few buggy routers here and there" were mostly Cisco CRS-1's which didn't understand the new attribute and sent a malformed message to all peers, causing them to close the BGP session. I think most of the impact was limited to Europe, especially Amsterdam area.
Re: sort by agony
On Fri, 27 Aug 2010, Callum Finlayson wrote: 1) Tijuana to Mexico City, 16hr hour layover, then to Newark NJ and cost over $1k. 2) Tijuana to Guadalajara for an 8hr layover, then to Atlanta for a 1.5hr layover to New York LGA. Made all the more agonizing when you arrive in NY and customs express interest in your decission to stop over south of the border for a couple of hours. You be cool for twenty hours And I'll pay you twenty grand. That song just pop into anyone else's head? -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Did your BGP crash today?
So much for "better left off public mailing lists" ! sigh ! Thomas On 27 Aug 2010, at 19:42, Lucy Lynch wrote: > FYI: > > -- > Dear Colleagues, > > On Friday 27 August, from 08:41 to 09:08 UTC, the RIPE NCC Routing > Information Service (RIS) announced a route with an experimental BGP > attribute. During this announcement, some Internet Service Providers > reported problems with their networking infrastructure. > > Investigation > -- > > Immediately after discovering this, we stopped the announcement and > started investigating the problem. Our investigation has shown that the > problem was likely to have been caused by certain router types > incorrectly modifying the experimental attribute and then further > announcing the malformed route to their peers. The announcements sent > out by the RIS were correct and complied to all standards. > > The experimental attribute was part of an experiment conducted in > collaboration with a group from Duke University. This involved > announcing a large (3000 bytes) optional transitive attribute, using a > modified version of Quagga. The attribute used type code 99. The data > consisted of zeros. We used the prefix 93.175.144.0/24 for this and > announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers. > > Reports from affected ISPs showed that the length of the attribute in > the attribute header, as seen by their routers, was not correct. The > header stated 233 bytes and the actual data in their samples was 237 > bytes. This caused some routers to drop the session with the peer that > announced the route. > > We have built a test set-up which is running identical software and > configurations to the live set-up. From this set-up, and the BGP packet > dumps as made by the RIS, we have determined that the length of the data > in the attribute as sent out by the RIS was indeed 3000 bytes and that > all lengths recorded in the headers of the BGP updates were correct. > > Beyond the RIS systems, we can only do limited diagnosis. One possible > explanation is that the affected routers did not correctly use the > extended length flag on the attribute. This flag is set when the length > of the attribute exceeds 255 bytes i.e. when two octets are needed to > store the length. > > It may be that the routers may not add the higher octet of the length to > the total length, which would lead, in our test set-up, to a total > packet length of 236 bytes. If, in addition, the routers also > incorrectly trim the attribute length, the problem could occur as > observed. It is worth noting that the difference between the reported > 233 and 237 bytes is the size of the flags, type code and length in the > attribute. > > We will be further investigating this problem and will report any > findings. We regret any inconvenience caused. > > Kind regards, > > Erik Romijn > > Information Services > RIPE NCC > ___ > tech-l mailing list > tec...@ams-ix.net > http://melix.ams-ix.net/mailman/listinfo/tech-l > > > > - Lucy > > On Fri, 27 Aug 2010, Grzegorz Janoszka wrote: > >> On 27-08-10 19:31, valdis.kletni...@vt.edu wrote: >>> On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? >>> If it in fact "crashed the internet", as opposed to "gave a few buggy >>> routers >>> here and there indigestion", you wouldn't be posting to NANOG looking for >>> confirmation. :) >> >> https://www.ams-ix.net/statistics/ >> >> Not whole internet, but a part. And the "few buggy routers here and there" >> were mostly Cisco CRS-1's which didn't understand the new attribute and sent >> a malformed message to all peers, causing them to close the BGP session. >> >> I think most of the impact was limited to Europe, especially Amsterdam area. >> >> >
Re: Did your BGP crash today?
sorry - found via google... - Lucy On Fri, 27 Aug 2010, Thomas Mangin wrote: So much for "better left off public mailing lists" ! sigh ! Thomas On 27 Aug 2010, at 19:42, Lucy Lynch wrote: FYI: -- Dear Colleagues, On Friday 27 August, from 08:41 to 09:08 UTC, the RIPE NCC Routing Information Service (RIS) announced a route with an experimental BGP attribute. During this announcement, some Internet Service Providers reported problems with their networking infrastructure. Investigation -- Immediately after discovering this, we stopped the announcement and started investigating the problem. Our investigation has shown that the problem was likely to have been caused by certain router types incorrectly modifying the experimental attribute and then further announcing the malformed route to their peers. The announcements sent out by the RIS were correct and complied to all standards. The experimental attribute was part of an experiment conducted in collaboration with a group from Duke University. This involved announcing a large (3000 bytes) optional transitive attribute, using a modified version of Quagga. The attribute used type code 99. The data consisted of zeros. We used the prefix 93.175.144.0/24 for this and announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers. Reports from affected ISPs showed that the length of the attribute in the attribute header, as seen by their routers, was not correct. The header stated 233 bytes and the actual data in their samples was 237 bytes. This caused some routers to drop the session with the peer that announced the route. We have built a test set-up which is running identical software and configurations to the live set-up. From this set-up, and the BGP packet dumps as made by the RIS, we have determined that the length of the data in the attribute as sent out by the RIS was indeed 3000 bytes and that all lengths recorded in the headers of the BGP updates were correct. Beyond the RIS systems, we can only do limited diagnosis. One possible explanation is that the affected routers did not correctly use the extended length flag on the attribute. This flag is set when the length of the attribute exceeds 255 bytes i.e. when two octets are needed to store the length. It may be that the routers may not add the higher octet of the length to the total length, which would lead, in our test set-up, to a total packet length of 236 bytes. If, in addition, the routers also incorrectly trim the attribute length, the problem could occur as observed. It is worth noting that the difference between the reported 233 and 237 bytes is the size of the flags, type code and length in the attribute. We will be further investigating this problem and will report any findings. We regret any inconvenience caused. Kind regards, Erik Romijn Information Services RIPE NCC ___ tech-l mailing list tec...@ams-ix.net http://melix.ams-ix.net/mailman/listinfo/tech-l - Lucy On Fri, 27 Aug 2010, Grzegorz Janoszka wrote: On 27-08-10 19:31, valdis.kletni...@vt.edu wrote: On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? If it in fact "crashed the internet", as opposed to "gave a few buggy routers here and there indigestion", you wouldn't be posting to NANOG looking for confirmation. :) https://www.ams-ix.net/statistics/ Not whole internet, but a part. And the "few buggy routers here and there" were mostly Cisco CRS-1's which didn't understand the new attribute and sent a malformed message to all peers, causing them to close the BGP session. I think most of the impact was limited to Europe, especially Amsterdam area.
Re: Did your BGP crash today?
On 27-08-10 20:41, Thomas Mangin wrote: I think most of the impact was limited to Europe, especially Amsterdam area. Yes, It had an effect on ISPs which are connected to RIS. http://www.ripe.net/ris/ AFAIK this mean ASes at LINX and AMS-IX . The LINX graph shows a similar (but smaller) dip of 50-60 GB. Not only. We don't peer with RIS, but about 8-10 our peers announce to us RIS. The nasty update we got from completely different AS, not RIS. You may just check whether you see AS12654 - it is RIS. -- Grzegorz Janoszka
Re: Did your BGP crash today?
On 27 Aug 2010, at 20:03, Grzegorz Janoszka wrote: > On 27-08-10 20:41, Thomas Mangin wrote: >>> I think most of the impact was limited to Europe, especially Amsterdam area. >> Yes, It had an effect on ISPs which are connected to RIS. >> http://www.ripe.net/ris/ >> AFAIK this mean ASes at LINX and AMS-IX . The LINX graph shows a similar >> (but smaller) dip of 50-60 GB. > > Not only. We don't peer with RIS, but about 8-10 our peers announce to us > RIS. The nasty update we got from completely different AS, not RIS. > You may just check whether you see AS12654 - it is RIS. Yes, the BGP message had a transitive attribute - sorry if I was not clear. That said, you may want to ask why you are getting RIS routes if you are not peering with them directly :p RIS is peering world wide ( http://www.ripe.net/ris/docs/peering.html ) but the mail was only sent to linx-ops and tech-l, so the announcement may have been limited to europe (for all I know). Thomas
Re: Did your BGP crash today?
On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: > > Unknown BGP attribute 99 (flags: 240) > Unknown BGP attribute 99 (flags: 240) > Unknown BGP attribute 99 (flags: 240) > Unknown BGP attribute 99 (flags: 240) > Unknown BGP attribute 99 (flags: 240) Just out of curiosity, at what point will we as operators rise up against the ivory tower protocol designers at the IETF and demand that they add a mechanism to not bring down the entire BGP session because of a single malformed attribute? Did I miss the memo about the meeting? I'll bring the punch and pie. -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Did your BGP crash today?
On 2010-08-27 21:13, Richard A Steenbergen wrote: > On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: >> >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) > > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? > I'll bring the punch and pie. Complain to your vendor, especially C & J are having good enough influence on the IETF to make such a change possible. I can agree with tearing the session down when one encounters an improperly formatted message, but an unknown attribute, while the rest of the format of message is fine, is a silly thing to hang up on indeed. Greets, Jeroen
Re: sort by agony
Marshall Eubanks wrote: > A _really_ intelligent airline scheduling system would (IMHO) be > able to offer you options like > > "there is a direct flight Pittsburgh -> Kansas City, and from there it > is a 2 hour drive to Columbia, so that will save you 5 hours travel time" That's not an airline scheduling system. That's a travel scheduling system. Different beast. > Regards > Marshall --Johnny
Re: Did your BGP crash today?
On Aug 27, 2010, at 3:13 PM, Richard A Steenbergen wrote: > On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: >> >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) > > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? > I'll bring the punch and pie. I think it's actually an implementation problem where it got out-of-sync. You can't exactly blame the IETF for a vendor having poor code quality. (at least not in this case IMHO). I seem to recall there was something like this in the past that caused some significant problems with people also running XR/CRS-1. They quickly got a fix and cisco issued a PSIRT as a result: http://www.cisco.com/en/US/products/products_security_advisory09186a0080af150f.shtml#summary I would hope these people updated their software for that impact as well. Without knowing what the defect impact was on those devices, and without talking to PSIRT today, I don't know if an advisory is pending. Perhaps it's a new defect and the bug is going to be triggered again soon for those that don't patch their devices. - jared
Re: Did your BGP crash today?
On Aug 27, 2010, at 3:17 PM, Jeroen Massar wrote: > On 2010-08-27 21:13, Richard A Steenbergen wrote: >> On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: >>> >>> Unknown BGP attribute 99 (flags: 240) >>> Unknown BGP attribute 99 (flags: 240) >>> Unknown BGP attribute 99 (flags: 240) >>> Unknown BGP attribute 99 (flags: 240) >>> Unknown BGP attribute 99 (flags: 240) >> >> Just out of curiosity, at what point will we as operators rise up >> against the ivory tower protocol designers at the IETF and demand that >> they add a mechanism to not bring down the entire BGP session because of >> a single malformed attribute? Did I miss the memo about the meeting? >> I'll bring the punch and pie. > > Complain to your vendor, especially C & J are having good enough > influence on the IETF to make such a change possible. > > > I can agree with tearing the session down when one encounters an > improperly formatted message, but an unknown attribute, while the rest > of the format of message is fine, is a silly thing to hang up on indeed. When you are processing something, it's sometimes hard to tell if something just was mis-parsed (as I think the case is here with the "missing-2-bytes") vs just getting garbage. Perhaps there should be some way to "re-sync" when you are having this problem, or a parallel "keepalive" path similar to MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is happening. - Jared
Re: Did your BGP crash today?
On 8/27/2010 3:22 PM, Jared Mauch wrote: > When you are processing something, it's sometimes hard to tell if something > just was mis-parsed (as I think the case is here with the "missing-2-bytes") > vs just getting garbage. Perhaps there should be some way to "re-sync" when > you are having this problem, or a parallel "keepalive" path similar to > MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is > happening. I know it wasn't there originally, and isn't mandatory now, but there is an MD5 hash that can be added to the packet. If the TCP hash checks out, then you know the packet wasn't garbled, and just contained information you didn't grok. That seems like enough evidence to be able to shrug and toss the packet without dropping the session. -Dave
Re: Idea's for donating/recycling server hardware [Off-Topic]
On Aug 26, 2010, at 10:03 PM, Suresh Ramasubramanian wrote: There's also http://www.nsrc.org at UOregon - as good a home as any , and better than most, for any gear you want to trash. On Fri, Aug 27, 2010 at 4:35 AM, Wil Schultz wrote: I apologize for being somewhat off topic... I've got a fair amount of SPARC hardware (v210 through v490) and 32bit HP DL360-380 hardware that I'm looking for creative ways to dispose of or to donate. It seems like a waste to send it to metal scrap, if anyone has a more creative way of disposal please contact me off list. Local to San Francisco. *disclaimer, contributions cannot go to religious or political organizations per corp policy* Thanks! -wil -- Suresh Ramasubramanian (ops.li...@gmail.com) -- "I try to be good hard-worker-man, but refrigemater so messy, so so messy." -- NewsRadio.
Re: Did your BGP crash today?
where's the change management process in all of this. basically now we are going to starting changing things that can potentially have an adverse affect on users without letting anyone know before hand Interesting concept. On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: > > On 8/27/2010 3:22 PM, Jared Mauch wrote: >> When you are processing something, it's sometimes hard to tell if something >> just was mis-parsed (as I think the case is here with the "missing-2-bytes") >> vs just getting garbage. Perhaps there should be some way to "re-sync" when >> you are having this problem, or a parallel "keepalive" path similar to >> MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is >> happening. > > I know it wasn't there originally, and isn't mandatory now, but there is > an MD5 hash that can be added to the packet. If the TCP hash checks > out, then you know the packet wasn't garbled, and just contained > information you didn't grok. That seems like enough evidence to be able > to shrug and toss the packet without dropping the session. > > -Dave > > > =+=+=+=+=+=+=+=+=+=+=+=+= Mike Gatti ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Did your BGP crash today?
On Fri, Aug 27, 2010 at 4:07 PM, Mike Gatti wrote: > where's the change management process in all of this. > basically now we are going to starting changing things that can > potentially have an adverse affect on users without letting anyone know > before hand Interesting concept. you are running bgp, you are connected to the 'internet'... congrats you are part of the experiment. I suppose one view is that "at least it wasn't someone with ill intent, or a misconfigured mikrotek!" (you are asking your vendors to run full bit sweeps of each protocol in a regimented manner checking for all possible edge cases and properly handling them, right?) -chris > On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: > >> >> On 8/27/2010 3:22 PM, Jared Mauch wrote: >>> When you are processing something, it's sometimes hard to tell if something >>> just was mis-parsed (as I think the case is here with the "missing-2-bytes") >>> vs just getting garbage. Perhaps there should be some way to "re-sync" when >>> you are having this problem, or a parallel "keepalive" path similar to >>> MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is >>> happening. >> >> I know it wasn't there originally, and isn't mandatory now, but there is >> an MD5 hash that can be added to the packet. If the TCP hash checks >> out, then you know the packet wasn't garbled, and just contained >> information you didn't grok. That seems like enough evidence to be able >> to shrug and toss the packet without dropping the session. >> >> -Dave >> >> >> > > =+=+=+=+=+=+=+=+=+=+=+=+= > Mike Gatti > ekim.it...@gmail.com > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > >
Fwd: Idea's for donating/recycling server hardware [Off-Topic]
Thank you for all of the replies, the response has been overwhelming. :-) I think we're going to be able to do some good stuff with this "junk", i'm going to start contacting some folks and get things going here shortly. Thank you! -wil Begin forwarded message: > From: Wil Schultz > Date: August 26, 2010 4:05:33 PM PDT > To: nanog@nanog.org > Subject: Idea's for donating/recycling server hardware [Off-Topic] > > I apologize for being somewhat off topic... > > I've got a fair amount of SPARC hardware (v210 through v490) and 32bit HP > DL360-380 hardware that I'm looking for creative ways to dispose of or to > donate. > > It seems like a waste to send it to metal scrap, if anyone has a more > creative way of disposal please contact me off list. Local to San Francisco. > > *disclaimer, contributions cannot go to religious or political organizations > per corp policy* > > Thanks! > > -wil
Re: Did your BGP crash today?
On Aug 27, 2010, at 12:13 PM, Richard A Steenbergen wrote: > > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? > I'll bring the punch and pie. About the same time vendors' BGP implementations start to work correctly? I agree such a knob would be useful, but seems to me that actually following the current standard would largely curb the issue by itself. I recall one of the previous times something like this happened (and with a much wider impact), I believe it was $C that was accepting a bad attribute and passing it along. The effect was that other vendors ($F in particular, I think) would drop the session (per RFC), which made it look like they were the broken ones. Instead of saying "why was this accepted from its source?" the community reaction seemed more to me to be "hey, BGP is breaking the internet!" If -everyone- dropped the session on a bad attribute, it likely wouldn't make it far enough into the wild to cause these problems in the first place. -c
Re: Did your BGP crash today?
On Fri, 27 Aug 2010 13:43:39 PDT, Clay Fiske said: > If -everyone- dropped the session on a bad attribute, it likely wouldn't > make it far enough into the wild to cause these problems in the first > place. That works fine for malformed attributes. It blows chunks for legally formed but unknown attributes - how would you ever deploy a new attribute? pgphZF03VSl1G.pgp Description: PGP signature
Re: Did your BGP crash today?
About the same time the operators get back into the IETF and become involved again. There was a time when operators played a large role in the development of things BGP (e.g. Tony Bates, Enke Chen, both at iMCI). No one is stopping us, the 'ivory tower' has no gate. jy On 28/08/2010, at 5:13 AM, Richard A Steenbergen wrote: > On Fri, Aug 27, 2010 at 01:29:15PM -0400, Jared Mauch wrote: >> >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) >> Unknown BGP attribute 99 (flags: 240) > > Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because of > a single malformed attribute? Did I miss the memo about the meeting? > I'll bring the punch and pie. > > -- > Richard A Steenbergenhttp://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > >
Re: Did your BGP crash today?
On Fri, Aug 27, 2010 at 01:43:39PM -0700, Clay Fiske wrote: > > If -everyone- dropped the session on a bad attribute, it likely > wouldn't make it far enough into the wild to cause these problems in > the first place. And if everyone filtered their BGP customers there would be no routing leaks, but we've seen how well that works. :) The "if anything bad happens, drop the session" method of protection is only effective if EVERY BGP implementation catches EVERY malformed update EVERY time, which just doesn't match up with reality. Not only that, but a healthy number of the bgp update issues over the years have actually been the result of implementations detecting perfectly valid things as invalid, which means by definition the implementations which get it right and don't drop the session act as carriers and spread the problem route globally. How long as we going to continue to act like this method of protection is actually working? Lets be reasonable, if your basic bgp message format is malformed you're going to need to drop the session. If the packet is corrupted or the size of the message doesn't match whats in the tlv, you're not going to be able to continue and you'll have to drop the session. But there are still a huge number of potential issues where it would be perfectly safe to drop the update you didn't like, and support for this could easily be negotiated and the sending side informed of the issue by a soft notification extension. I have yet to see a single argument against this which isn't political or philosophical in nature. -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Looking for Fiber Plant Management software
Most of the ones I have seen (2 out of 3) were inhouse/home-grown solutions. I believe the other was provided by SA (Scientific Atlanta). I tried to do a quick search on it and it appears that product may now be provided by Cisco in partnership with SA. Best of luck -Original Message- From: Jason Lixfeld Date: Fri, 27 Aug 2010 12:13:35 To: Jeff Saxe Cc: Subject: Re: Looking for Fiber Plant Management software I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > Good morning, NANOGers. My colleague at work wonders if anyone has > suggestions for software to database all our fiber plant that we're > constructing. We started out with paper, then Excel spreadsheets in a folder > and on paper in a book, but clearly as our plant grows and we do more > splicing this is not going to scale. We have started a MySQL database with a > few tables, but wonder if someone has already invented this wheel. > > What do the "big boys" use? Homegrown solutions developed in-house and > jealously guarded? Something standard? Expensive or cheap? Free open-source? > He'd like to see... > > outside plan facilities: cables, fibers, splice points, poles; copper and > fiber, preferably, but fiber is more important > "circuit" or "DLR" that knows what elements are involved in a circuit > GIS integration so that cables can be drawn on a map automagically > low cost, of course > > Thanks in advance, everyone. > > -- Jeff Saxe, Network Engineer > Blue Ridge InternetWorks, Charlottesville, VA > 434-817-0707 ext. 2024 / js...@briworks.com > > > >
RE: Looking for Fiber Plant Management software
OSP Insight. Pricey but an excellent tool for OSP documentation. -Original Message- From: khatfi...@socllc.net [mailto:khatfi...@socllc.net] Sent: Friday, August 27, 2010 2:24 PM To: Jason Lixfeld; Jeff Saxe Cc: nanog@nanog.org Subject: Re: Looking for Fiber Plant Management software Most of the ones I have seen (2 out of 3) were inhouse/home-grown solutions. I believe the other was provided by SA (Scientific Atlanta). I tried to do a quick search on it and it appears that product may now be provided by Cisco in partnership with SA. Best of luck -Original Message- From: Jason Lixfeld Date: Fri, 27 Aug 2010 12:13:35 To: Jeff Saxe Cc: Subject: Re: Looking for Fiber Plant Management software I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > Good morning, NANOGers. My colleague at work wonders if anyone has > suggestions for software to database all our fiber plant that we're > constructing. We started out with paper, then Excel spreadsheets in a folder > and on paper in a book, but clearly as our plant grows and we do more > splicing this is not going to scale. We have started a MySQL database with a > few tables, but wonder if someone has already invented this wheel. > > What do the "big boys" use? Homegrown solutions developed in-house and > jealously guarded? Something standard? Expensive or cheap? Free open-source? > He'd like to see... > > outside plan facilities: cables, fibers, splice points, poles; copper and > fiber, preferably, but fiber is more important > "circuit" or "DLR" that knows what elements are involved in a circuit > GIS integration so that cables can be drawn on a map automagically > low cost, of course > > Thanks in advance, everyone. > > -- Jeff Saxe, Network Engineer > Blue Ridge InternetWorks, Charlottesville, VA > 434-817-0707 ext. 2024 / js...@briworks.com > > > >
Re: Did your BGP crash today?
come on Chris, is the Internet an experiment or not? :) one would think that a responsible party would have made efforts to let others in the "playground" know they were going to try something different that could have ramifications on an unkown distribution of some code bases. I'm not asking my vendor or (in the case of OSS) me to run "full bit sweeps"... but a heads up to some of the known ops lists would have been not only welcome but expected. as usual, YMMV --bill On Fri, Aug 27, 2010 at 04:11:32PM -0400, Christopher Morrow wrote: > On Fri, Aug 27, 2010 at 4:07 PM, Mike Gatti wrote: > > where's the change management process in all of this. > > basically now we are going to starting changing things that can > > potentially have an adverse affect on users without letting anyone know > > before hand Interesting concept. > > you are running bgp, you are connected to the 'internet'... congrats > you are part of the experiment. > > I suppose one view is that "at least it wasn't someone with ill > intent, or a misconfigured mikrotek!" > > (you are asking your vendors to run full bit sweeps of each protocol > in a regimented manner checking for all possible edge cases and > properly handling them, right?) > > -chris > > > On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: > > > >> > >> On 8/27/2010 3:22 PM, Jared Mauch wrote: > >>> When you are processing something, it's sometimes hard to tell if > >>> something > >>> just was mis-parsed (as I think the case is here with the > >>> "missing-2-bytes") > >>> vs just getting garbage. Perhaps there should be some way to "re-sync" > >>> when > >>> you are having this problem, or a parallel "keepalive" path similar to > >>> MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is > >>> happening. > >> > >> I know it wasn't there originally, and isn't mandatory now, but there is > >> an MD5 hash that can be added to the packet. If the TCP hash checks > >> out, then you know the packet wasn't garbled, and just contained > >> information you didn't grok. That seems like enough evidence to be able > >> to shrug and toss the packet without dropping the session. > >> > >> -Dave > >> > >> > >> > > > > =+=+=+=+=+=+=+=+=+=+=+=+= > > Mike Gatti > > ekim.it...@gmail.com > > =+=+=+=+=+=+=+=+=+=+=+=+= > > > > > > > > > > >
Re: Did your BGP crash today?
On Fri, Aug 27, 2010 at 04:57:17PM -0400, valdis.kletni...@vt.edu wrote: > On Fri, 27 Aug 2010 13:43:39 PDT, Clay Fiske said: > > > If -everyone- dropped the session on a bad attribute, it likely wouldn't > > make it far enough into the wild to cause these problems in the first > > place. > > That works fine for malformed attributes. It blows chunks for legally formed > but unknown attributes - how would you ever deploy a new attribute? > This is covered by the RFC. Unknown attributes are either dropped or passed on depending on the attribute flags. The problem as in AS4 was that there where illegally formed unknown attributes that got passed around and made RFC compliant routers, which already handled AS4, further down the chain fail. This problem was addressed in "Error Handling for Optional Transitive BGP Attributes" but for some reasons people think it is necessary to make something simple more and more complex so this draft is still pending. -- :wq Claudio
BGP Update Report
BGP Update Report Interval: 19-Aug-10 -to- 26-Aug-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS541663690 4.3% 513.6 -- BATELCO-BH 2 - AS346425712 1.7%1836.6 -- ASC-NET - Alabama Supercomputer Network 3 - AS32528 18622 1.3%4655.5 -- ABBOTT Abbot Labs 4 - AS28573 17201 1.2% 16.8 -- NET Servicos de Comunicao S.A. 5 - AS35931 14837 1.0%2472.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS553614735 1.0% 136.4 -- Internet-Egypt 7 - AS16814 14708 1.0% 21.6 -- NSS S.A. 8 - AS982912047 0.8% 51.7 -- BSNL-NIB National Internet Backbone 9 - AS755211561 0.8% 13.3 -- VIETEL-AS-AP Vietel Corporation 10 - AS11351 11536 0.8% 36.0 -- RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 11 - AS13880 11319 0.8%1617.0 -- ACI-AS - american century investments 12 - AS580011102 0.8% 59.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS815110794 0.7% 15.2 -- Uninet S.A. de C.V. 14 - AS35567 10169 0.7% 95.9 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 15 - AS104749991 0.7% 525.8 -- NETACTIVE 16 - AS144209788 0.7% 17.7 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 17 - AS454648824 0.6% 245.1 -- NEXTWEB-AS-AP Room 201, TGU Bldg 18 - AS210177692 0.5% 769.2 -- VSI-AS VSI AS 19 - AS349847533 0.5% 26.3 -- TELLCOM-AS Tellcom Iletisim Hizmetleri 20 - AS3816 7497 0.5% 28.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS32528 18622 1.3%4655.5 -- ABBOTT Abbot Labs 2 - AS35931 14837 1.0%2472.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS346425712 1.7%1836.6 -- ASC-NET - Alabama Supercomputer Network 4 - AS13880 11319 0.8%1617.0 -- ACI-AS - american century investments 5 - AS535321270 0.1%1270.0 -- KINGMETALS - King Architectural Metals 6 - AS48565 926 0.1% 926.0 -- POCZTAPOLSKA-AS Poczta Polska Spolka Akcyjna 7 - AS27027 882 0.1% 882.0 -- ANBELL ASN-ANBELL 8 - AS210177692 0.5% 769.2 -- VSI-AS VSI AS 9 - AS11613 710 0.1% 710.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 10 - AS455421401 0.1% 700.5 -- VNU-AS-VN VietNam National University Ha Noi 11 - AS500101980 0.1% 660.0 -- NAWRAS-AS Omani Qatari Telecommunications Company SAOC 12 - AS104749991 0.7% 525.8 -- NETACTIVE 13 - AS541663690 4.3% 513.6 -- BATELCO-BH 14 - AS16861 460 0.0% 460.0 -- REVELEX - Revelex.com 15 - AS167184511 0.3% 451.1 -- EMBARQ-HMBL - Embarq Corporation 16 - AS15984 439 0.0% 439.0 -- The Joint-Stock Commercial Bank CentroCredit. 17 - AS49493 423 0.0% 423.0 -- SVT-AS SVT-Proveedor de Servicios de Internet 18 - AS20817 423 0.0% 423.0 -- DELTANET-AS Deltanet Autonomous System 19 - AS22580 370 0.0% 370.0 -- GUARD - GUARD INSURANCE GROUP 20 - AS430551793 0.1% 358.6 -- KATRINA-AS CJSC Katrina TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.128.0/17 12834 0.8% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.0.0/17 12825 0.8% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 196.2.16.0/24 9859 0.6% AS10474 -- NETACTIVE 4 - 130.36.34.0/24 9262 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.35.0/24 9262 0.6% AS32528 -- ABBOTT Abbot Labs 6 - 63.211.68.0/22 8599 0.6% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - 148.204.141.0/24 6213 0.4% AS8151 -- Uninet S.A. de C.V. 8 - 198.140.43.0/246188 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 190.65.228.0/225779 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 10 - 216.126.136.0/22 4947 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 11 - 84.255.152.0/244090 0.3% AS5416 -- BATELCO-BH 12 - 84.255.146.0/244082 0.3% AS5416 -- BATELCO-BH 13 - 84.255.145.0/244082 0.3% AS5416 -- BATELCO-BH 14 - 84.255.147.0/244082 0.3% AS5416 -- BATELCO-BH 15 - 95.32.128.0/18 3851 0.2% AS21017 -- VSI-AS VSI AS 16 - 95.32.192.0/18 3659 0.2% AS21017 -- VSI-AS VSI AS 17 - 206.184.16.0/243066 0.2% AS174 -- COGENT Cogent/PSI 18 - 77.69.143.0/24 2932 0.2% AS5416 -- BATELCO-BH 19 - 77.69.190.0/24 2932 0.2% AS5416 -- BATELCO-BH 20 - 77.69.142.0/24 2932 0.2% AS5416 -- BATELCO-BH Details
The Cidr Report
This report has been generated at Fri Aug 27 21:12:04 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
20-08-1040 205848
21-08-10332999 206105
22-08-10333406 206219
23-08-10333522 206203
24-08-10333578 206571
25-08-10333874 206667
26-08-10333708 206713
27-08-10333965 206728
AS Summary
35248 Number of ASes in routing system
14995 Number of ASes announcing only one prefix
4451 Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
97263040 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 27Aug10 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 334389 206722 12766738.2% All ASes
AS6389 3843 282 356192.7% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 4451 1872 257957.9% TWTC - tw telecom holdings,
inc.
AS19262 1802 276 152684.7% VZGNI-TRANSIT - Verizon Online
LLC
AS4766 1866 512 135472.6% KIXS-AS-KR Korea Telecom
AS22773 1180 66 111494.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4755 1482 431 105170.9% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS5668 1131 89 104292.1% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS17488 1342 302 104077.5% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS18566 1087 63 102494.2% COVAD - Covad Communications
Co.
AS6478 1308 372 93671.6% ATT-INTERNET3 - AT&T WorldNet
Services
AS8151 1526 635 89158.4% Uninet S.A. de C.V.
AS1785 1791 960 83146.4% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS10620 1102 290 81273.7% Telmex Colombia S.A.
AS8452 1147 425 72262.9% TEDATA TEDATA
AS7545 1407 721 68648.8% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS7303 791 115 67685.5% Telecom Argentina S.A.
AS4808 917 290 62768.4% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS13343 977 357 62063.5% SCRR-13343 - Road Runner
HoldCo LLC
AS4804 678 73 60589.2% MPX-AS Microplex PTY LTD
AS7552 654 114 54082.6% VIETEL-AS-AP Vietel
Corporation
AS17676 605 77 52887.3% GIGAINFRA Softbank BB Corp.
AS4780 685 161 52476.5% SEEDNET Digital United Inc.
AS7018 1470 953 51735.2% ATT-INTERNET4 - AT&T WorldNet
Services
AS7011 1136 659 47742.0% FRONTIER-AND-CITIZENS -
Frontier Communications of
America, Inc.
AS24560 1002 525 47747.6% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS14420 553 78 47585.9% CORPORACION NACIONAL DE
TELECOMUNICACIONES - CNT EP
AS22047 551 78 47385.8% VTR BANDA ANCHA S.A.
AS3356 1145 675 47041.0% LEVEL3 Level 3 Communications
AS28573 1025 566 45944.8% NET Servicos de Comunicao S.A.
AS36992 661 211 45068.1% ETISALAT-MISR
Total 39315122282708768.9% Top 30 total
Possible Bogus Routes
31.0.0.0/1
Re: Did your BGP crash today?
On Aug 27, 2010, at 5:37 PM, bmann...@vacation.karoshi.com wrote: come on Chris, is the Internet an experiment or not? :) one would think that a responsible party would have made efforts to let others in the "playground" know they were going to try something different that could have ramifications on an unkown distribution of some code bases. I'm assuming that they weren't really expecting this to cause issues... Where does one draw the line? I'm planning on announcing x.y.z.0/20 later in the week -- x, y and z are all prime and the sum of all 3 is also a prime. There is a non-zero chance that something somewhere will go flooie, shall I send mail now or later? Also, I would prefer that this gets discovered and dealt with (in this case by stopping the announcement :-)) than having folk not willing to try things and ending up with a weaponized version... W I'm not asking my vendor or (in the case of OSS) me to run "full bit sweeps"... but a heads up to some of the known ops lists would have been not only welcome but expected. as usual, YMMV --bill On Fri, Aug 27, 2010 at 04:11:32PM -0400, Christopher Morrow wrote: On Fri, Aug 27, 2010 at 4:07 PM, Mike Gatti wrote: where's the change management process in all of this. basically now we are going to starting changing things that can potentially have an adverse affect on users without letting anyone know before hand Interesting concept. you are running bgp, you are connected to the 'internet'... congrats you are part of the experiment. I suppose one view is that "at least it wasn't someone with ill intent, or a misconfigured mikrotek!" (you are asking your vendors to run full bit sweeps of each protocol in a regimented manner checking for all possible edge cases and properly handling them, right?) -chris On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: On 8/27/2010 3:22 PM, Jared Mauch wrote: When you are processing something, it's sometimes hard to tell if something just was mis-parsed (as I think the case is here with the "missing-2-bytes") vs just getting garbage. Perhaps there should be some way to "re-sync" when you are having this problem, or a parallel "keepalive" path similar to MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is happening. I know it wasn't there originally, and isn't mandatory now, but there is an MD5 hash that can be added to the packet. If the TCP hash checks out, then you know the packet wasn't garbled, and just contained information you didn't grok. That seems like enough evidence to be able to shrug and toss the packet without dropping the session. -Dave =+=+=+=+=+=+=+=+=+=+=+=+= Mike Gatti ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+= -- What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?" -- (Terry Pratchett, Pyramids)
Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability Advisory ID: cisco-sa-20100827-bgp Revision 1.0 For Public Release 2010 August 27 2200 UTC (GMT) +- Summary === Cisco IOS XR Software contains a vulnerability in the Border Gateway Protocol (BGP) feature. The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session. Affected devices running Cisco IOS XR Software corrupt the unrecognized attribute before sending to neighboring devices, but neighboring devices may be running operating systems other than Cisco IOS XR Software and may still reset the BGP peering session after receiving the corrupted update. This is per standards defining the operation of BGP. Cisco developed a fix that addresses this vulnerability and will be releasing free software maintenance upgrades (SMU) progressively starting 28 August 2010. This advisory will be updated accordingly as fixes become available. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml Affected Products = This vulnerability affects all Cisco IOS XR Software devices configured with BGP routing. Vulnerable Products +-- To determine the Cisco IOS XR Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS XR Software by displaying text similar to "Cisco IOS XR Software". The software version is displayed after the text "Cisco IOS XR Software". The following example identifies a Cisco CRS-1 that is running Cisco IOS XR Software Release 3.6.2: RP/0/RP0/CPU0:CRS#show version Tue Aug 18 14:25:17.407 AEST Cisco IOS XR Software, Version 3.6.2[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 1.49(20080319:195807) [CRS-1 ROMMON], CRS uptime is 4 weeks, 4 days, 1 minute System image file is "disk0:hfr-os-mbi-3.6.2/mbihfr-rp.vm" cisco CRS-8/S (7457) processor with 4194304K bytes of memory. 7457 processor at 1197Mhz, Revision 1.2 17 Packet over SONET/SDH network interface(s) 1 DWDM controller(s) 17 SONET/SDH Port controller(s) 8 TenGigabitEthernet/IEEE 802.3 interface(s) 2 Ethernet/IEEE 802.3 interface(s) 1019k bytes of non-volatile configuration memory. 38079M bytes of hard disk. 981440k bytes of ATA PCMCIA card at disk 0 (Sector size 512 bytes). Configuration register on node 0/0/CPU0 is 0x102 Boot device on node 0/0/CPU0 is mem: !--- output truncated The following example identifies a Cisco 12404 router that is running Cisco IOS XR Software Release 3.7.1: RP/0/0/CPU0:GSR#show version Cisco IOS XR Software, Version 3.7.1[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 12.0(20051020:160303) SOFTWARE Copyright (c) 1994-2005 by cisco Systems, Inc. GSR uptime is 3 weeks, 6 days, 3 hours, 20 minutes System image file is "disk0:c12k-os-mbi-3.7.1/mbiprp-rp.vm" cisco 12404/PRP (7457) processor with 2097152K bytes of memory. 7457 processor at 1266Mhz, Revision 1.2 1 Cisco 12000 Series Performance Route Processor 1 Cisco 12000 Series - Multi-Service Blade Controller 1 1 Port ISE Packet Over SONET OC-48c/STM-16 Controller (1 POS) 1 Cisco 12000 Series SPA Interface Processor-601/501/401 3 Ethernet/IEEE 802.3 interface(s) 1 SONET/SDH Port controller(s) 1 Packet over SONET/SDH network interface(s) 4 PLIM QoS controller(s) 8 FastEthernet/IEEE 802.3 interface(s) 1016k bytes of non-volatile configuration memory. 1000496k bytes of disk0: (Sector size 512 bytes). 65536k bytes of Flash internal SIMM (Sector size 256k). Configuration register on node 0/0/CPU0 is 0x2102 Boot device on node 0/0/CPU0 is disk0: !--- output truncated Additional information about Cisco IOS XR Software release naming conventions is available in the "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/web/about/security/intelligence/ios-ref.html#9 Additional information about Cisco IOS XR Software time-based release model is available in the "White Paper: Guidelines for Cisco IOS XR Software" at the following link: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8803/ps5845/product_bulletin_c25-478699.html BGP is conf
Re: Did your BGP crash today?
On Aug 27, 2010, at 1:57 PM, valdis.kletni...@vt.edu wrote: > On Fri, 27 Aug 2010 13:43:39 PDT, Clay Fiske said: > >> If -everyone- dropped the session on a bad attribute, it likely wouldn't >> make it far enough into the wild to cause these problems in the first >> place. > > That works fine for malformed attributes. It blows chunks for legally formed > but unknown attributes - how would you ever deploy a new attribute? By making it optional. Seems to me that's pretty well covered by the Path Attributes section of the RFC. A bad attribute isn't simply unknown, it's malformed. My apologies for not wording that more precisely. I do see the wisdom of fine-grained control of this behavior. I'm just saying, it'd be nice if we could have correct behavior on the basics in the first place. :) -c
Re: Did your BGP crash today?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Aug 27, 2010 at 5:02 PM, Clay Fiske wrote: > > On Aug 27, 2010, at 1:57 PM, valdis.kletni...@vt.edu wrote: > >> >> That works fine for malformed attributes. It blows chunks for legally >> formed but unknown attributes - how would you ever deploy a new >> attribute? > > By making it optional. Seems to me that's pretty well covered by the Path > Attributes section of the RFC. > > A bad attribute isn't simply unknown, it's malformed. My apologies for > not wording that more precisely. > > I do see the wisdom of fine-grained control of this behavior. I'm just > saying, it'd be nice if we could have correct behavior on the basics in > the first place. :) > As an aside, I see that Cisco has released a late Friday afternoon security advisory on this issue: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml FYI, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMeFNZq1pz9mNUZTMRAkR9AJ9cTz71N5/RMaQFD6LsumKLhpfASACdHrBR 4uQ0+oes21gvTS5IVJZXMds= =5wqD -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Did your BGP crash today?
Once upon a time, Paul Ferguson said: > As an aside, I see that Cisco has released a late Friday afternoon security > advisory on this issue: Huh, I had an upstream (with Cisco gear on their end) do "URGENT maintenance" last night with less than 12 hours notice. I wonder if this is why... -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Did your BGP crash today?
> Just out of curiosity, at what point will we as operators rise up > against the ivory tower protocol designers at the IETF and demand that > they add a mechanism to not bring down the entire BGP session because > of a single malformed attribute? there is a problem underlying this. bgp is not tlv. so once a parser detects an error, it can not *rigorously* know where to take up again. randy
Did your BGP crash today?
One of the affected platforms. I think it has info on IOS patches for it. I didn't read all of it as I don't have any Cisco products. -- Forwarded message -- From: Cisco Systems Product Security Incident Response Team Date: Fri, Aug 27, 2010 at 8:00 PM Subject: Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability To: na...@merit.edu Cc: ps...@cisco.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerability Advisory ID: cisco-sa-20100827-bgp Revision 1.0 For Public Release 2010 August 27 2200 UTC (GMT) +- Summary === Cisco IOS XR Software contains a vulnerability in the Border Gateway Protocol (BGP) feature. The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session. Affected devices running Cisco IOS XR Software corrupt the unrecognized attribute before sending to neighboring devices, but neighboring devices may be running operating systems other than Cisco IOS XR Software and may still reset the BGP peering session after receiving the corrupted update. This is per standards defining the operation of BGP. Cisco developed a fix that addresses this vulnerability and will be releasing free software maintenance upgrades (SMU) progressively starting 28 August 2010. This advisory will be updated accordingly as fixes become available. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml Affected Products = This vulnerability affects all Cisco IOS XR Software devices configured with BGP routing. Vulnerable Products +-- To determine the Cisco IOS XR Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS XR Software by displaying text similar to "Cisco IOS XR Software". The software version is displayed after the text "Cisco IOS XR Software". The following example identifies a Cisco CRS-1 that is running Cisco IOS XR Software Release 3.6.2: RP/0/RP0/CPU0:CRS#show version Tue Aug 18 14:25:17.407 AEST Cisco IOS XR Software, Version 3.6.2[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 1.49(20080319:195807) [CRS-1 ROMMON], CRS uptime is 4 weeks, 4 days, 1 minute System image file is "disk0:hfr-os-mbi-3.6.2/mbihfr-rp.vm" cisco CRS-8/S (7457) processor with 4194304K bytes of memory. 7457 processor at 1197Mhz, Revision 1.2 17 Packet over SONET/SDH network interface(s) 1 DWDM controller(s) 17 SONET/SDH Port controller(s) 8 TenGigabitEthernet/IEEE 802.3 interface(s) 2 Ethernet/IEEE 802.3 interface(s) 1019k bytes of non-volatile configuration memory. 38079M bytes of hard disk. 981440k bytes of ATA PCMCIA card at disk 0 (Sector size 512 bytes). Configuration register on node 0/0/CPU0 is 0x102 Boot device on node 0/0/CPU0 is mem: !--- output truncated The following example identifies a Cisco 12404 router that is running Cisco IOS XR Software Release 3.7.1: RP/0/0/CPU0:GSR#show version Cisco IOS XR Software, Version 3.7.1[00] Copyright (c) 2008 by Cisco Systems, Inc. ROM: System Bootstrap, Version 12.0(20051020:160303) SOFTWARE Copyright (c) 1994-2005 by cisco Systems, Inc. GSR uptime is 3 weeks, 6 days, 3 hours, 20 minutes System image file is "disk0:c12k-os-mbi-3.7.1/mbiprp-rp.vm" cisco 12404/PRP (7457) processor with 2097152K bytes of memory. 7457 processor at 1266Mhz, Revision 1.2 1 Cisco 12000 Series Performance Route Processor 1 Cisco 12000 Series - Multi-Service Blade Controller 1 1 Port ISE Packet Over SONET OC-48c/STM-16 Controller (1 POS) 1 Cisco 12000 Series SPA Interface Processor-601/501/401 3 Ethernet/IEEE 802.3 interface(s) 1 SONET/SDH Port controller(s) 1 Packet over SONET/SDH network interface(s) 4 PLIM QoS controller(s) 8 FastEthernet/IEEE 802.3 interface(s) 1016k bytes of non-volatile configuration memory. 1000496k bytes of disk0: (Sector size 512 bytes). 65536k bytes of Flash internal SIMM (Sector size 256k). Configuration register on node 0/0/CPU0 is 0x2102 Boot device on node 0/0/CPU0 is disk0: !--- output truncated Additional information about Cisco IOS XR Software release naming conventions is available in the "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/web/about/security/intelligence/i
Re: Did your BGP crash today?
> So much for "better left off public mailing lists" ! sigh ! damn! security through obscurity busted again. will people never learn?
Re: Idea's for donating/recycling server hardware [Off-Topic]
http://nsrc.org/ will clean up and ship to the academics and ngos in the significantly less spoiled and privileged countries. randy
Re: Looking for Fiber Plant Management software
We use Fiberworks from Enghouse. Its built atop ArcObjects and all data is stored in an ARCGIS geodatabase, providing good flexibility to get the data brought up on ArcGIS Server (Web) for web-based editing. The good thing about this system is that it can also be used for design of FTTH as well, and makes it possible to produce for-construction as well as as-built drawings (with cut sheets & etc.) http://www.enghouse.com/amd/products/fiberworks.html Our sister company (Xit telecom) which does OSP engineering/consulting/GIS can help implement this system. Regards, -=Francois=- -- Francois D. Menard Director of technology Xittel telecommunications inc. 1350 Royale #800 Trois-Rivieres, QC, G9A 4J4 Canada Tel: +1 819 601-6633 Fax: +1 819 374-0395 fmen...@xittel.net On 2010-08-27, at 5:31 PM, Jim Devane wrote: > OSP Insight. Pricey but an excellent tool for OSP documentation. > > > -Original Message- > From: khatfi...@socllc.net [mailto:khatfi...@socllc.net] > Sent: Friday, August 27, 2010 2:24 PM > To: Jason Lixfeld; Jeff Saxe > Cc: nanog@nanog.org > Subject: Re: Looking for Fiber Plant Management software > > Most of the ones I have seen (2 out of 3) were inhouse/home-grown solutions. > > I believe the other was provided by SA (Scientific Atlanta). I tried to do a > quick search on it and it appears that product may now be provided by Cisco > in partnership with SA. > > Best of luck > -Original Message- > From: Jason Lixfeld > Date: Fri, 27 Aug 2010 12:13:35 > To: Jeff Saxe > Cc: > Subject: Re: Looking for Fiber Plant Management software > > I've got a client who uses AutoCAD. They use it exclusively and have a > pretty big fibre network for someone who's not an ILEC, so I guess it works > fairly well. > > On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > >> Good morning, NANOGers. My colleague at work wonders if anyone has >> suggestions for software to database all our fiber plant that we're >> constructing. We started out with paper, then Excel spreadsheets in a folder >> and on paper in a book, but clearly as our plant grows and we do more >> splicing this is not going to scale. We have started a MySQL database with a >> few tables, but wonder if someone has already invented this wheel. >> >> What do the "big boys" use? Homegrown solutions developed in-house and >> jealously guarded? Something standard? Expensive or cheap? Free open-source? >> He'd like to see... >> >> outside plan facilities: cables, fibers, splice points, poles; copper and >> fiber, preferably, but fiber is more important >> "circuit" or "DLR" that knows what elements are involved in a circuit >> GIS integration so that cables can be drawn on a map automagically >> low cost, of course >> >> Thanks in advance, everyone. >> >> -- Jeff Saxe, Network Engineer >> Blue Ridge InternetWorks, Charlottesville, VA >> 434-817-0707 ext. 2024 / js...@briworks.com >> >> >> >> > > >
Re: Looking for Fiber Plant Management software
CableProject USA offers a free trial and a YT demo video. I can't vouch for it, never having witnessed it in operation personally, but it looks interesting. [1]http://www.cableprojectusa.com/ Cable Management Software runs the full gamut, from simplistic to near-ERP in scope, while others (e.g., VPI) also perform autoconfiguration and coordinated, parametric link designs for specific types of hardware (WDM, Switches/Routers, ROADMs, etc.). One can spend anywhere from free to $29.99 to tens of thousands of dollars, so decide carefully what you need, know specifically what you're looking for, and most of all, caveat emptor. --- franc...@menards.ca wrote: From: Francois Menard To: Jim Devane Cc: Jason Lixfeld , "nanog@nanog.org" Subject: Re: Looking for Fiber Plant Management software Date: Sat, 28 Aug 2010 00:53:04 -0400 We use Fiberworks from Enghouse. Its built atop ArcObjects and all data is stored in an ARCGIS geodatabase, providing good flexibility to get the data brought up on ArcGIS Server (Web) for web-based editing. The good thing about this system is that it can also be used for design of FTTH as well, and makes it possible to produce for-construction as well as as-built drawings (with cut sheets & etc.) http://www.enghouse.com/amd/products/fiberworks.html Our sister company (Xit telecom) which does OSP engineering/consulting/GIS can help implement this system. Regards, -=Francois=- -- Francois D. Menard Director of technology Xittel telecommunications inc. 1350 Royale #800 Trois-Rivieres, QC, G9A 4J4 Canada Tel: +1 819 601-6633 Fax: +1 819 374-0395 fmen...@xittel.net On 2010-08-27, at 5:31 PM, Jim Devane wrote: > OSP Insight. Pricey but an excellent tool for OSP documentation. > > > -Original Message- > From: khatfi...@socllc.net [mailto:khatfi...@socllc.net] > Sent: Friday, August 27, 2010 2:24 PM > To: Jason Lixfeld; Jeff Saxe > Cc: nanog@nanog.org > Subject: Re: Looking for Fiber Plant Management software > > Most of the ones I have seen (2 out of 3) were inhouse/home-grown solutions. > > I believe the other was provided by SA (Scientific Atlanta). I tried to do a quick search on it and it appears that product may now be provided by Cisco in partnership with SA. > > Best of luck > -Original Message- > From: Jason Lixfeld > Date: Fri, 27 Aug 2010 12:13:35 > To: Jeff Saxe > Cc: > Subject: Re: Looking for Fiber Plant Management software > > I've got a client who uses AutoCAD. They use it exclusively and have a pretty big fibre network for someone who's not an ILEC, so I guess it works fairly well. > > On 2010-08-27, at 11:39 AM, Jeff Saxe wrote: > >> Good morning, NANOGers. My colleague at work wonders if anyone has suggestions for software to database all our fiber plant that we're constructing. We started out with paper, then Excel spreadsheets in a folder and on paper in a book, but clearly as our plant grows and we do more splicing this is not going to scale. We have started a MySQL database with a few tables, but wonder if someone has already invented this wheel. >> >> What do the "big boys" use? Homegrown solutions developed in-house and jealously guarded? Something standard? Expensive or cheap? Free open-source? He'd like to see... >> >> outside plan facilities: cables, fibers, splice points, poles; copper and fiber, preferably, but fiber is more important >> "circuit" or "DLR" that knows what elements are involved in a circuit >> GIS integration so that cables can be drawn on a map automagically >> low cost, of course >> >> Thanks in advance, everyone. >> >> -- Jeff Saxe, Network Engineer >> Blue Ridge InternetWorks, Charlottesville, VA >> 434-817-0707 ext. 2024 / js...@briworks.com >> >> >> >> > > > References 1. http://www.cableprojectusa.com/
