June 2001 - Test - lists.nanog.org

Outage ?
by Dee McKinney 01 Jun '01

01 Jun '01

Is there some outage on UUNET, L3 or Above.Net right now ?

3 2

mac-address accounting
by Alex Rubenstein 01 Jun '01

01 Jun '01

Perhaps I am using this feature wrong, but I don't think so. This morning, I am trying to get mac-address accounting working on a 7507MX/RSP8/12.0.17S/GEIP+ running ISL, to indentify large peers off an ethernet peering fabric. I've done 'ip accounting mac-address out'. I then wait. Then, I: core1.nyc#sho int g0/0/0 mac-accounting GigabitEthernet0/0/0 to external peers and customers Output (475 free) 0001.64da.bc00(3 ): 2 packets, 179 bytes, last: 3036ms ago 0004.de2b.e41c(9 ): 1 packets, 99 bytes, last: 3036ms ago 00e0.52a6.1f00(11 ): 1 packets, 99 bytes, last: 3036ms ago 0100.0c00.0000(13 ): 57198 packets, 37155973 bytes, last: 388ms ago 0030.7bee.fc54(13 ): 2 packets, 218 bytes, last: 2836ms ago All of the mac-addresses listed in this 'sho' are valid, except for '0100.0c00.0000', which doesn't exist: core1.nyc#sho arp | inc 0100 core1.nyc# All the others are valid, yet they are way, and I mean *way* under the amounts that I know I am sending to that peer. Any clues? I've searched CCO/Bug Toolkit, I don't see anything relevant.

3 2

Location for Henry Hub LA
by Sean Donelan 01 Jun '01

01 Jun '01

Are hubs built where lots of pipes connect, or do people build pipes to places where the largest hubs are? http://www.zdnet.com/intweek/stories/news/0,4164,2767091,00.html

1 0

RE: C&W Peering Problem?
by Karyn Ulriksen 01 Jun '01

01 Jun '01

If anyone else is seeing wierd problems with their GBLX uplinks, please let me know. I stopped announcing routes out them because some of my customers were having a lot of problems such as one IP would go through, but the next consecutive IP couldn't and would get locked up in NYC. Earlier I was seeing the same thing happen in Atlanta. They can't seem to replicate the problem, even though I have sent them several traceroutes where they are all stopping at the same point. I know that stopping my announcements is going to hamper troubleshooting, so if others are having similar problems maybe we can get them to look a little closer. K :: -----Original Message----- :: From: Jason Lewis [mailto:jlewis@jasonlewis.net] :: Sent: Friday, June 01, 2001 1:09 PM :: To: nanog(a)merit.edu :: Subject: RE: C&W Peering Problem? :: :: :: :: Does anyone know who was dropped? I have been having :: strange connectivity :: problems between my network on the C&W network and my :: datacenter which is on :: GlobalCenter's net. No one can tell me what is going on, :: but maybe this has :: something to do with it. :: :: Jason Lewis :: http://www.packetnexus.com :: It's not secure "Because they told me it was secure". The :: people at the :: other end of the link know less about security than you do. :: And that's :: scary. :: :: :: :: -----Original Message----- :: From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On :: Behalf Of :: Simon Lockhart :: Sent: Friday, June 01, 2001 3:03 PM :: To: David Diaz :: Cc: Charles Scott; nanog(a)merit.edu :: Subject: Re: C&W Peering Problem? :: :: :: :: >I was wondering when this issue was going to be brought up. C&W :: >dropped peering with several backbones. I will bet the problems :: >started about a week ago. :: :: Probably because they didn't meet the new C&W peering requirements. :: :: They sent me a link to their peering requirements the other :: week when I :: asked. Basically, to peer you have to have an OC48 backbone with :: redundantly connected nodes in 9 regions of the USA :: (according to their :: definition of regions), peering at 4 diverse locations, with :: a minimum of :: 45Mbit/s of traffic at each location. :: :: Interestingly, C&W's network map doesn't show PoP's in all of their 9 :: regions. :: :: Simon :: -- :: Simon Lockhart | Tel: +44 (0)1737 839676 :: Internet Engineering Manager | Fax: +44 (0)1737 839516 :: BBC Internet Services | Email: :: Simon.Lockhart(a)bbc.co.uk :: Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/

1 0

RE: PSINet Files Chapter 11...
by Los, Ralph 01 Jun '01

01 Jun '01

Hey, OK, I have to say, in their defense...what little technology/engineering they DO have, have been very solid on the T-1 we have from them. I've had only a single problem about a week ago when one of their routers stopped announcing a route Herndon-->Chicago (oops), and we've had that T-1 in for over 7 months now. They are doomed, yes, but they do have a decent engineering staff. Ralph M. Los Asst. Vice-President, Internet Systems and Security EnvestNet Advisory Corp. rlos(a)envestnet.com (312) 827-3945 (direct) (312) 296-9003 (wireless w/voicemail) -----Original Message----- From: up(a)3.am [mailto:up@3.am] Sent: Friday, June 01, 2001 1:01 PM To: nanog(a)merit.edu Subject: Re: PSINet Files Chapter 11... On Fri, 1 Jun 2001, Joe Abley wrote: > > On Fri, Jun 01, 2001 at 05:39:51PM +0100, Stephen J. Wilcox wrote: > > Does anyone know whats happening with PSINet UK? I see only reference to > > USA, Canada and South America.. > > http://www.psinet.com/news/pr/01/june1.html > > PSINet Businesses Not Affected by Actions Nice, objective source :). I do know of someone who has a T1 to them for the past 6 months or so, and are not terribly pleased. It seems that laying off most of your tech staff can in fact, affect business... James Smallacombe PlantageNet, Inc. CEO and Janitor up(a)3.am http://3.am =========================================================================

2 1

Mindspring
by Karyn Ulriksen 01 Jun '01

01 Jun '01

If there is a member of the Mindspring NOC staff listening, can you contact me at (949) 743-2014 at your earliest? Thanx in advance! --------------------------------------------------------------------- Best regards, Karyn Ulriksen Network Operations Manager SiteStream, A VitalStream Company 1 Jenner, Suite 100 Irvine, California 92618 USA Phone: (949) 743-2000 email: kulriksen(a)vitalstream.com URL: http://www.vitalstream.com ===========================================

1 0

PSINet Files Chapter 11...
by Christopher A. Woodfield 01 Jun '01

01 Jun '01

About time! http://news.cnet.com/news/0-1004-200-6155076.html?tag=mn_hd -C --------------------------- Christopher A. Woodfield rekoil(a)semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

5 4

Re: engineering --> ddos and flooding
by Jim Shankland 01 Jun '01

01 Jun '01

Dan Foster <dsf(a)frontiernet.net> writes: > I, too, am much looking forward to the proposed standards to turn this > kind of thing into a non-event. :) Well, look no further than here, for your prayers are answered: On any connection to an end-user, ISPs shall forward only packets with source addresses assigned to that end-user by the ISP. Exceptions can be made for multi-homed end-users: e.g., if an end-user has 1.2.3.0/24 from ISP A, and 5.6.7.0/24 from ISP B, each ISP may choose to accept packets with source addresses from the block assigned by the other ISP, by prior arrangement with the end-user and the other ISP. Now, if you're looking forward to the *implementation* of this proposed standard, you had best be looking through a very strong telescope. It will happen some time after the last open SMTP relay on the Internet is secured :-(. Jim Shankland

1 0

RE: mac-address accounting
by Martin, Christian 01 Jun '01

01 Jun '01

Whoops, mixed this up with ISL. This is ISL group 0. sorry for the spewage.. chris > I think these maybe the Cisco LOOP pulses sent out to detect > link status. > Lemme check in the lab... > > chris > > > -----Original Message----- > > From: Simon Leinen [mailto:simon@limmat.switch.ch] > > Sent: Friday, June 01, 2001 8:47 AM > > To: Alex Rubenstein > > Cc: nanog(a)merit.edu > > Subject: Re: mac-address accounting > > > > > > > > >>>>> "ar" == Alex Rubenstein <alex(a)nac.net> writes: > > > core1.nyc#sho int g0/0/0 mac-accounting > > > GigabitEthernet0/0/0 to external peers and customers > > > Output (475 free) > > [...] > > > 0100.0c00.0000(13 ): 57198 packets, 37155973 bytes, > > last: 388ms ago > > [...] > > > core1.nyc#sho arp | inc 0100 > > > core1.nyc# > > > > 01:00:0c is Cisco's Ethernet multicast address prefix. > > 01:00:0c:00:00:00 looks strange to me. > > > > The cisco-nsp mailing list had a query about this problem: > > > > http://puck.nether.net/lists/cisco-nsp/0318.html > > > > But I don't know whether this has been resolved. If I try outbound > > MAC accounting (usually I only use inbound MAC accounting > at exchange > > points) on a 7206VXR running 12.0(17)S, everything looks fine. > > > > > All the others are valid, yet they are way, and I mean *way* under > > > the amounts that I know I am sending to that peer. > > > > (Maybe your Cisco multicasts all traffic out to the exchange point > > rather than send it to the correct peer - seems much more robust to > > me, although you might end up with heavy packet replication :-) > > -- > > Simon Leinen simon(a)babar.switch.ch > > SWITCH > http://www.switch.ch/misc/leinen/ > > Computers hate being anthropomorphized. >

1 0

RE: mac-address accounting
by Martin, Christian 01 Jun '01

01 Jun '01

I think these maybe the Cisco LOOP pulses sent out to detect link status. Lemme check in the lab... chris > -----Original Message----- > From: Simon Leinen [mailto:simon@limmat.switch.ch] > Sent: Friday, June 01, 2001 8:47 AM > To: Alex Rubenstein > Cc: nanog(a)merit.edu > Subject: Re: mac-address accounting > > > > >>>>> "ar" == Alex Rubenstein <alex(a)nac.net> writes: > > core1.nyc#sho int g0/0/0 mac-accounting > > GigabitEthernet0/0/0 to external peers and customers > > Output (475 free) > [...] > > 0100.0c00.0000(13 ): 57198 packets, 37155973 bytes, > last: 388ms ago > [...] > > core1.nyc#sho arp | inc 0100 > > core1.nyc# > > 01:00:0c is Cisco's Ethernet multicast address prefix. > 01:00:0c:00:00:00 looks strange to me. > > The cisco-nsp mailing list had a query about this problem: > > http://puck.nether.net/lists/cisco-nsp/0318.html > > But I don't know whether this has been resolved. If I try outbound > MAC accounting (usually I only use inbound MAC accounting at exchange > points) on a 7206VXR running 12.0(17)S, everything looks fine. > > > All the others are valid, yet they are way, and I mean *way* under > > the amounts that I know I am sending to that peer. > > (Maybe your Cisco multicasts all traffic out to the exchange point > rather than send it to the correct peer - seems much more robust to > me, although you might end up with heavy packet replication :-) > -- > Simon Leinen simon(a)babar.switch.ch > SWITCH http://www.switch.ch/misc/leinen/ Computers hate being anthropomorphized.

1 0