- Test - lists.nanog.org

Netflow IP accounting and IP protocol numbers
by steven hessing 25 Nov '97

25 Nov '97

The other day we started using Cisco netflow accounting software together with IP flow export feature of recent Cisco IOS versions. What we found was that although we put a lot of protocols in the nfknown.protocols file of the accounting software (everywthing we could find in the /etc/services file of Solaris and Linux), there is still a lot of traffic under TCP-Other and UDP-Other. This indicated that traffic is going over our network using ports that the software doesn't know about. This could for example be Real-audio, Cuseeme, Pointcast, Backweb etc traffic. Unfortunately, I don't have a list of these newer protocols together with their port numbers. Has anyone compiled such a list? There's the Assigned numbers RFC but the last version of it is RFC 1700 of October 1994. -- Steven

5 4

OPS: SECURITY new packet of death
by Sean Donelan 25 Nov '97

25 Nov '97

Good morning America (and good day or night to the rest of the world), I hope you got a good nights sleep. There is a new packet of death circulating. Sending a SYN packet with the source and destination address & port set to the same value causes some systems to lockup. One such system seems to include several versions of Cisco IOS. Details on Bugtraq. Have a nice day. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

12 11

RE: Eugene Kashpureff's Defense Fund
by Jim Browning 25 Nov '97

25 Nov '97

ROFL.. ---------- From: Bob Allisat [SMTP:tor@wtv.net] Sent: Monday, November 24, 1997 12:22 PM > Eugene Kashpureff's Defense Fund

1 0

RE: Sprint problems
by Michael Bostardi 24 Nov '97

24 Nov '97

For $0.10 a minute you could call their NOC. > -----Original Message----- > From: Dan Hubbard [SMTP:dhubbard@thepalace.com] > Sent: Monday, November 24, 1997 9:24 PM > To: nanog(a)merit.edu > Subject: Sprint problems > > We are having a great deal of packet loss to Sprint ? Any details... > --------------- > Dan Hubbard > The Palace Inc.

1 0

Re: Sprint problems
by cdavisso＠teir.com 24 Nov '97

24 Nov '97

According to the Sprint Technical number, they're having a "network event" in the Washington DC area. Don't have any other details yet. We do have an open trouble ticket. Chuck Davisson TEIR -- ================================= I've no doubt the devil grins, As seas of ink I spatter. Ye gods forgive my literary sins, The other kind don't matter. - Robert W. Service

1 0

Sprint problems
by Dan Hubbard 24 Nov '97

24 Nov '97

We are having a great deal of packet loss to Sprint ? Any details... --------------- Dan Hubbard The Palace Inc.

1 0

Switch-Based Interconnects
by Tim Salo 24 Nov '97

24 Nov '97

Does anyone have any analytic results about the amount of buffering required in 100 Mbps or gigabit Ethernet switches used for [wide-area] interconnects? For the various layer-three switches? -tjs

1 0

ATM Switches (was: New MAE-EAST)
by Tim Salo 24 Nov '97

24 Nov '97

A long time ago, Kent wrote: > Date: Sat, 08 Nov 1997 06:58:56 -0800 > From: "Kent W. England" <kwe(a)6SigmaNets.com> > Subject: Re: New MAE-EAST > [...] > ... Find a co-lo where you can > cross-connect without being robbed or build your own NAP, just don't use > DEC-designed Gigaswitches and FDDI. Use full duplex 100 Mbps Ethernet > switch or find an old Fore switch cheap. Building an interconnect around a first-generation ATM switch is a lot like building an interconnect around a first-generation router, (think Cisco AGS or even Bridge GS/3). The first FORE switch (the ASX-100), as well as its contemporaries, didn't have the buffering necessary to adequately support wide-area traffic. I suggest that, if you intend to use ATM as a medium, you look at the current FORE switches, perhaps the ASX-1000. Such a switch would provide the buffering necessary for wide-area connections as well as support for newer ATM features. An ATM switch might also allow you to connect it directly to wide-area ATM services. This might, depending on your particular circumstances, allow some interesting configurations, such as a wide-area interconnect. Also, I suggest: o Don't use ATM DSUs, (ADSUs). They simply weren't designed for the sort of load likely to be experienced at a successful interconnect. o If you are the first to construct an interconnect with a particular class of equipment or a specific product, try to test the configuration under load before committing to production. - Believe your test results. If things don't work while testing, they probably won't work in production. -tjs

1 0

Re: Land and Cisco question
by Sean Donelan 24 Nov '97

24 Nov '97

>I'm sorry - but the Right Thing (tm) to do is to >ingress filter, as I have already evangelized. > >Like it or not. Paul is correct. Various vendors will update their systems to handle this packet of death, but someone will discover another packet of death. Anti-spoofing filters don't prevent them, but they do act as fire stops to slow their spread. Topology may prevent you from creating perfect screens, but even with the 80/20 rule, anti-spoofing would impede many DOS attacks; or speed up the tracking of the source. Just because there are good reasons for not doing it in the 20%, you should still try to do it for the 80% it would help. Single-homed networks, even broad networks like MCI's backbone, rarely have legitimate packets with their source address originated by hosts not directly on those networks and routed through parts unknown. As an added bonus, anti-spoofing filters also block several cases of people pointing default at your network. Think about it. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Land and Cisco question
by owen＠DeLong.SJ.CA.US 24 Nov '97

24 Nov '97

> Randy Bush said: > > for each interface on a router > > block tcp which is both to and from that interface > > I don't think that's sufficient. What about spoofed packets arriving via > interface A, with IP source and destination both set to the address of > interface B? > > --apb (Alan Barrett) > > If you do it with an access-list in then it doesn't matter. Even a spoofed packet will be blocked prior to arriving where it can do harm. Owen

2 1