- Test - lists.nanog.org

Re: smurf
by Joe Provo - Network Architect 09 Dec '97

09 Dec '97

> ==>Dear vendors: > ==> > ==> GIVE A KNOB TO DO THIS, ACROSS THE BOARD, IN YOUR GEAR. > > It's a requirement per the RFC: [snip] You, I and many->most of the folks here know it, but as your paper notes that Bay isn't following 1812 yet, I'm noting Ascend doesn't (or isn't for all their platforms/wasn't comprehending when we were trying to get good answers from them). I don't know if the FORE code that does the Right Thing is in production yet. Joe

1 0

Re: smurf
by Joe Provo - Network Architect 08 Dec '97

08 Dec '97

[since Wayne passed the soapbox, I'll just borrow it for a few. NB: The following comments are my own, or belong to the last pot of coffee. Nothing at all to do with the source organization, machines, etc; ldisclaim, disavow, etc etc.] > For anyone who has not, PLEASE DISABLE DIRECTED BROADCASTS! [snip] Dear vendors: GIVE A KNOB TO DO THIS, ACROSS THE BOARD, IN YOUR GEAR. I seems like the kicking and shoving needs to start, so: Hats off to Cisco and OpenRoute/Proteon for having simple knobs that even customers can be told how to activate in their gear. Kudos to FORE for at least having the presence of mind to understand the problem and supply code the supports a knob to shut off the behavior. Brickbats to Ascend for supplying that answer "set up filters against the broadcast address". Anyone this side of catatonia can produce that answer; let's have a knob to shut it off either across the board or interface by interface. And no, just doing it on current-high-end-box doesn't cut it; supply a patch to the large installed base of CPE (pipe50es, etc) or else you haven't eliminated the issue for the majority of LAN interfaces attached to your product line. Joe "speaking for myself" Provo -30-

2 1

smurf
by Wayne Bouchard 08 Dec '97

08 Dec '97

Okay, so I'm now blocking 45 megs of icmp echo-reply packets at my borders.. At one point, this was 80,000 packets/sec. (No, I'm not exagerating.) <SoapBox> For anyone who has not, PLEASE DISABLE DIRECTED BROADCASTS! Tell a friend.. If you sell routers to clients and/or you configure them, include that in your default configuration. Encourage people to filter inbound ICMP where possible.. Do whatever it takes to work with your customer/peers to put a stop to this kind of abuse. Of all the attacks to date, this (and the recent land.c which is a different issue together) threaten the most disruption of internet services. With ISDN and DSL, users have the bandwidth necessary to generate even more dangerous levels of traffic. If you don't think this issue affects you, it does. If you're not a target, your probably being used as a source. </SoapBox> We thank you for your support.. ---------------------------------------------------------------------- Wayne Bouchard GlobalCenter web(a)primenet.com Primenet Network Operations Internet Solutions for (602) 416-6422 800-373-2499 x6422 Growing Businesses FAX: (602) 416-9422 http://www.primenet.com http://www.globalcenter.net ----------------------------------------------------------------------

10 10

Network Monitoring Tool
by Jared Mauch 08 Dec '97

08 Dec '97

I would like to announce the availability of my network monitoring tool version 0.78 to the public. This program does various great things that Rover and other such freeware unix tools should have implemented a long time ago :) It does monitoring of the following services: icmp, http, smtp, nntp, pop3, imap, and various udp and tcp port monitoring. (More test types are currently under development, such as nameservers, snmp tests, radius and xtacacs). The big advantage over most of the other tools out there is the ability to build network dependencies. Included is a brief config file example that you may want to use within your network: monitoring-eth-router.your.net ping localnet my@pager { core.router.my.net ping core2.router my@pager { mae-east.router.my.net ping mae-east my@pager mae-west.router.my.net ping mae-west my@pager } } There is various client software that has been built for talking to the monitoring server, include a java, (n)curses, and python clients that distribute with the program. I'm happy to take feature requests. If you have the time, and the need, could you please test and give your feedback to me? I think this will help make network operations go a little bit better for some of the folks out there, both large and small. I'm currently working on the next version that has major code revisions to speed up the checks further, but it currently beats out most of the monitoring tools that folks are using. You can obtain the program from: ftp://puck.nether.net/pub/jared/sysmon-0.78.tar.gz It should build on almost any UNIX machine out there, if you encounter problems, please let me know. I will take no more of your time, please direct comments, feedback and flames directly to me, i've set the reply-to: accordingly. - Jared

1 0

RE: Operational problem: active bridge between MAE-WEST and PAIX
by marki＠valuserve.com 08 Dec '97

08 Dec '97

My apologies to those effected, The problem has been fixed, and the offending port has been executed. Mark Ishikawa

1 0

Operational problem: active bridge between MAE-WEST and PAIX
by dlr＠bungi.com 08 Dec '97

08 Dec '97

While trying to track down a strange and unusual problem tonight, I discovered that someone is running a switch or a bridge between mae-west and the Palo Alto Internet Exchange. After adding an ip address 198.32.176.222 255.255.255.0 sec to my mae-west router, I was able to: mae-west#ping 198.32.176.252 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 198.32.176.252, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/109/524 ms mae-west#sh ip arp 198.32.176.252 Protocol Address Age (min) Hardware Addr Type Interface Internet 198.32.176.252 0 0800.2bb6.b8f7 SNAP Fddi4/1/0 mae-west# If you are trying to track down unusual problems between mae-west and PAIX, you might want to check this out. Of course, IMHO, the bridge should be taken down or severly filtered. On the other hand - it does mean that everyone only at mae-west should immediately apply for PAIX IP addresses :-) -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: CIDR FAQ pointer invalid (?)
by Hank Nussbacher 06 Dec '97

06 Dec '97

At 10:21 AM 12/6/97 -0500, Paul Ferguson wrote: >Updating some outdated URL's and just realized that: > > http://www.rain.net/faqs/cidr.faq.html > >no longer works. What is the correct URL? The most up to date is: http://www.ibm.net.il/~hank/cidr.html -Hank > >- paul > >ps. The same URL is being used on the NANOG homepage. > >

1 0

CIDR FAQ pointer invalid (?)
by Paul Ferguson 06 Dec '97

06 Dec '97

Updating some outdated URL's and just realized that: http://www.rain.net/faqs/cidr.faq.html no longer works. What is the correct URL? - paul ps. The same URL is being used on the NANOG homepage.

1 0

Problems with specific routing policies for each exchange point
by mark＠exodus.net 05 Dec '97

05 Dec '97

I ran in to a little problem yesterday with my peering sessions wih the various route servers around the country. The problem was that I was not receiving routes from particular ASNs anymore. With a little help from Jake at Merit we were able to pinpoint the problem in my rs-in configuration. It seems that I was importing two different AS macros that each referenced the other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser on the route server which in turn nullified my routing policy. I was wondering if anyone else had come across this little phenomenon. Mark Tripod Senior Backbone Engineer Exodus Communications

9 16

The Cidr Report
by Tony Bates 05 Dec '97

05 Dec '97

1 0