Re: Standard prefix length filtering
You should not have any issues with a /22, most providers will accept /24 as the maximum length. refer to http://www.nanog.org/filter.html Regards Raymond chk 543 wrote: Is there a standard prefix length most providers filter on, or is there a way to find out what each provider filters on? We have been assigned a /22 and are wondering if we will have any issues with this block. Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us.
Re: Question on Loosely Synchronized Router Clocks
top posting to keep you alert! there are folks who syncronize clocks so that logs make sense. and those that do, tend to pick a common TZ... there is nothing like syncronizing logs from routers in Nepal, India, China, and LA UTC can be your friend... wrt acces to clock source - i'd be happy to have the httpd server code pulled out and adding a GPS/802.11 timesource to the platform of joy. of course presuming that a router clock is ammenable to an external discipline source. Many PC's are not... --bill On Tue, Sep 18, 2007 at 02:40:16PM -0500, Stephen Sprunk wrote: Thus spake Xin Liu [EMAIL PROTECTED] Sorry for the confusion. Let me clarify. We are interested in a number of questions: 1. Can we assume loosely synchronized router clocks in the Internet, or we have to make absolutely no assumption about router clocks at all? That assumption is _generally_ true, but not often enough that you can rely on it. 2. If the router clocks are indeed loosely synchronized, what is the granularity we can assume? Particularly, we are interested in whether we can assume router clocks are synchronized within 10 minutes. My experience is they'll either be within a few seconds or off by several days to years. There's not much middle ground. 3. It's always possible that a router's clock goes wrong. In practice, how often does this happen? It's unlikely to go wrong to any noticeable degree _if it was ever correct in the first place_. However, many people do not bother setting the clocks at all (which will often result in a clock that's off by a decade or more), or intentionally set them to be wrong. A lot of folks had to set their clocks back a few years around Y2k, for instance. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
When I wrote my book, I mostly looked at Cisco for this, and apart from Cisco to FreeBSD and Linux. The logic is that on a Cisco, you can build a good tunnel box (6to4 or manual tunnels) on a C7200 or some other box that has a decent CPU that can do the tunneling in software. Quite possibly a Juniper can do the same with hardware support (although I don't know that and it's also very possible that they can't do it in hardware or with decent speed in software) but there are no cheap(er) Juniper boxes that are suitable for deployment as a 5 - 200 Mbps tunnel box, in my opinion. Are you saying that 6to4 relay servers should be dedicated to that task? I.e. you should either dedicate a pair of routers per PoP or set up a couple of BSD/Linux boxes per PoP? --Michael Dillon
Re: Question on Loosely Synchronized Router Clocks
Stephen Sprunk wrote: ... is it reasonable to assume clock synchronization in the rest of our design? In general, it is not. I can't think of any existing protocol that does, actually. Kerberos. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature
RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Just stumbled upon this article http://www.networkworld.com/news/tech/2007/090507-tech-uodate.html Suggested here is that Dual Stack is more attractive than tunneling. Is the advise here based on real life experience or is it a matter of what is good for the goose may not be good for the gander? The article is written for enterprise network administrators, not for ISPs. If you are an ISP, the two main options are to dual-stack or to use MPLS with 6PE. Even if your network does not have an MPLS core today, you should still consider whether it makes sense to use MPLS with 6PE as your migration path to IPv6. Every network is different so there is really no panacea here. As for tunnels, I expect that everybody uses them somewhere in the network. There are lots of different kinds of tunnels, more than mentioned in the article. For ISP purposes, you could build an IPv6 overlay network instead of either dual-stacking or MPLS with 6PE. For small to midsize ISPs this may make a lot of sense. For larger ISPs, they will likely do some of this to accommodate their 2nd and 3rd tier PoP locations. The important thing about tunnels is to make sure that they are well-designed and well-maintained. The most important aspect of maintaining a tunnel, is making sure that you get rid of it when it is no longer the best solution. MPLS is based on tunneling. Lots of broadband access is based on tunnels. Pseudo-Wire Emulation is based on tunnels. --Michael Dillon
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 18-sep-2007, at 23:51, [EMAIL PROTECTED] wrote: On Tue, 18 Sep 2007 23:29:38 +0200, Iljitsch van Beijnum said: they can't do it in hardware or with decent speed in software) but there are no cheap(er) Juniper boxes that are suitable for deployment as a 5 - 200 Mbps tunnel box, in my opinion. I presume your thinking is that by the time you get to 200Mbps of tunneled stuff, it's time to get native mode turned up? No need to wait that long... Native is always the best way to go if possible. Honestly, I haven't considered the possiblity of someone needing more than a couple hundred megabits worth of tunnel traffic.
What's the real issue here?
:~ whois 97.81.31.19 Unknown AS number or IP network. Please upgrade this program. Is this a function of whois hardcoded to no do lookups for this address space? I can't seem to find any info about the range, beyond registered but unallocated. I figured whois would at least return something about it not being allocated. Is this hijacked space?
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On 19-sep-2007, at 11:58, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Are you saying that 6to4 relay servers should be dedicated to that task? No, of course not. However, even though today IPv6 traffic is fairly minimal for pretty much everyone, it has the potential to grow quickly now that more stuff comes with IPv6 support out of the box. If someone then adds an record to a service that generates a lot of traffic, a noticeable amount of traffic can move from IPv4 to IPv6 over night. So I wouldn't be comfortable doing any form of IPv6 that is limited to, say, 200 Mbps on a router that can handle many gigabits worth of IPv4 traffic. That way, if more than a few percent of the traffic moves from IPv4 to IPv6, you're in trouble. Note that this equally applies to tunnel en/decapsulation and regular IPv6 forwarding if those are not hardware accelerated. However, if you have a box that has the same IPv6 as IPv4 capabilities, you won't have any trouble. And if you have a somewhat limited box handle IPv6 and then IPv6 grows beyond the capabilities of that box, at least your IPv4 traffic isn't affected. I.e. you should either dedicate a pair of routers per PoP or set up a couple of BSD/Linux boxes per PoP? No need to do tunneling at leaf nodes (i.e., ones where all the traffic goes into one direction) and if you have at least two in your network one location can be backup for another, so then one per location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. But doing it on non-dedicated routers is fine as well as long as you're sure an excess of IPv6 traffic isn't going to cause problems.
Re: What's the real issue here?
# whois 97.81.31.19 0.0% 1 58.3 58.3 58.3 58.3 0.0? Charter Communications NETBLK-CHARTER-NET (NET-97-80-0-0-1) 97.80.0.0 - 97.90.255.255 Charter Communications KNG-TN-97-81-24 (NET-97-81-24-0-1) 97.81.24.0 - 97.81.31.255 # ARIN WHOIS database, last updated 2007-09-18 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. NetSecGuy wrote: :~ whois 97.81.31.19 Unknown AS number or IP network. Please upgrade this program. Is this a function of whois hardcoded to no do lookups for this address space? I can't seem to find any info about the range, beyond registered but unallocated. I figured whois would at least return something about it not being allocated. Is this hijacked space?
RE: What's the real issue here?
My whois program returns: 97.81.31.19 Host unreachable 97.81.24.0 - 97.81.31.255 Charter Communications 12405 Powerscourt Dr. St. Louis MO 63131 United States IPAddressing +1-314-288-3889 [EMAIL PROTECTED] Abuse: +1-314-288-3111 [EMAIL PROTECTED] KNG-TN-97-81-24 Created: 2007-04-11 Updated: 2007-04-11 Source: whois.arin.net Perhaps a function of how lookups are being done? *shrug* Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of NetSecGuy Sent: Wednesday, September 19, 2007 10:29 AM To: nanog@merit.edu Subject: What's the real issue here? :~ whois 97.81.31.19 Unknown AS number or IP network. Please upgrade this program. Is this a function of whois hardcoded to no do lookups for this address space? I can't seem to find any info about the range, beyond registered but unallocated. I figured whois would at least return something about it not being allocated. Is this hijacked space?
Re: Standard prefix length filtering
On Wed, Sep 19, 2007 at 09:03:35AM +0100, Andy Davidson wrote: On 19 Sep 2007, at 06:22, chk 543 wrote: Is there a standard prefix length most providers filter on, or is there a way to find out what each provider filters on? We have been assigned a /22 and are wondering if we will have any issues with this block. There are no hard and fast rules, but a general rule is the more you de-aggregate the more problems you are going to have, so unless you have a very good reason not to, announce the /22 and nothing longer. ...and if you think you have a reason to do so, carefully consider if the shorter prefix needs to be visibly globally or not. If you still are intent on deaggregating on a global scale and wish to guarantee no problems, send the deaggregates in addition to the aggregate such that you will still be visible to more-specific filters. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Wed, Sep 19, 2007, Iljitsch van Beijnum wrote: location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. As someone who is building little compact flash and USB flash based BSD boxes for various tasks, I can quite happily say its entirely possible to build diskless based Linux/BSD routers which are upgraded about as easy as upgrading a Cisco router (ie, copy over new image, run save-config script, reboot.) Its been that way for quite some time. If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. Adrian
Re: What's the real issue here?
Hi, On 19/09/2007, at 4:28 PM, NetSecGuy wrote: :~ whois 97.81.31.19 Unknown AS number or IP network. Please upgrade this program. Is this a function of whois hardcoded to no do lookups for this address space? I can't seem to find any info about the range, beyond registered but unallocated. I figured whois would at least return something about it not being allocated. Is this hijacked space? Please note that this error is actually being returned by the 'whois' program because it is out of date and does not know what registrar this IP range was allocated to yet quads:~ lathiat$ whois -h whois.arin.net 97.81.31.19 Charter Communications NETBLK-CHARTER-NET (NET-97-80-0-0-1) 97.80.0.0 - 97.90.255.255 Charter Communications KNG-TN-97-81-24 (NET-97-81-24-0-1) 97.81.24.0 - 97.81.31.255 # ARIN WHOIS database, last updated 2007-09-18 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. quads:~ lathiat$ Regards, Trent
Re: What's the real issue here?
On Wed, Sep 19, 2007 at 10:28:52AM -0400, NetSecGuy wrote: :~ whois 97.81.31.19 Unknown AS number or IP network. Please upgrade this program. Is this a function of whois hardcoded to no do lookups for this [snip] You are running some old version of whois - thanks for providing no OS or anything. It quite cleearly told you ityself that it is in need of upgrading, and the specifics will vary based on what the heck you are running. Perhaps a pointy-clicky client is more your speed? the ARIN web interface would tell you in this instance, and the geektools.com lookup is fairly bright about looking at multiple registries. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: What's the real issue here?
--- NetSecGuy [EMAIL PROTECTED] wrote: :~ whois 97.81.31.19 Unknown AS number or IP network. Please upgrade this program. Is this a function of whois hardcoded to no do lookups for this address space? I can't seem to find any info about the range, beyond registered but unallocated. I figured whois would at least return something about it not being allocated. Is this hijacked space? Sounds like you have a bad whois client. The web whois at arin.net shows that it's allocated to Charter. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
Adrian Chadd wrote: On Wed, Sep 19, 2007, Iljitsch van Beijnum wrote: location would be enough. If I had some old 7200s lying around I'd use those, in locations where replacing drives isn't a huge deal a BSD box (Linux if you insist) would be a good choice because they give you a bigger CPU for your money. As someone who is building little compact flash and USB flash based BSD boxes for various tasks, I can quite happily say its entirely possible to build diskless based Linux/BSD routers which are upgraded about as easy as upgrading a Cisco router (ie, copy over new image, run save-config script, reboot.) Its been that way for quite some time. If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/routers out of, and quite inexpensive. ~Seth
12u Colo+power in Level3, Orlando, TOMORROW
Guys, I hate to send this to nanog, and please direct all replies offlistbut this is a flat out last ditch effort to keep from losing a customer. I need about 12u of space @ 380 S. Lake Destiny Rd, Orlando FL and AC power for it (details on that not yet known, 10 dell PE1950s), and I need it tomorrow. This is the Level3 Gateway colo facility in Orlando. We can do daily, weekly, monthly, yearly, whatever, just have to get these boxes online. Other facilities are not an option unless you can also provide a 1G crossconnect from the L3 building by tomorrow. ;) Root problem is that we got caught with no power...and L3 has no more power to give. :( thanks, and sorry for the offtopic. --- david raistrickhttp://www.netmeister.org/news/learn2quote.html [EMAIL PROTECTED] http://www.expita.com/nomime.html
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Wed, Sep 19, 2007, Seth Mattinen wrote: If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 support, a routing daemon (whatever people think is good enough) and whatever other stuff is enough to act as a 6to4 gateway. You too can build diskless core2duo software routers for USD $1k. What about Soekris hardware? I don't have any personal experience with it, but it looks very appealing to build load balancers/routers out of, and quite inexpensive. Good for some things. You can get bigger things for ~ $1k in a 1ru formfactor that take single-core or dual-core CPUs depending on what you need. (I think the latest whitebox wholesaler was Supermicro who were pushing AUD $700 1ru barebones 300mm deep servers with an intel motherboard. Add RAM+CPU+flash, shake and stir.) How much traffic can a modern intel board with a core 2 duo handle with $EL_GENERIC_UNIX_OS ? Adrian
Re: What's the real issue here?
Point taken. I assumed my version of whois was up to date and my google results only showed it being unallocated. FWIW, OSX my default whois was 4.7.17, which I assumed was up to date. Updated to 4.7.20 and charter appears. Apologies for the time waster. On 9/19/07, Joe Provo [EMAIL PROTECTED] wrote: On Wed, Sep 19, 2007 at 10:28:52AM -0400, NetSecGuy wrote: :~ whois 97.81.31.19 Unknown AS number or IP network. Please upgrade this program. Is this a function of whois hardcoded to no do lookups for this [snip] You are running some old version of whois - thanks for providing no OS or anything. It quite cleearly told you ityself that it is in need of upgrading, and the specifics will vary based on what the heck you are running. Perhaps a pointy-clicky client is more your speed? the ARIN web interface would tell you in this instance, and the geektools.com lookup is fairly bright about looking at multiple registries. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)
On Wed, Sep 19, 2007, Alex Thurlow wrote: How much traffic can a modern intel board with a core 2 duo handle with $EL_GENERIC_UNIX_OS ? The PCI-Express bus tops out at 2.5 Gbps I believe, and they (Vyatta router salespeople to be specific) say you should be able to reach that. At 850 Mbps, my Intel Core 2 Duo running Quagga/IPtables (with a decent number of firewall rules) on Gentoo only hits about 30% CPU usage. With that, it sound like you could hit the 2.5Gbps if you had the connection. What pps are you seeing on that? Adrian
Level3 or Broadwing or other issues in Dallas ?
I'm in Louisiana and just lost my OC12 to Bwing/L3. Circuit didn't die, actually received a BGP message to terminate the session. Anyone else seeing anything or got an update? ALL the numbers I have to L3 are busy...
Re: Level3 or Broadwing or other issues in Dallas ?
on 2007-09-19 13:25 W. Kevin Hunt said the following: I’m in Louisiana and just lost my OC12 to Bwing/L3. Circuit didn’t die, actually received a BGP message to terminate the session. Anyone else seeing anything or got an update? ALL the numbers I have to L3 are busy... Same same for our client who's co-loed in the Bwing facility in NYC. Traceroutes die: 18 p6-0.c0.ftwo.broadwing.net (216.140.17.53) 161.712 ms 158.098 ms 158.154 ms 19 p4-0.c0.atln.broadwing.net (216.140.17.114) 174.425 ms 178.960 ms 177.797 ms 20 p3-0.c0.wash.broadwing.net (216.140.8.109) 188.125 ms 187.199 ms 188.288 ms 21 p0-2-0.a1.wash.broadwing.net (216.140.8.90) 187.539 ms 190.421 ms 185.878 ms different point A, same point Z: 23 p4-0.c0.atln.broadwing.net (216.140.17.114) 145.159 ms 143.587 ms 145.530 ms 24 p3-0.c0.wash.broadwing.net (216.140.8.109) 159.735 ms 161.113 ms 159.258 ms 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * and all the usual NOC numbers are either busy or fast-busy (!) It's probably not a total melt-down, as our voice PRIs there are all still OK. //jbaltz -- jerry b. altzman[EMAIL PROTECTED] www.jbaltz.com thank you for contributing to the heat death of the universe.
Re: Level3 or Broadwing or other issues in Dallas ?
On Wed, Sep 19, 2007 at 12:25:53PM -0500, W. Kevin Hunt wrote: I'm in Louisiana and just lost my OC12 to Bwing/L3. Circuit didn't die, actually received a BGP message to terminate the session. Anyone else seeing anything or got an update? ALL the numbers I have to L3 are busy... Seeing the same exact thing in Newark, DE. Ross
Level 3 in Ohio
Is anyone reporting Level3 outages in Ohio or DC ? One of my clients is down, and L3 is not answering the phones (!) traceroute 65.89.42.1 (From Cogent in Tyson's Corner) traceroute to 65.89.42.1 (65.89.42.1), 30 hops max, 38 byte packets 1 dmz-mct2.multicasttech.com (63.105.122.1) 0.367 ms 0.265 ms 0.238 ms 2 g0-7.na21.b002176-1.dca01.atlas.cogentco.com (38.99.206.153) 0.598 ms 0.548 ms 0.529 ms 3 g2-1-3587.core01.dca01.atlas.cogentco.com (38.20.32.13) 0.862 ms 0.834 ms 0.740 ms 4 t4-1.mpd01.dca01.atlas.cogentco.com (154.54.3.158) 0.801 ms 0.879 ms * 5 v3493.mpd01.dca02.atlas.cogentco.com (154.54.7.2) 1.328 ms 1.311 ms 1.247 ms 6 t1-4.mpd01.iad01.atlas.cogentco.com (154.54.7.162) 1.693 ms 1.598 ms 1.605 ms 7 g4-0-3490.core01.iad01.atlas.cogentco.com (154.54.3.225) 1.411 ms 1.453 ms 1.552 ms 8 oc48-6-0-2.edge2.Washington3.Level3.net (4.68.127.9) 1.577 ms 1.588 ms 16.498 ms 9 ae-44-99.car4.Washington1.Level3.net (4.68.17.198) 2.766 ms ae-24-79.car4.Washington1.Level3.net (4.68.17.70) 3.282 ms ae-34-89.car4.Washington1.Level3.net (4.68.17.134) 2.808 ms time out Cox Cable in Northern Virginia [TME-Laptop-2:~/Movies/NoisiVision] tme% traceroute 65.89.42.1 traceroute to 65.89.42.1 (65.89.42.1), 64 hops max, 40 byte packets 1 * * * 2 ip70-179-104-1.dc.dc.cox.net (70.179.104.1) 14.989 ms 11.563 ms 11.782 ms 3 ip68-100-1-161.dc.dc.cox.net (68.100.1.161) 18.078 ms 12.329 ms 12.036 ms 4 ip68-100-0-1.dc.dc.cox.net (68.100.0.1) 13.368 ms 12.301 ms 11.960 ms 5 mrfddsrj01-ge110.rd.dc.cox.net (68.100.0.161) 12.504 ms 11.729 ms * 6 xe-9-2-0.edge1.washington1.level3.net (4.79.228.61) 59.189 ms 12.721 ms 11.749 ms 7 ae-44-99.car4.washington1.level3.net (4.68.17.198) 13.502 ms 13.389 ms ae-34-89.car4.washington1.level3.net (4.68.17.134) 14.290 ms time out (Note that both trace routes appear to be flapping at the last reported hop. Regards Marshall
RE: Level3 or Broadwing or other issues in Dallas ?
Same thing in Chicago. Brian Knoll -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ross Vandegrift Sent: Wednesday, September 19, 2007 12:34 PM To: W. Kevin Hunt Cc: nanog@merit.edu Subject: Re: Level3 or Broadwing or other issues in Dallas ? On Wed, Sep 19, 2007 at 12:25:53PM -0500, W. Kevin Hunt wrote: I'm in Louisiana and just lost my OC12 to Bwing/L3. Circuit didn't die, actually received a BGP message to terminate the session. Anyone else seeing anything or got an update? ALL the numbers I have to L3 are busy... Seeing the same exact thing in Newark, DE. Ross
Re: Level3 or Broadwing or other issues in Dallas ?
On Wed, 19 Sep 2007, Jerry B. Altzman wrote: on 2007-09-19 13:25 W. Kevin Hunt said the following: I?m in Louisiana and just lost my OC12 to Bwing/L3. Circuit didn?t die, actually received a BGP message to terminate the session. Anyone else seeing anything or got an update? ALL the numbers I have to L3 are busy... Same same for our client who's co-loed in the Bwing facility in NYC. Traceroutes die: 18 p6-0.c0.ftwo.broadwing.net (216.140.17.53) 161.712 ms 158.098 ms 158.154 ms 19 p4-0.c0.atln.broadwing.net (216.140.17.114) 174.425 ms 178.960 ms 177.797 ms 20 p3-0.c0.wash.broadwing.net (216.140.8.109) 188.125 ms 187.199 ms 188.288 ms 21 p0-2-0.a1.wash.broadwing.net (216.140.8.90) 187.539 ms 190.421 ms 185.878 ms different point A, same point Z: 23 p4-0.c0.atln.broadwing.net (216.140.17.114) 145.159 ms 143.587 ms 145.530 ms 24 p3-0.c0.wash.broadwing.net (216.140.8.109) 159.735 ms 161.113 ms 159.258 ms 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * and all the usual NOC numbers are either busy or fast-busy (!) It's probably not a total melt-down, as our voice PRIs there are all still OK. //jbaltz -- jerry b. altzman[EMAIL PROTECTED] www.jbaltz.com thank you for contributing to the heat death of the universe. It just came up back here in SE PA. Last time this happened, the Broadwing 888 number was fast busy, as it was this time. The Level 3 Corporate HQ numbers were all normal busy, probably just swamped with calls from people like us. Traceroute from my Verizon FIOS account initially looked like this: traceroute to pil.net (207.7.198.3), 30 hops max, 40 byte packets 1 wireless_broadband_router (192.168.1.1) 1.146 ms 0.482 ms 0.464 ms 2 l100.vfttp-40.phlapa.verizon-gni.net (72.94.48.1) 7.87 ms 6.712 ms 7.088 ms 3 mail.pil.net (207.7.198.3) 15.164 ms !H Then went to this, shortly before coming back up: traceroute to 207.7.198.3 (207.7.198.3), 30 hops max, 40 byte packets 1 wireless_broadband_router (192.168.1.1) 1.237 ms 0.489 ms 0.436 ms 2 l100.vfttp-40.phlapa.verizon-gni.net (72.94.48.1) 7.528 ms 9.455 ms 19.71 ms 3 p1-1.lcr-04.phlapa.verizon-gni.net (130.81.59.102) 6.606 ms 18.624 ms 6.345 ms 4 130.81.29.214 (130.81.29.214) 9.617 ms 7.354 ms 7.097 ms 5 0.so-6-0-0.xl2.phl6.alter.net (152.63.3.81) 5.876 ms 7.501 ms 6.563 ms 6 0.so-6-0-0.xl4.iad8.alter.net (152.63.0.130) 12.968 ms 11.937 ms 11.486 ms 7 0.ge-7-0-0.br2.iad8.alter.net (152.63.41.157) 27.124 ms 17.941 ms 10.892 ms 8 4.68.127.25 (4.68.127.25) 23.224 ms 11.511 ms 13.252 ms 9 vlan99.csw4.washington1.level3.net (4.68.17.254) 24.319 ms vlan79.csw2.washington1.level3.net (4.68.17.126) 15.146 ms vlan99.csw4.washington1.level3.net (4.68.17.254) 21.856 ms 10 ae-64-64.ebr4.washington1.level3.net (4.69.134.177) 16.428 ms ae-84-84.ebr4.washington1.level3.net (4.69.134.185) 22.225 ms ae-74-74.ebr4.washington1.level3.net (4.69.134.181) 15.351 ms 11 ae-4.ebr3.losangeles1.level3.net (4.69.132.81) 84.88 ms 84.218 ms 89.179 ms 12 ae-2.ebr3.sanjose1.level3.net (4.69.132.9) 93.175 ms 100.726 ms 91.776 ms 13 ae-83-83.csw3.sanjose1.level3.net (4.69.134.234) 93.029 ms 84.361 ms 98.956 ms 14 ae-33-89.car3.sanjose1.level3.net (4.68.18.133) 90.771 ms 217.911 ms 118.959 ms 15 te-4-1-73.rp0-1.snjsca13.level3.net (4.68.63.6) 85.783 ms * * 16 216.140.3.65 (216.140.3.65) 98.25 ms 96.062 ms 96.013 ms 17 * * * 18 * * * 19 p4-0.c0.atln.broadwing.net (216.140.17.114) 152.745 ms 150.813 ms 151.869 ms 20 * * * 21 p0-2-0.a1.wash.broadwing.net (216.140.8.90) 171.344 ms 170.289 ms 163.337 ms 22 216.140.8.238 (216.140.8.238) 171.446 ms 157.893 ms 162.619 ms 23 66-243-174-57.focaldata.net (66.243.174.57) 175.231 ms 177.866 ms 171.83 ms 24 * * * 25 * * * James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
[Fwd: [Outages] FW: SMC INITIAL OUTAGE NOTIFICATION: MULTIPLE fBroadwing Markets]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI -/ - Original Message Subject: [Outages] FW: SMC INITIAL OUTAGE NOTIFICATION: MULTIPLE fBroadwing Markets Date: Wed, 19 Sep 2007 12:50:58 -0500 From: W. Kevin Hunt [EMAIL PROTECTED] To: [EMAIL PROTECTED] City/State: Mobile, AL Brief description of symptoms: . Multiple internet customers down due BGP being removed off multiple fBroadwing routers Cause of outage/impairment: BGP configuration removed The outage began at: 13:00 The outage is affecting: Multiple Customers Number of Reports: Unknown The department currently working on this problem is: Ops Eng/IP Core The external department/Telco currently working on this problem is: None Master Ticket number on this trouble: 2130326 Additional Comments/ETR: .. The following routers are impacting: a0-1-lsancaa1.bwng.log a0-1-phnxazb1.bwng.log a0-2-brkrdc.bwng.log a0-2-brkrtx04.bwng.log a0-2-dllstx02.bwng.log a0-3-atlnga8a.bwng.log a0-3-mdlyfla1.bwng.log a0-4-bltmmda1.bwng.log a0-4-nwrkdc.bwng.log a0-4-nwrkdea1.bwng.log a0-4-washdca1.bwng.log a0-5-chcgil02.bwng.log a0-5-cncnoha2.bwng.log a0-6-nwaknja1.bwng.log a0-6-nwyknya1.bwng.log a0-7-slkcdc.bwng.log a0-7-slkcuta2.bwng.log a0-8-sttlwa01.bwng.log a0-mplsmna2.bwng.log a1-2-brkrdc.bwng.log a1-7-slkcdc.bwng.log rp0-1-snjcca13.bwng.log rp0-2-dllstxri.bwng.log rp0-4-asnbvaas.bwng.log rp0-5-chcgilca.bwng.log -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8WUrpbZvCIJx1bcRAksBAKCKgjwX2jGoT7G2SNbGwAiugZ5tFwCZAbeD UOgG+/mgvhH8A7qhY0lPGgY= =TNwy -END PGP SIGNATURE-
Re: Level3 or Broadwing or other issues in Dallas ?
On Wed, 19 Sep 2007, W. Kevin Hunt wrote: I'm in Louisiana and just lost my OC12 to Bwing/L3. Circuit didn't die, actually received a BGP message to terminate the session. Looks like a change management Oops. I'm sure they are putting things back as fast as they can.
Re: Level 3 in Ohio
It's back up in Ohio, as of 2:05 PM EDT. On Sep 19, 2007, at 1:33 PM, Marshall Eubanks wrote: Is anyone reporting Level3 outages in Ohio or DC ? One of my clients is down, and L3 is not answering the phones (!) traceroute 65.89.42.1 (From Cogent in Tyson's Corner) traceroute to 65.89.42.1 (65.89.42.1), 30 hops max, 38 byte packets 1 dmz-mct2.multicasttech.com (63.105.122.1) 0.367 ms 0.265 ms 0.238 ms 2 g0-7.na21.b002176-1.dca01.atlas.cogentco.com (38.99.206.153) 0.598 ms 0.548 ms 0.529 ms 3 g2-1-3587.core01.dca01.atlas.cogentco.com (38.20.32.13) 0.862 ms 0.834 ms 0.740 ms 4 t4-1.mpd01.dca01.atlas.cogentco.com (154.54.3.158) 0.801 ms 0.879 ms * 5 v3493.mpd01.dca02.atlas.cogentco.com (154.54.7.2) 1.328 ms 1.311 ms 1.247 ms 6 t1-4.mpd01.iad01.atlas.cogentco.com (154.54.7.162) 1.693 ms 1.598 ms 1.605 ms 7 g4-0-3490.core01.iad01.atlas.cogentco.com (154.54.3.225) 1.411 ms 1.453 ms 1.552 ms 8 oc48-6-0-2.edge2.Washington3.Level3.net (4.68.127.9) 1.577 ms 1.588 ms 16.498 ms 9 ae-44-99.car4.Washington1.Level3.net (4.68.17.198) 2.766 ms ae-24-79.car4.Washington1.Level3.net (4.68.17.70) 3.282 ms ae-34-89.car4.Washington1.Level3.net (4.68.17.134) 2.808 ms time out Cox Cable in Northern Virginia [TME-Laptop-2:~/Movies/NoisiVision] tme% traceroute 65.89.42.1 traceroute to 65.89.42.1 (65.89.42.1), 64 hops max, 40 byte packets 1 * * * 2 ip70-179-104-1.dc.dc.cox.net (70.179.104.1) 14.989 ms 11.563 ms 11.782 ms 3 ip68-100-1-161.dc.dc.cox.net (68.100.1.161) 18.078 ms 12.329 ms 12.036 ms 4 ip68-100-0-1.dc.dc.cox.net (68.100.0.1) 13.368 ms 12.301 ms 11.960 ms 5 mrfddsrj01-ge110.rd.dc.cox.net (68.100.0.161) 12.504 ms 11.729 ms * 6 xe-9-2-0.edge1.washington1.level3.net (4.79.228.61) 59.189 ms 12.721 ms 11.749 ms 7 ae-44-99.car4.washington1.level3.net (4.68.17.198) 13.502 ms 13.389 ms ae-34-89.car4.washington1.level3.net (4.68.17.134) 14.290 ms time out (Note that both trace routes appear to be flapping at the last reported hop. Regards Marshall
RE: Level 3 in Ohio
I can ping 65.89.42.1 from here and it seems to be going through level3. traceroute to 65.89.42.1 (65.89.42.1), 30 hops max, 38 byte packets 1 wookie-02.core..net () 0.454 ms 0.458 ms 0.320 ms 2 wookie-01-fe-2-0.core..net (xx) 0.678 ms 0.648 ms 0.559 ms 3 ge-5-0-102.hsa2.Cincinnati1.Level3.net (63.210.xx) 0.826 ms 0.747 ms 1.742 ms 4 so-5-0-0.mpls1.Cincinnati1.Level3.net (4.68.124.241) 0.819 ms 0.858 ms 1.102 ms 5 so-2-0-1.bbr2.Chicago1.Level3.net (64.159.0.162) 7.157 ms 7.216 ms ae-0-0.bbr1.Chicago1.Level3.net (64.159.1.33) 6.998 ms 6 ae-24-52.car4.Chicago1.Level3.net (4.68.101.40) 7.449 ms ae-14-51.car4.Chicago1.Level3.net (4.68.101.8) 7.525 ms ae-14-53.car4.Chicago1.Level3.net (4.68.101.72) 7.503 ms 7 te-4-1-73.rp0-5.chcgilca.Level3.net (4.68.63.14) 8.883 ms 11.020 ms 8.155 ms 8 P5-0.a0.chcg.broadwing.net (216.140.14.109) 8.120 ms 13.737 ms 8.424 ms 9 p2-0-0.e1.chcg.broadwing.net (216.140.15.30) 8.987 ms 7.944 ms 8.161 ms 10 67.99.9.158 (67.99.9.158) 15.497 ms * 16.167 ms Mike Walter, MCP Systems Administrator 3z.net a PCD Company http://www.3z.net When Success is the Only Solution think 3z.net tel: 859.331.9004 fax: 859.578.3522 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marshall Eubanks Sent: Wednesday, September 19, 2007 1:34 PM To: nanog list Subject: Level 3 in Ohio Is anyone reporting Level3 outages in Ohio or DC ? One of my clients is down, and L3 is not answering the phones (!) traceroute 65.89.42.1 (From Cogent in Tyson's Corner) traceroute to 65.89.42.1 (65.89.42.1), 30 hops max, 38 byte packets 1 dmz-mct2.multicasttech.com (63.105.122.1) 0.367 ms 0.265 ms 0.238 ms 2 g0-7.na21.b002176-1.dca01.atlas.cogentco.com (38.99.206.153) 0.598 ms 0.548 ms 0.529 ms 3 g2-1-3587.core01.dca01.atlas.cogentco.com (38.20.32.13) 0.862 ms 0.834 ms 0.740 ms 4 t4-1.mpd01.dca01.atlas.cogentco.com (154.54.3.158) 0.801 ms 0.879 ms * 5 v3493.mpd01.dca02.atlas.cogentco.com (154.54.7.2) 1.328 ms 1.311 ms 1.247 ms 6 t1-4.mpd01.iad01.atlas.cogentco.com (154.54.7.162) 1.693 ms 1.598 ms 1.605 ms 7 g4-0-3490.core01.iad01.atlas.cogentco.com (154.54.3.225) 1.411 ms 1.453 ms 1.552 ms 8 oc48-6-0-2.edge2.Washington3.Level3.net (4.68.127.9) 1.577 ms 1.588 ms 16.498 ms 9 ae-44-99.car4.Washington1.Level3.net (4.68.17.198) 2.766 ms ae-24-79.car4.Washington1.Level3.net (4.68.17.70) 3.282 ms ae-34-89.car4.Washington1.Level3.net (4.68.17.134) 2.808 ms time out Cox Cable in Northern Virginia [TME-Laptop-2:~/Movies/NoisiVision] tme% traceroute 65.89.42.1 traceroute to 65.89.42.1 (65.89.42.1), 64 hops max, 40 byte packets 1 * * * 2 ip70-179-104-1.dc.dc.cox.net (70.179.104.1) 14.989 ms 11.563 ms 11.782 ms 3 ip68-100-1-161.dc.dc.cox.net (68.100.1.161) 18.078 ms 12.329 ms 12.036 ms 4 ip68-100-0-1.dc.dc.cox.net (68.100.0.1) 13.368 ms 12.301 ms 11.960 ms 5 mrfddsrj01-ge110.rd.dc.cox.net (68.100.0.161) 12.504 ms 11.729 ms * 6 xe-9-2-0.edge1.washington1.level3.net (4.79.228.61) 59.189 ms 12.721 ms 11.749 ms 7 ae-44-99.car4.washington1.level3.net (4.68.17.198) 13.502 ms 13.389 ms ae-34-89.car4.washington1.level3.net (4.68.17.134) 14.290 ms time out (Note that both trace routes appear to be flapping at the last reported hop. Regards Marshall
Re: Level3 or Broadwing or other issues in Dallas ?
Yep - Chicago also. On Wednesday 19 September 2007 12:25:53 W. Kevin Hunt wrote: I'm in Louisiana and just lost my OC12 to Bwing/L3. Circuit didn't die, actually received a BGP message to terminate the session. Anyone else seeing anything or got an update? ALL the numbers I have to L3 are busy...
ipv6/v4 naming nomenclature [Was: Apple Air...]
On Sep 18, 2007, at 1:30 PM, David Conrad wrote: HI, On Sep 18, 2007, at 5:45 AM, Jeroen Massar wrote: Please please please, for the sake of a semi-'standard', please only use the following forms in those cases: www.domain www.ipv6.domain www.ipv4.domain Don't come up with any other variants. The above form is what is in general use around the internet and what some people will at least try to use in cases where a DNS label has both an and A and one of them doesn't work. You can of course add them, it is your DNS, but with the above people might actually try them. What RFC (or other standards publication) is this documented in? Where did the www.ipv6 and www.ipv4 standard come from? As for end- users such as normal non-network people, having a standard that adds more characters than necessary (that eventually may become arbitrary) seems rather silly. Why wouldn't w4.domain or w6.domain suffice for this purpose rather than making it overly scientific? I can understand the want to use ipv4 etc to separate out other services such as DNS, SMPT, etc, but everyone does what they want with those services anyway. -Barrett
Re: ipv6/v4 naming nomenclature [Was: Apple Air...]
Barrett Lyon wrote: On Sep 18, 2007, at 1:30 PM, David Conrad wrote: [..] On Sep 18, 2007, at 5:45 AM, Jeroen Massar wrote: Please please please, for the sake of a semi-'standard', please only use [..] What RFC (or other standards publication) is this documented in? Where did the www.ipv6 and www.ipv4 standard come from? Note my clear use of semi and 'standard' and mind the quotes. Also note that for instance an IETF standard is only a standard when something in very common use for quite some time. Maybe this would be a good one to jot down as an Informational/BCP kind of document. It is something which is in use by a lot of sites who have been enabled with IPv6 for about the last 10 years and needed a way to distinct IPv4 and IPv6 variants of their hosts. Remember, before that people on NANOG started noticing the existence of IPv6 in the last few months, and before we had the 6bone with 3ffe::/16 there was also a 6bone with 5f00::/8 (RFC1897, which I really had to look up as my bear is not that long ;), oddly enough that is even before most people even had internet or knew that it existed. As for end-users such as normal non-network people, having a standard that adds more characters than necessary (that eventually may become arbitrary) seems rather silly. It is not meant to be used by end-users. Those should simply Google/Yahoo/Baidu for the description of the site and get the content and not be bother with remembering hostnames, let them use bookmarks or something, then they at least won't be caught by typo-squatters who are dominating the DNS system. It is only a semi-'standard' which is in use by network operators who didn't want to remember the or A for a hostname while being able to choose a protocol to ping/telnet/ssh/etc as there was a time when we already had IPv6 but some tools (yes, including PuTTY ;) did not allow selection of either IPv4 or IPv6 protocols. But also allowing the hosts to have an + A so that a tool could pick the protocol that was available. Sometimes you want to select that thus using: hostname.example.com A + hostname.ipv6.example.com A hostname.ipv4.example.com A solved that problem without having to add support for a '-6' or '-4' switch for IPv6 and IPv4 respectively into all tools that one uses. Some code doesn't come with source and some people don't want to patch it up so this is a perfect way to solve it. As mentioned above, this is for people who want to pick the version of IP protocol used. End-users don't even know what IP is, and they also should not know and they definitely should not have to care. As such, when you think that your site is 'working fine' over IPv4, then add an A record to it, when you think that IPv6 is fine, add an record, otherwise, have a trick like http://www.braintrust.co.nz/ipv6wwwtest/ and test if your users can reach the IPv6 variant or not. Most likely they won't have IPv6 enabled yet, if they have then great :) Why wouldn't w4.domain or w6.domain suffice for this purpose rather than making it overly scientific? It would suffice, it just is not what is in use. Also some people like to actually name OTHER things than their 'www' with it. The trend for that seems to be more that you can ignore the 'www' portion anyway and just http://youtube.com or http://google.com work. Also, I know a certain company using 'w3' for intranet-only websites, while using 'www' for internet websites. Greets, Jeroen signature.asc Description: OpenPGP digital signature
RH0 and Enterprise Input
Nanogers- Specifically Enterprise nogers. Not sure if you are aware of this IETF draft on RH0. Its in last call. So if you want to voice your opinion on whether you feel everyone should stop the traffic that has RH0 headers from moving on or just ignore it and let it on by, you will need to make your voice heard now. For the most part everyone is ok with this draft because it doesnt effect them and it helps address a security issue. I havnt heard a large voice from the Enterprise arena who might actually need the traffic to be passed on and not stopped. Thus, my posting this on nanog. -Cheers! Marla Official last call notice: The IESG has received a request from the IP Version 6 Working Group WG (ipv6) to consider the following document: - 'Deprecation of Type 0 Routing Headers in IPv6 ' draft-ietf-ipv6-deprecate-rh0-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-09-24. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-01.txt AD's follow-up: I wanted to mention a few points regarding this document, given that the matter has been the subject of some controversy. There was clear consensus in the WG for picking this approach, but it was also a rough consensus, with a number of differing opinions. One of the concerns was that the discussed vulnerabilities do not justify changing the specifications. First, this is not the first or the last time we find security issues or other bugs in our protocols. This particular issue has gotten more interest than it probably deserves; as bugs and changes go, its a very small one. But this does not imply that we can forget it and do nothing. The IETF is responsible for its specifications much the same way as vendors are responsible for their products. When there's a bug or a security vulnerability in our specifications, it is our duty to take notice and take appropriate action. Perhaps we can debate what that action should be, but it most certainly should include documentation of the issue, and in some cases modification of the spec in question. I personally want to ensure that IETF specifications and the real world are in sync, both in terms of describing what implementations actually do, and in the specifications being complete descriptions of the issues that one must think about. No one should have to hunt list discussions and operational folklore to find out how to implement key parts of our protocol stacks. A similar concern was why IPv6 is being treated differently from IPv4, which has similar source routing features. But there is a fairly big difference between the features when looking at the details. Specifically, IPv6 allows a much larger number of addresses to be used in the routing list, resulting in a greater potential for amplification. (But frankly, I suspect that even in IPv4 we have a difference between what our RFCs say and what the true implementation and operational practice is. Maybe the by-default-on rule from RFC 1812 should be revisited. Once we are done with this document we need to look at the IPv4 situation as well.) Another concern is that if Type 0 Route Header is deprecated, it is hard to bring back, if we later find out that we need it. However, new Types can be defined with relative ease -- in fact, I have personal experience of this in RFC 3775, and the process was smooth, I can recommend it. Finally, a process note required by our downref process: The document Updates both RFC 2460 (core IPv6 spec, DS) by removing functionality and RFC 4294 (IPv6 node requirements, Informational) while itself being destined for PS. Jari Arkko AD for IPv6 WG
