- Test - lists.nanog.org

Re: problems with covad.net 192.168 address space
by Robert Bonomi 02 Aug '04

02 Aug '04

> From owner-nanog(a)merit.edu Mon Aug 2 17:30:06 2004 > Date: Mon, 02 Aug 2004 18:25:00 -0400 > From: Eric Kimminau <ekimminau(a)rainfinity.com> > To: nanog(a)merit.edu > Subject: problems with covad.net 192.168 address space > > > Hola! > > Anyone having problems with covad.net and 192.168 public broadcasts? Covad uses some RFC-1918 space internally, for routers, etc. Nothing unusual there. They are known to use the low part of the 172.16.0.0/12 space for the PPP links betwen CPE and DSLAM, and the high part of the same space for the 'upstream gateway'. They use 192.168.0.0/16 for internal routing. They do not use 'Net 10' _at_all_. A traceroute from my home network goes from my dsl modem/router to a 172.31.x.x address; then through two 192.168.x.x addresses, And then to the public internet. Covad does NOT filter *any* RFC-1918 _source_address_ packets from going _to_ their customers. I've had some lengthy discussions with their abuse desk about this, when my firewall has blocked/logged hostile *incoming* packets with RFC-1918 source addresses. For "some strange reason" they can't tell, _or_track_, where those packets are coming from. I'm told they _do_ have RFC-1918 ingress and egress filtering for both source and destination addresses, at their gateways to the _external_ internet. That -that- filtering means that the stuff that shows up 'at _my_ front door' *is* coming from another COVAD customer, and not from "somewhere _outside_ Covad's network".

1 0

problems accessing 128.171.*
by Brian Russo 02 Aug '04

02 Aug '04

Is anyone else having problems accessing 128.171.* (hawaii.edu) - bri -- Recursivity. Call back if it happens again.

3 3

ATT Worldnet Mail Contact?
by Mike Lyon 02 Aug '04

02 Aug '04

Could someone from ATT Worldnet who has access to blacklist info please contact me offlist? Thank You, Mike

1 0

Test, please ignore
by Michael Hallgren 01 Aug '04

01 Aug '04

test

1 0

RE: Quick question.
by Michel Py 01 Aug '04

01 Aug '04

> Michael Loftis wrote: > Eh really? Whenever I've lost a second CPU (primary or secondary) > the machine was a brick until the secondary CPU was gutted and for > Piii slotted systems a terminator board was installed in the > secondary slot. That was with PIIs, PPros and PIIIs; and not always. When I said "Xeon" I assumed a P4 Xeon; nobody's sold PIII system for a while. I have seen number of PII and PIII dual-capable motherboards that work with one CPU without a processor terminator though, including the very successful slot-1 440BX and 440GX based workhorses (that power the majority of PII and PIII Xeons). Since the 7501 Intel chipset, BIOSes are able to detect processor failures all the time, apparently. (O/T) that's why I avoid RDRAM like the plague too: does not work without a terminator in unused slots. AFAIC, the main annoyance of dual-capable mobos with single processors has historically been that you needed to install M$ with two processors if you wanted to upgrade to dual-proc later; this has changed with hyperthreading, as now even single-processor systems are seen by Windows as a duallie. > What motherboard(s) you using that are holding up to failures > like this? The last two failures I can remember were an Intel whitebox with SE7501BR2 motherboard and a Dell mobo also based on the 7501 (can't remember the P/N) (some Dell boards are close derivatives of the Intel design). For hardware I have touched myself recently, I can assure that none of the following require a processor terminator: http://indigo.intel.com/mbsg/details.aspx?compID=1915 http://indigo.intel.com/mbsg/details.aspx?compID=1887 Proliant DL380. I have tested numerous Tyan and Supermicro 7501 and 7505 boards as well and none required a processor terminator. I have never seen an AMD board that required terminators either. I plan to test the following two DDRII-400 7525 boards when released: http://www.tyan.com/products/html/thunderi7525.html http://www.supermicro.com/products/motherboard/Xeon800/E7525/X6DA8-G2.cf m and they don't require terminators either. Terminators are a thing of the past; as a matter of fact, in California and especially in Sacramento they're called governators now. > My experience has shown PSU and motherboard failures are > faaaaar more common than CPUs. It used to be true, but not anymore. A 2.4 GHz Xeon currently _retails_ for $200 something (care to guess what the OEM price for 1,000 is?), it can't be as reliable as when we used to pay $2,800 for it. Also, there was a time where fan failure would account for half of the PS failures, not true anymore either. Michel.

3 2

RE: Next hop issues inside AS577 to AS852?
by Mike Tancsa 31 Jul '04

31 Jul '04

At 08:27 AM 31/07/2004, Krichbaum, Eric wrote: >If it's every 60 seconds, I'd suspect the BGP timer is the root. They >probably forgot to use next-hop self or a static route to a peer. The >end result being that the route to the bgp peer is learned via bgp >itself... Maybe. Hard to say if thats what their default hold time is. I am still seeing the odd hit in their network. For the sites we connect with inside Bell, the tunnel LQR expire is 10 seconds and we have seen 2 big bounces since routing around this morning. I emailed their noc, but no response. The Bell looking glass doesnt seem to have any flap statistics so I dont know if things are bouncing inside :( It is looking different once again. Via Cogent to me, 194# traceroute 199.212.134.1 traceroute to 199.212.134.1 (199.212.134.1), 64 hops max, 44 byte packets 1 HSE-MTL-ppp12931.qc.sympatico.ca (209.226.183.241) 266.986 ms 229.511 ms 209.679 ms 2 Hamilton-ppp278329.sympatico.ca (206.172.130.250) 419.439 ms 219.614 ms 199.657 ms 3 kitcorr01-fe0-0-0.15.in.bellnexxia.net (206.47.229.8) 219.461 ms 239.605 ms 187.514 ms 4 badBellDNS (64.230.241.125) 221.605 ms 209.597 ms 199.655 ms 5 badBellDNS (64.230.242.194) 219.439 ms 227.155 ms 202.135 ms 6 core2-chicago23-pos10-0.in.bellnexxia.net (206.108.103.118) 229.386 ms 249.620 ms 346.174 ms 7 bx1-chicago23-pos11-0.in.bellnexxia.net (206.108.103.125) 228.434 ms 234.041 ms 219.645 ms 8 p13-0.core01.ord01.atlas.cogentco.com (154.54.11.29) 249.438 ms 239.589 ms 199.658 ms 9 p15-0.core02.ord01.atlas.cogentco.com (66.28.4.62) 239.441 ms 249.618 ms 229.679 ms 10 p5-0.core01.yyz01.atlas.cogentco.com (66.28.4.214) 249.409 ms 237.480 ms 231.808 ms 11 g0-1.na01.b011027-0.yyz01.atlas.cogentco.com (66.250.14.230) 251.504 ms 259.618 ms 219.669 ms 12 1572534Ontario.demarc.cogentco.com (38.112.5.166) 239.467 ms 249.593 ms 219.660 ms 13 tor-hespler-360-dslgate.sentex.ca (64.7.143.43) 229.489 ms 249.606 ms 214.908 ms 14 hespler-tor-360-i4.sentex.ca (64.7.143.46) 241.707 ms 229.615 ms 219.680 ms 15 ns.sentex.ca (199.212.134.1) 259.436 ms 239.613 ms 215.514 ms Hops 6 and 8 were coming back as * * * on the traceroute a few hrs ago, but packets were getting to and from me. Hopefully someone from Bell will pipe up on or offlist as to what the problem was / is and if its resolved. Telus is my main transit, and I dont like having to use such a blunt approach to working around this issue :( ---Mike >Eric Krichbaum, Chief Engineer >MCSE, CCNP, CCDP, CCSP, CCIP > >-----Original Message----- >From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of >Mike Tancsa >Sent: Saturday, July 31, 2004 7:52 AM >To: nanog(a)nanog.org >Subject: Next hop issues inside AS577 to AS852? > > >Unfortunately, I am not a direct customer of AS577 otherwise I would >open a ticket with them, but we have a lot of sites inside Bell Canada >that need to reach us. > >Starting suspiciously at maintenance window time, we were seeing >sporadic reachability issues coming at us from Bell. I am pretty sure >its to us, and not the other way around as exiting out, I always prefer >my GT/360 link and depending on the source IP it always works. The path >back to me was via >AS852 (telus) but I had to massively prepend to force it via someone >else to get things working. > >But here are 2 traceroutes from inside AS577 (Bell) back to me > > >Traceroute a) >194# traceroute -n 64.7.153.1 >traceroute to 64.7.153.1 (64.7.153.1), 64 hops max, 44 byte packets > 1 209.226.183.241 266.863 ms 219.712 ms 199.588 ms > 2 206.172.130.250 219.408 ms 219.700 ms 209.619 ms > 3 206.47.229.8 239.433 ms 195.376 ms 193.984 ms > 4 64.230.241.125 229.460 ms 199.675 ms 209.669 ms > 5 64.230.242.150 209.415 ms 189.707 ms 199.627 ms > 6 154.11.3.25 239.440 ms 219.684 ms 208.091 ms > 7 154.11.6.17 241.001 ms 217.379 ms 231.976 ms > 8 64.7.143.44 229.456 ms 199.648 ms 189.635 ms > 9 64.7.143.45 224.784 ms 194.333 ms 189.678 ms 10 64.7.153.1 >229.431 ms 209.654 ms 209.672 ms > >traceroute b) >194# traceroute -n 64.7.153.1 >traceroute to 64.7.153.56 (64.7.153.56), 64 hops max, 44 byte packets > 1 209.226.183.241 278.871 ms 221.986 ms 189.687 ms > 2 206.172.130.250 219.433 ms 229.680 ms 339.650 ms > 3 206.47.229.19 239.447 ms 189.621 ms 195.621 ms > 4 64.230.241.121 223.483 ms 209.663 ms 199.695 ms > 5 64.230.242.97 329.445 ms 209.667 ms 229.666 ms > 6 64.230.242.181 239.463 ms 196.798 ms 192.568 ms > 7 * * * > 8 * * * > > >Every 60 seconds or so the path back to me inside AS577 would change >back and forth between a) and b). I dont know what Hop 7 on b) is. It >could be another peer to AS852 (Telus) or just another internal router >at Bell (AS577). Suffice to say, when taking path b) packets never get >back to me. > >To work around it, I had to prepend out my AS852 link so that Bell comes >back at me via GT/360 or Cogent. > >Anyone from Bell or Telus around to clarify where the problem is? >Sadly, this is a holiday long weekend here in Canada :( The wheels fell >off around 4:30 AM EST. > > ---Mike > > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex Communications, mike(a)sentex.net >Providing Internet since 1994 www.sentex.net >Cambridge, Ontario Canada www.sentex.net/mike

1 0

RE: Next hop issues inside AS577 to AS852?
by Krichbaum, Eric 31 Jul '04

31 Jul '04

If it's every 60 seconds, I'd suspect the BGP timer is the root. They probably forgot to use next-hop self or a static route to a peer. The end result being that the route to the bgp peer is learned via bgp itself... Eric Krichbaum, Chief Engineer MCSE, CCNP, CCDP, CCSP, CCIP -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mike Tancsa Sent: Saturday, July 31, 2004 7:52 AM To: nanog(a)nanog.org Subject: Next hop issues inside AS577 to AS852? Unfortunately, I am not a direct customer of AS577 otherwise I would open a ticket with them, but we have a lot of sites inside Bell Canada that need to reach us. Starting suspiciously at maintenance window time, we were seeing sporadic reachability issues coming at us from Bell. I am pretty sure its to us, and not the other way around as exiting out, I always prefer my GT/360 link and depending on the source IP it always works. The path back to me was via AS852 (telus) but I had to massively prepend to force it via someone else to get things working. But here are 2 traceroutes from inside AS577 (Bell) back to me Traceroute a) 194# traceroute -n 64.7.153.1 traceroute to 64.7.153.1 (64.7.153.1), 64 hops max, 44 byte packets 1 209.226.183.241 266.863 ms 219.712 ms 199.588 ms 2 206.172.130.250 219.408 ms 219.700 ms 209.619 ms 3 206.47.229.8 239.433 ms 195.376 ms 193.984 ms 4 64.230.241.125 229.460 ms 199.675 ms 209.669 ms 5 64.230.242.150 209.415 ms 189.707 ms 199.627 ms 6 154.11.3.25 239.440 ms 219.684 ms 208.091 ms 7 154.11.6.17 241.001 ms 217.379 ms 231.976 ms 8 64.7.143.44 229.456 ms 199.648 ms 189.635 ms 9 64.7.143.45 224.784 ms 194.333 ms 189.678 ms 10 64.7.153.1 229.431 ms 209.654 ms 209.672 ms traceroute b) 194# traceroute -n 64.7.153.1 traceroute to 64.7.153.56 (64.7.153.56), 64 hops max, 44 byte packets 1 209.226.183.241 278.871 ms 221.986 ms 189.687 ms 2 206.172.130.250 219.433 ms 229.680 ms 339.650 ms 3 206.47.229.19 239.447 ms 189.621 ms 195.621 ms 4 64.230.241.121 223.483 ms 209.663 ms 199.695 ms 5 64.230.242.97 329.445 ms 209.667 ms 229.666 ms 6 64.230.242.181 239.463 ms 196.798 ms 192.568 ms 7 * * * 8 * * * Every 60 seconds or so the path back to me inside AS577 would change back and forth between a) and b). I dont know what Hop 7 on b) is. It could be another peer to AS852 (Telus) or just another internal router at Bell (AS577). Suffice to say, when taking path b) packets never get back to me. To work around it, I had to prepend out my AS852 link so that Bell comes back at me via GT/360 or Cogent. Anyone from Bell or Telus around to clarify where the problem is? Sadly, this is a holiday long weekend here in Canada :( The wheels fell off around 4:30 AM EST. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 0

Next hop issues inside AS577 to AS852?
by Mike Tancsa 31 Jul '04

31 Jul '04

Unfortunately, I am not a direct customer of AS577 otherwise I would open a ticket with them, but we have a lot of sites inside Bell Canada that need to reach us. Starting suspiciously at maintenance window time, we were seeing sporadic reachability issues coming at us from Bell. I am pretty sure its to us, and not the other way around as exiting out, I always prefer my GT/360 link and depending on the source IP it always works. The path back to me was via AS852 (telus) but I had to massively prepend to force it via someone else to get things working. But here are 2 traceroutes from inside AS577 (Bell) back to me Traceroute a) 194# traceroute -n 64.7.153.1 traceroute to 64.7.153.1 (64.7.153.1), 64 hops max, 44 byte packets 1 209.226.183.241 266.863 ms 219.712 ms 199.588 ms 2 206.172.130.250 219.408 ms 219.700 ms 209.619 ms 3 206.47.229.8 239.433 ms 195.376 ms 193.984 ms 4 64.230.241.125 229.460 ms 199.675 ms 209.669 ms 5 64.230.242.150 209.415 ms 189.707 ms 199.627 ms 6 154.11.3.25 239.440 ms 219.684 ms 208.091 ms 7 154.11.6.17 241.001 ms 217.379 ms 231.976 ms 8 64.7.143.44 229.456 ms 199.648 ms 189.635 ms 9 64.7.143.45 224.784 ms 194.333 ms 189.678 ms 10 64.7.153.1 229.431 ms 209.654 ms 209.672 ms traceroute b) 194# traceroute -n 64.7.153.1 traceroute to 64.7.153.56 (64.7.153.56), 64 hops max, 44 byte packets 1 209.226.183.241 278.871 ms 221.986 ms 189.687 ms 2 206.172.130.250 219.433 ms 229.680 ms 339.650 ms 3 206.47.229.19 239.447 ms 189.621 ms 195.621 ms 4 64.230.241.121 223.483 ms 209.663 ms 199.695 ms 5 64.230.242.97 329.445 ms 209.667 ms 229.666 ms 6 64.230.242.181 239.463 ms 196.798 ms 192.568 ms 7 * * * 8 * * * Every 60 seconds or so the path back to me inside AS577 would change back and forth between a) and b). I dont know what Hop 7 on b) is. It could be another peer to AS852 (Telus) or just another internal router at Bell (AS577). Suffice to say, when taking path b) packets never get back to me. To work around it, I had to prepend out my AS852 link so that Bell comes back at me via GT/360 or Cogent. Anyone from Bell or Telus around to clarify where the problem is? Sadly, this is a holiday long weekend here in Canada :( The wheels fell off around 4:30 AM EST. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 0

DS-3 extended demarc photos
by Michel Py 30 Jul '04

30 Jul '04

Following photos are from a customer's frac DS-3 (BW capped at 12mbps at the DSU). The ISP is Sprint the LEC is SBC. http://arneill-py.sacramento.ca.us/photos/ds3demarc-lr.jpg This is the actual demarc; this is the back of the NIU, the two black cables in slot 1 on the right go to CPE. There is no jack of course, as the DS-3 uses a pair of 75-ohm cables. This would be a good reason why it is improper to call a NIU a "smart jack", as this semantic transgression only applies to T1 circuits mostly on the east coast. http://arneill-py.sacramento.ca.us/photos/ds3niu-lr.jpg The other side of it. There is only one ds-3 circuit so there is only one card in the NIU chassis. http://arneill-py.sacramento.ca.us/photos/ds3niu2-lr.jpg A wider view where you can see the entire NIU chassis as well as the fiber distribution panel. This is a 23-inch rack, not 19-inch. http://arneill-py.sacramento.ca.us/photos/ds3optical-lr.jpg This is an extended demarc, here you can see the equipment the LEC brought into the customer's data room. They spliced the fiber in the MPOE and installed their own 23-inch rack in the customer's room; this is the preferred way of extending the demarc: move the NIU into customer's territory. The optical platform is a Nortel OPTera Metro 3400. Interesting points: - This is a 1-tenant building, which helps a lot in having the demarc extended. What also helps moving the demarc is a 120 degrees F temperature in the MPOE and 68 degrees in the data room :-D - The LEC brought an OC-12 ring (600 mbps) although the customer is using only 12 mbps; room to grow. - The equipment can't be powered by the span (power-over-fiber, anyone?). The phone company does not trust anyone for power and even though the entire room is on UPS and the customer also has a huge diesel generator, they bring batteries. Note that like most telco gear everything runs on redundant 48VDC power. Michel. Hi-res here: http://arneill-py.sacramento.ca.us/photos/ds3demarc-hr.jpg http://arneill-py.sacramento.ca.us/photos/ds3niu-hr.jpg http://arneill-py.sacramento.ca.us/photos/ds3niu2-hr.jpg http://arneill-py.sacramento.ca.us/photos/ds3optical-hr.jpg

2 1

Faster site: DS-3 extended demarc photos
by Michel Py 30 Jul '04

30 Jul '04

[It was pointed to me that the site was dog slow; indeed you guys are oversubscribing the upstream. I'm moving the jpegs to a bigger pipe; the low-res are already there, hires still copying, please be patient. Sorry for the inconvenience] Following photos are from a customer's frac DS-3 (BW capped at 12mbps at the DSU). The ISP is Sprint the LEC is SBC. http://home.pacbell.net/arn-py/photos/ds3demarc-lr.jpg This is the actual demarc; this is the back of the NIU, the two black cables in slot 1 on the right go to CPE. There is no jack of course, as the DS-3 uses a pair of 75-ohm cables. This would be a good reason why it is improper to call a NIU a "smart jack", as this semantic transgression only applies to T1 circuits mostly on the east coast. http://home.pacbell.net/arn-py/photos/ds3niu-lr.jpg The other side of it. There is only one ds-3 circuit so there is only one card in the NIU chassis. http://home.pacbell.net/arn-py/photos/ds3niu2-lr.jpg A wider view where you can see the entire NIU chassis as well as the fiber distribution panel. This is a 23-inch rack, not 19-inch. http://home.pacbell.net/arn-py/photos/ds3optical-lr.jpg This is an extended demarc, here you can see the equipment the LEC brought into the customer's data room. They spliced the fiber in the MPOE and installed their own 23-inch rack in the customer's room; this is the preferred way of extending the demarc: move the NIU into customer's territory. The optical platform is a Nortel OPTera Metro 3400. Interesting points: - This is a 1-tenant building, which helps a lot in having the demarc extended. What also helps moving the demarc is a 120 degrees F temperature in the MPOE and 68 degrees in the data room :-D - The LEC brought an OC-12 ring (600 mbps) although the customer is using only 12 mbps; room to grow. - The equipment can't be powered by the span (power-over-fiber, anyone?). The phone company does not trust anyone for power and even though the entire room is on UPS and the customer also has a huge diesel generator, they bring batteries. Note that like most telco gear everything runs on redundant 48VDC power. Michel. Hi-res here: http://home.pacbell.net/arn-py/photos/ds3demarc-hr.jpg http://home.pacbell.net/arn-py/photos/ds3niu-hr.jpg http://home.pacbell.net/arn-py/photos/ds3niu2-hr.jpg http://home.pacbell.net/arn-py/photos/ds3optical-hr.jpg

1 0