July 2004 - Test - lists.nanog.org

ad.doubleclick.net missing from DNS?
by Sean Donelan 23 Aug '04

23 Aug '04

The A record for ad.doubleclick.net is missing from DNS. This is causing apparent web page slowdowns when viewing web sites containing ads linked to ad.doubleclick.net

16 18

FW: hey had eric sent you
by Riley, Marty 19 Aug '04

19 Aug '04

I'm running short on theories and options, so I thought I would see if any other ISPs have seen this problem on your network(s). If so, what was the cure? mjr -----Original Message----- The Unknown problem. Symptoms: At random times dialup, dedicated, & internal network users are unable to pass TCP traffic to off network sites. ICMP and UDP appears to be uneffected by the outage which lasts anywhere from 2 to 5 minutes. The problem appears to be wide spread with similar reports from WVNET and other ISPS. nTelos is experiencing a similar problem but we have yet to confirm it is the same. Problem has changed in it's action but remained similar enough to consider it the same problem. Effected Platforms: Windows 2000 Pro, XP Home, XP Pro, & 2003 Server. Uneffected Platforms: Unix, MacOS (?) History: During the week of 2/9/04 the call center started recieving reports of users being unable to connect to sites off the CityNet network. Sites hosted on the internal network are uneffected by the outage. Initally it was thought to be a Internet Explorer problem possably caused by the KB832894 / IE SP1 or other updates but after further investigation it was found that Mozilla users were encountering the same problem. After several days of testing it was determined that during the outage any TCP session started on any port would fail. TCP sessions started before the outage continue to work and show no ill effects from the outage. After logging connection attempts at various intervals on many machines there appears to be no sort of pattern in the outages. Most machines encounter the problem, some more than others and a few do not encounter it at all. The duration and frequency of the outage is very fluid. During an outage, we can verify that the packet does seem to leave and reenter the network: Mar 5 22:28:04 pittpa-chaswv-ds3 17083: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17084: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17085: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17086: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 1 packet Mar 5 22:33:24 pittpa-chaswv-ds3 17089: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 7 packets Mar 5 22:33:24 pittpa-chaswv-ds3 17090: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 17 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17092: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 7 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17093: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 18 packets Mar 5 00:58:30 pittpa-clarwv-ds3 16062: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 1 packet Mar 5 00:58:30 pittpa-clarwv-ds3 16063: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16067: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16068: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16069: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16070: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 1 packet Mar 5 01:03:39 pittpa-clarwv-ds3 16072: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 1 packet Mar 5 01:03:47 pittpa-clarwv-ds3 16073: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 74 packets Mar 5 01:04:13 pittpa-clarwv-ds3 16075: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 72 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16078: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3218) -> 216.41.224.3(80), 4 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16079: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 3 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16080: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3221) -> 216.41.224.3(80), 19 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16081: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 5 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16082: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3229) -> 216.41.224.3(80), 6 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16083: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3236) -> 216.41.224.3(80), 9 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16084: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3233) -> 216.41.224.3(80), 12 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16085: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 21 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16087: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3239), 19 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16088: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 4 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16089: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 2 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16091: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3218), 3 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16092: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3221), 17 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16093: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3229), 5 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16094: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3236), 7 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16096: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3233), 9 packets Network analysis showed significant amounts of spoofed multicast traffic and odd arp traffic. 10:17:16.416222 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 278 10:17:16.421886 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 334 10:17:16.423873 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 262 10:17:16.426948 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 254 10:17:16.432095 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 298 10:17:16.435921 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 274 10:17:16.439959 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 328 10:17:16.445317 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 326 10:17:16.449688 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 330 10:17:16.463537 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 322 Steps were taken to elminiate the spoofed traffic on the routers and access servers in the form of ACLs and filter lists. Neither have eliminiated the problem... but to what extent they might have helped has yet to be determined. The problem is still occuring, for some users the duration of the outage seems to have shortened other users notice no difference. It is not yet known if the filtering on the routers and access servers or the conversion to the 10.x.x.x network has made any difference. We should have a better idea in the upcoming days. What Doesn't help: Removing windows updates. Turning off XP firewall. Searching for malware. (SpyBot-SD, Adaware) Virus scanning (Various softwares) Specifying dns servers. Reinstalling windows.

7 6

Re: Verisign vs. ICANN
by Paul Vixie 17 Aug '04

17 Aug '04

> Anything I/we can do to help the cause? not at the moment. i'm not a defendant, just a named co-conspirator.

15 23

Convention networks and viruses
by Sean Donelan 05 Aug '04

05 Aug '04

As NANOG has experienced during the last several meetings, in any network used by a large number of people, there will be a certain percentage of people which bring infected computers into the network. http://www.nytimes.com/2004/07/29/technology/circuits/29bost.html?pagewante… Wiring a Convention, Version 2004 By SETH SCHIESEL Published: July 29, 2004 [...] But data services have not been as solid. Many news organizations suffered intermittent breakdowns in Internet service, and on Tuesday evening the main press pavilion was offline for about 90 minutes. A spokesman for Verizon said the company deliberately caused the interruption as part of an effort to root out a more deep-seated network problem, which the company said appeared to have been caused by a virus carried by network devices provided by news organizations. In the interim, a handful of data lines provided by other companies, including AT&T, served as a backup.

6 7

Quick question about secondary addresses
by Dan Lockwood 03 Aug '04

03 Aug '04

I'm in a debate with a guy over the use of 'ip address x.x.x.x s.s.s.s secondary' on Cisco gear. I seem to remember reading that the use of secondary addresses is a bad idea, but I can't recall the details of why. Process switched? Can anyone offer a resource or more specific information? Thanks, Dan

5 4

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