- Test - lists.nanog.org

Clueful T-Mobile contact on the Circuit switched side?
by Aaron D. Osgood 05 Mar '09

05 Mar '09

Please accept my apologies for the waste of space - Will someone from T-Mobile please contact me off list? It seems there is a 10k block of NPA-NXX #'s not in your table. All other rectification contact attempts have failed Thanks! Aaron D. Osgood Streamline Solutions L.L.C P.O. Box 6115 Falmouth, ME 04105 TEL: 207-781-5561 FAX: 207-781-8067 MOBILE: 207-831-5829 PAGE: 2078315829(a)vtext.com AOLIM: OzCom1 ICQ: 206889374 AOsgood(a)Streamline-Solutions.net Blog: http://streamlinesolutionsllc.blogspot.com/ http://www.streamline-solutions.net http://www.WMDaWARe.com Introducing Efficiency to Business since 1986.

2 1

Re: "web problems" "ssl issues"
by Mike Tancsa 05 Mar '09

05 Mar '09

At 02:32 PM 3/5/2009, Christopher Morrow wrote: >Perhaps Thawte/VS is experiencing some LB or load issues? If any verisign folks are around, it would make life a lot easier if an RST was sent instead of timing out like it is/was ---Mike

2 1

"web problems" "ssl issues"
by Mike Tancsa 05 Mar '09

05 Mar '09

Not sure if others are running into this or not, but we had a few vague support calls come in at once about browser 'ssl problems' and some issues with some websites 'taking forever to come up'... It looks like the common problem is bringing up pages that have src="https://siteseal.thawte.com/cgi/server/thawte_seal_generator.exe"> embedded in the web page the end user goes to. Depending on how the page is written, it can seem (to the end user anyways) as if the page is taking for ever to come up. The browser is blocking on talking to the site seal server. e.g. from the first syn, it was almost 25 seconds before the verisign/thawte server responded. 10:37:18.894068 IP 199.212.134.18.65064 > 65.205.248.240.443: S 2515327385:2515327385(0) win 64240 <mss 1460,nop,wscale 0,nop,nop,sackOK> 10:37:21.860159 IP 199.212.134.18.65064 > 65.205.248.240.443: S 2515327385:2515327385(0) win 64240 <mss 1460,nop,wscale 0,nop,nop,sackOK> 10:37:27.794374 IP 199.212.134.18.65064 > 65.205.248.240.443: S 2515327385:2515327385(0) win 64240 <mss 1460,nop,wscale 0,nop,nop,sackOK> 10:37:39.865205 IP 199.212.134.18.62217 > 65.205.248.242.443: S 3464052443:3464052443(0) win 64240 <mss 1460,nop,wscale 0,nop,nop,sackOK> 10:37:42.881109 IP 199.212.134.18.62217 > 65.205.248.242.443: S 3464052443:3464052443(0) win 64240 <mss 1460,nop,wscale 0,nop,nop,sackOK> 10:37:42.961994 IP 65.205.248.242.443 > 199.212.134.18.62217: S 3993252659:3993252659(0) ack 3464052444 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 2> 10:37:42.962311 IP 199.212.134.18.62217 > 65.205.248.242.443: . ack 1 win 64240 10:37:42.962799 IP 199.212.134.18.62217 > 65.205.248.242.443: P 1:103(102) ack 1 win 64240 10:37:43.035470 IP 65.205.248.242.443 > 199.212.134.18.62217: . ack 103 win 1460 10:37:43.037779 IP 65.205.248.242.443 > 199.212.134.18.62217: . 1:1461(1460) ack 103 win 1460 10:37:43.041639 IP 65.205.248.242.443 > 199.212.134.18.62217: . 1461:2921(1460) ack 103 win 1460 10:37:43.042292 IP 199.212.134.18.62217 > 65.205.248.242.443: . ack 2921 win 64240 10:37:43.118203 IP 65.205.248.242.443 > 199.212.134.18.62217: P 2921:3967(1046) ack 103 win 1460 10:37:43.119345 IP 199.212.134.18.62217 > 65.205.248.242.443: P 103:285(182) ack 3967 win 63194 network connectivity to 65.205.248.0/24 is fine for me. It looks to be at the application layer at verisign ? Just a heads up in case your helpdesk runs into this issue as well as it seems to be a rather obscure problem that sent us on a wild goose chase at first. Some browsers deal with it differently. on IE, most of the page does not display until the seal comes up or times out. ---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

3 2

Re: SNMP and syslog forwarders
by Martin Mersberger 05 Mar '09

05 Mar '09

Hi Sam, For SNMP Traps, we were using 'Concord TrapExploder'. I'm not sure, if this is still named that way - it's now more than 1.5 years ago, I'd been involved in that project. As we had configured all network elements to send the Traps to both TrapExploders, we had to de-duplicate the traps on the EventManagement piece of our NMS platform. But that's been an easy one... For Syslog, we had used syslog-ng and it was just running like a charm.. .. just my 2ct's regards Martin > It's looking like running all of our traps and syslog through a couple > of relay devices (and then onwards to the various NMS's) would be quite > a win for us. > > These relay devices just need to be "dumb" forwarders (we don't require > any filtering or storing, just reflection), but we need an HA pair > (across two sites) without creating duplicates. > > I have the coding skills to make this myself, but as coding skills come > and go in our network team, we are looking for a commerical product so > it will continnue to work after I get: hit by a bus / amnesia / visions > > of grandeur. > > Any recommendations / experience? This needs to scale to ~1,500 devices. > > Thanks, > > Sam

1 0

SNMP and syslog forwarders
by Sam Stickland 04 Mar '09

04 Mar '09

Hi, It's looking like running all of our traps and syslog through a couple of relay devices (and then onwards to the various NMS's) would be quite a win for us. These relay devices just need to be "dumb" forwarders (we don't require any filtering or storing, just reflection), but we need an HA pair (across two sites) without creating duplicates. I have the coding skills to make this myself, but as coding skills come and go in our network team, we are looking for a commerical product so it will continnue to work after I get: hit by a bus / amnesia / visions of grandeur. Any recommendations / experience? This needs to scale to ~1,500 devices. Thanks, Sam

4 3

Re: MAC address confusion
by R. Kevin Oberman 04 Mar '09

04 Mar '09

Sorry fot the top-post, but my Treo makes it almost impossible to do otherwise. The protocols using these reserved, local addresses all use them to embed the network layer address. AA addresses are used by DECnet and kin while 02 is for XNS, I seem to recall. As long as the only addresses used in these spaces are thse asigned by those protocols and they use peoperly assigned network layer addresses, ther will never be a conflict. That is the point in0the registration...marking them as reserved for the protocols in question and not to be used for anything else. Sent from my Treo: R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) E. O. Lawrence Berkeley National Laboratory (LBNL) oberman(a)es.net +1 510-486-8634 -----Original Message----- From: Saku Ytti <saku+nanog(a)ytti.fi> Date: Wednesday, Mar 4, 2009 12:49 am Subject: Re: MAC address confusion To: nanog(a)nanog.org On (2009-03-03 13:50 -0800), Kevin Oberman wrote: > This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. Why would they need to have same L3 address? The way I see it, only thing that matters is, if or not, the addresses might speak ethernetII. If your ethernetII switch sees your local 02 address and one of the addresses below and they collide, the switch will keep relearning the address behind two ports. Unless of course it is guaranteed, that none of these addresses will ever appear as BIA in ethernetII capable NIC. 02-07-01 (hex) RACAL-DATACOM 02-1C-7C (hex) PERQ SYSTEMS CORPORATION 02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD. 02-60-8C (hex) 3COM CORPORATION 02-70-01 (hex) RACAL-DATACOM 02-70-B0 (hex) M/A-COM INC. COMPANIES 02-70-B3 (hex) DATA RECALL LTD 02-9D-8E (hex) CARDIAC RECORDERS INC. 02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO) 02-BB-01 (hex) OCTOTHORPE CORP. 02-C0-8C (hex) 3COM CORPORATION 02-CF-1C (hex) COMMUNICATION MACHINERY CORP. 02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION -- ++ytti

1 0

Yahoo postmaster?
by Chris Adams 04 Mar '09

04 Mar '09

Can a Yahoo postmaster ping me off list? I've got a couple of servers that appear to be mis-categorized. -- Chris Adams <cmadams(a)hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

3 3

MAC address confusion
by Saku Ytti 04 Mar '09

04 Mar '09

Whic one of these, is locally assigned unicast MAC address, when talking about output format CSCO uses? 4000.0000.0000 (Local IXPs choice) 0200.0000.0000 (My money is here) http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM A0-6A-00 (hex) Verilink Corporation In either case two of the lowest or highest bits of 1st octet seems to be happily used to assign addresses. What am I missing here? -- ++ytti

4 7

Cox Abuse Contact
by Blake Pfankuch 04 Mar '09

04 Mar '09

Can someone from the Cox Cable Abuse department contact me off list in regards to an account in Rhode Island? Blake Pfankuch Network Engineer [cid:image001.gif@01C99C47.5ECB1B70]

1 0

Re: GBLX I2 connection issues?
by Scott Weeks 03 Mar '09

03 Mar '09

No. For example: /usr/local/bin/tcptraceroute 208.39.178.1 <snip> 9 208.173.53.138 54.790 ms 55.312 ms 55.207 ms 10 pos-0-9-0-0-cr01.losangeles.ca.ibone.comcast.net (68.86.85.186) 57.883 ms 57.948 ms 57.676 ms 11 pos-0-14-0-0-cr01.dallas.tx.ibone.comcast.net (68.86.85.142) 93.850 ms 94.420 ms 93.846 ms 12 pos-0-14-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.154) 112.976 ms 113.173 ms 113.260 ms 13 pos-0-11-0-0-cr01.mclean.va.ibone.comcast.net (68.86.85.242) 129.032 ms 129.078 ms 128.753 ms 14 pos-0-0-0-0-pe01.ashburn.va.ibone.comcast.net (68.86.86.26) 129.215 ms 129.142 ms 129.110 ms 15 ccs-pe01.ashburn.va.ibone.comcast.net (68.86.92.198) 136.825 ms 136.564 ms 136.844 ms 16 ge-11-0-cr01.phl.comcastcommercial.net (208.39.157.41) 142.110 ms 142.837 ms 142.407 ms 17 ge-3-1-br01.phl.comcastcommercial.net (208.39.156.2) 141.837 ms 142.068 ms 142.010 ms 18 208.39.178.1 [closed] 145.743 ms 145.467 ms 145.180 ms --- dnightin(a)wellesley.edu wrote: From: Don Nightingale <dnightin(a)wellesley.edu> To: "nanog(a)nanog.org" <nanog(a)nanog.org> Subject: GBLX I2 connection issues? Date: Tue, 03 Mar 2009 15:37:21 -0500 We're seeing packet loss getting to 208.39.178.0/23 over I2, anyone else seeing any issues? 1 * 207.210.142.2 212 msec 236 msec 2 ge5-3-0-1000M.ar1.SJC2.gblx.net (64.208.110.25) 4 msec 4 msec 4 msec 3 te9-3-10G.ar5.NYC1.gblx.net (67.16.131.109) 80 msec 208 msec 8 msec 4 * * * 5 * * * 6 * * * 7 * * * 8 -- Don Nightingale Systems and Networks Manager Wellesley College 781-283-3271

1 0