January 2003 - Test - lists.nanog.org

Weird thing happening
by Dale Levesque 22 Jan '03

22 Jan '03

I have been looking at some stats on a router and I am seeing high utilization between 2 routers, I am seeing utilization on one interface of about 60megs up and down, when the aggregate of all other interfaces is about 13megs up and down. The routers that I am using are a Riverstone 8600 and a Redback sms500, these have been in production for over a year and have not had this problem before. I have made sure that the rate-limiting for icmp,snmp,bgp,ospf and rip are set down to under a meg (for now). These 2 routers are directly connected, and I am not seeing a lot of broadcast traffic. If someone has some in-sight on what is happening please let me know. Also this happened to me yesterday on a different set of routers w/ the same configuration and nothing has been changed. The problem just sort of fixed itself. I would think it's a Dos or DDOS but my inet interfaces are not getting more that like is 13megs up and down. I have done the obvious like reboot, incase and interface is jabbering and cables test out. I would not be so perplexed at this issue if it happened all the time or only happened on one set of routers, but this seems to be an isolated incident but not so isolate because it has happened on another set of routers (one Riverstone and on Redback again). P.S. Speeds and Duplex match. Dale Levesque

2 2

Filters on Class B space; is will /19 pass?
by CSTALLER＠sbcglobal.net 22 Jan '03

22 Jan '03

Fellow Networkers, I have a question regarding current filtering rules/practices on the Internet and prefix length requirements for Class B space. I know that the ARIN space (64/8, 66/8 etc.) must be accepted at /19 or smaller but what about old class Bs? I have a global organization that has a 152.x.x.x /16. I currently I have 2 /19s out of POPs in the US and the aggregate /16 being advertised. I would like to give some of these /19s to other regions such as Europe, Japan, India, ASIA etc. The carrier selection in these regions will be different than what I have in the US. I want to know if anyone is filtering /19s for these networks. Any other information that I should be aware of in this scenario would also be very much appreciated. Thanks in advance. Regards, Curtis Staller CCIE # 9059

1 0

Stumper
by Mark J. Scheller 22 Jan '03

22 Jan '03

I have run into a problem that has me completely stumped, so I'm tossing it out to NANOG for some help. Before I lay out the specifics, I'm not trying to point fingers at any particular ISP or vendor here, but this problem only exhibits itself in very specific configurations. Unfortunately, the configuration is common enough as to get unwanted attention from the higher-ups. Here's the particulars: Users that have Verizon DSL and a Linksys cable/DSL router have difficulties accessing sites on my network -- whether they are trying with http, https, smtp, pop3, ssh, ftp, etc., etc. Oh, but pings seem to be fine. Low latency, no loss. This is true even for access to a server brought up in the DMZ, to keep the firewalls out of the equation. Doing some packet sniffing on the ethernet side of my router, I could see specific http requests never showed up (and the user saw the broken image icon). This was for an mrtg graph page with +/- 30 images. I saw the request for almost all the image files, save for one and the user reported the broken image icon for the one. So this looks and smells like a packet loss issue..... but who/where/how? Taking the Linksys out of the pictures (connecting their PC directly to the Verizon DSL modem) makes the problem go away. These same users report no trouble whatsoever accessing many other common sites across the internet. Here's another interesting data point: when one user runs Morpheus (on any machine in his home network) he then has absolutely no problems accessing servers/services on my network. Other users with Linksys routers and, say cable modem, do not have this problem! So I'm looking for some pointers. What could I have done to my edge router (a Cisco 3640 if that helps any) that would make it drop packets from Verizon DSL customers with Linksys routers so long as they aren't running Morpheus? Mark J. Scheller (scheller(a)u1.net)

12 13

RE: Stumper
by Martin Renschler (EWU) 21 Jan '03

21 Jan '03

Linksys has frequent releases and I had the opportunity to stumble several times into firmware versions where some special applications (e.g. X-Window session over IPSec) wouldn't work. Turned out, they were playing with the MTU. Two releases further on, it would work, then again not etc. I would rather try to solve the problem on the server side (make sure your server sends out unfragmented smaller packets). /Martin <Disclaimer>This is a private statement and does not necessarily reflect the opinion of my employer...</Disclaimer> -----Original Message----- From: jeffrey.arnold [mailto:jba@analogue.net] Sent: Tuesday, January 21, 2003 2:36 PM To: Mark J. Scheller Cc: nanog(a)merit.edu Subject: Re: Stumper On Tue, 21 Jan 2003, Mark J. Scheller wrote: :: Here's the particulars: :: :: Users that have Verizon DSL and a Linksys cable/DSL router have :: difficulties accessing sites on my network -- whether they are trying :: with http, https, smtp, pop3, ssh, ftp, etc., etc. Oh, but pings :: seem to be fine. Low latency, no loss. This is true even for access :: to a server brought up in the DMZ, to keep the firewalls out of the :: equation. :: Have the user update their linksys firmware. I see this problem all the time. Linksys soho gateways are notorious for their early firmware not sending fragments with proper headers. Any acl that does not allow *all frags* by default will deny their packets. There may be other issues as well, but the firmware update tends to fix all of the problems. -jba __ [jba(a)analogue.net] :: analogue.networks.nyc :: http://analogue.net

1 0

Earthquake Mag: 7.6 - 2003/01/21 20:07 - Epicenter: Costa Colima Mexico
by Martin J. Levy 21 Jan '03

21 Jan '03

Found at... http://www.ssn.unam.mx/ ...which is now somewhat overrun! Nothing yet at... http://neic.usgs.gov/neis/current/m_america.html Martin

1 0

RE: Stumper
by Cutler, James R 21 Jan '03

21 Jan '03

MTU on the PC's -----Original Message----- From: Mark J. Scheller [mailto:scheller@u1.net] Sent: 2003-01-21, Tuesday 5:45 PM To: nanog(a)merit.edu Subject: Re: Stumper The Linksys does have an MTU setting, and I've had my users try some lower settings to see if it made any differences. One user set the MTU on the Linksys as low as 1200 with no noticeable improvement. Anything else I should look at? mS (scheller(a)u1.net)

1 0

RE: Stumper
by Ray Burkholder 21 Jan '03

21 Jan '03

This might be an MTU setting issue. If pppoe, then on my Cisco stuff, an MTU of 1492 (I think that is the right value) seemed to clear things up. Ray Burkholder > -----Original Message----- > From: Mark J. Scheller [mailto:scheller@u1.net] > Sent: January 21, 2003 18:26 > To: nanog(a)merit.edu > Subject: Stumper > > > > > I have run into a problem that has me completely stumped, so > I'm tossing it out to NANOG for some help. > > Before I lay out the specifics, I'm not trying to point > fingers at any particular ISP or vendor here, but this > problem only exhibits itself in very specific configurations. > Unfortunately, the configuration is common enough as to get > unwanted attention from the higher-ups. > > Here's the particulars: > > Users that have Verizon DSL and a Linksys cable/DSL router > have difficulties accessing sites on my network -- whether > they are trying with http, https, smtp, pop3, ssh, ftp, etc., > etc. Oh, but pings seem to be fine. Low latency, no loss. > This is true even for access to a server brought up in the > DMZ, to keep the firewalls out of the equation. > > Doing some packet sniffing on the ethernet side of my router, > I could see specific http requests never showed up (and the > user saw the broken image icon). This was for an mrtg graph > page with +/- 30 images. I saw the request for almost all > the image files, save for one and the user reported the > broken image icon for the one. So this looks and smells like > a packet loss issue..... but who/where/how? > > Taking the Linksys out of the pictures (connecting their PC > directly to the Verizon DSL modem) makes the problem go away. > > These same users report no trouble whatsoever accessing many > other common sites across the internet. > > Here's another interesting data point: when one user runs > Morpheus (on any machine in his home network) he then has > absolutely no problems accessing servers/services on my network. > > Other users with Linksys routers and, say cable modem, do not > have this problem! > > So I'm looking for some pointers. What could I have done to > my edge router (a Cisco 3640 if that helps any) that would > make it drop packets from Verizon DSL customers with Linksys > routers so long as they aren't running Morpheus? > > Mark J. Scheller (scheller(a)u1.net) > > >

2 1

The Awards: Best network service provider security architecture
by Sean Donelan 21 Jan '03

21 Jan '03

I've been looking at a lot of different technical security architectures for network providers. Obviously many providers keep their security secret, so they may or may not have a decent security architecture. Nevertheless there is still a lot of good information available from government agency networks, academics and vendors. The best network service provider security architecture document First Place: Information Assurance Technical Framework Second Place: The ESNET unclassified Security Plan Third Place: University of Washington Network Security Credo >From the IATF document http://www.iatf.net/ 5.1 Availability of Backbone Network I would disagree about item #3, IP is a datagram service, and does not protect against delay or packet drops (see item #1). Otherwise this is a decent list of functional security requirements for most Internet backbone providers. Its short, but covers the big items. 1. BNs must provide an agreed level of responsiveness, continuity of service and resistance to accidental or intentional corruption of the communications service. (The agreement is between the owners of the network and the users of the network.) 2. BNs are not required to provide security services of user data (such as confidentiality and integrity)that is the user's responsibility. 3. BNs must protect against the delay, misdelivery, or nondelivery of otherwise adequately protected information. 4. BNs, as a part of the end-to-end information transfer system, must provide the service transparently to the user. 5. As part of the transparency requirement, the BN must operate seamlessly with other backbones and local networks.

2 2

uunet
by Scott Granados 21 Jan '03

21 Jan '03

Is something up on uunet tonight? It looks to me that dns is broken forward and reverse but more likely it looks like a bad bogan fiilter popped up suddenly. I have issue as soon as I leave mfn's network and hit uunet.

14 17

Re: Peering BOF VI at NANOG
by ren 21 Jan '03

21 Jan '03

And for those attending the Gigabit Peering Forum in Los Angeles following NANOG, please drop me a line <ren(a)sbc.com> if you can make the dinner out in Malibu at http://www.gladstones.com on the 12th. Cheers, -ren At 08:16 AM 1/10/2003 -0800, William B. Norton wrote: >Hi all - > >If you are not a Peering Coordinator attending NANOG 27 then you needn't >read any further. > >The 6th Peering BOF at NANOG will be held Monday night and focuses on >helping Peering Coordinators make contact with other Peering Coordinators >using "Peering Personals." We solicit Peering Coordinators (via this >e-mail), asking them to characterize their networks and peering policies >in general ways ("content heavy" or "access (eyeball) -heavy," "Multiple >Points Required" or "Will Peer anywhere," "Peering with Content OK," >etc.). From the answers we will select a set of ISP Peering Coordinators >to present a 2-3 minute description of their network, what they look for >in a peer, etc., allowing the audience to put a face with the name of the >ISP. At the end of the Peering BOF, Peering Coordinators will have time to >speak with Peering Coordinators of ISPs they seek to interconnect with. >The expectation is that these interactions will lead to the Peering >Negotiations stage, the first step towards a more fully meshed and >therefore resilient Internet. > >If you are a Peering Coordinator and wish to participate in this BOF, >please fill out the following form and e-mail it to wbn(a)equinix.com with >Subject: Peering BOF VI . > > >-------------------------------------------------------------------------------- > >Name: >Title: >Company: >AS#: > >Check each that applies: >___ We are an ISP (sell access to the Internet) > -- OR -- >___ We are a Non-ISP (content company, etc.) >___ We are Content-Heavy > -- OR -- >___ We are Access-Heavy >___ Peering with Content Players or Content Heavy ISPs is OK by us >___ We generally require peering in multiple locations >___ We will peer with anyone in any single location >___ We have huge volumes of traffic (lots of users and/or lots of content) > (huge: > 1 Gbps total outbound traffic to peers and transit > providers) >___ We have a global network >___ We require Contracts for Peering >Current Peering Locations: _______________________ >Planned (3-6 mos) Peering Locations: _______________________________ > >See you in Phoenix! > >Bill > >PS - This form is also on the NANOG web page at: >http://www.nanog.org/mtg-0302/norton.html > >--------------------------------------------------------------------------------------------------------------- >William B. Norton <wbn(a)equinix.com> 650.315.8635 >Co-Founder and Chief Technical Liaison Equinix, Inc.

1 0