- NANOG - lists.nanog.org

Re: Filtering Source Addresses on gw-internet
by C. Jon Larsen 12 Aug '97

12 Aug '97

Thats what I thought at first. But if the permit comes first, then packets with valid source addresses (a.b.c.d) get out because they pass that rule. So a packet built like: Source-> a.b.c.d Dest-> 172.17.0.0 will get out and be passed to the ISP, wasting bandwidth. Thats why I deny them first, and then do the permit later on in the list. > On Tue, 12 Aug 1997, C. Jon Larsen wrote: > > > gw-internet#show access-lists 120 > > Extended IP access list 120 > > deny ip any 10.0.0.0 0.255.255.255 log > > deny ip any 172.16.0.0 0.0.255.255 log > > deny ip any 172.17.0.0 0.0.255.255 log > > deny ip any 192.168.0.0 0.0.255.255 log > > permit ip a.b.c.0 0.0.0.255 any (27429 matches) > > deny ip any any log > > Aren't the first 4 deny's redundant? Using access-lists, I was under the > impression, there was an implicit deny at the end, such that all you'd > need is a single permit line above, and optionally the last deny so you > get to log violations. > > ------------------------------------------------------------------ > Jon Lewis <jlewis(a)fdt.net> | Unsolicited commercial e-mail will > Network Administrator | be proof-read for $199/message. > Florida Digital Turnpike | > ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____ > > Linux. +-------------------+---------------------+ | C. Jon Larsen | jlarsen(a)ajtech.com | | Systems Engineer | Tel: 804.353.2800 | | A&J Technologies | | |-------------------+---------------------| | http://www.ajtech.com | +-----------------------------------------+

2 1

Re: Packet size data
by brett watson 12 Aug '97

12 Aug '97

> Paul G. Donner wrote: > > > What about cflowd? > > cflowd would be really useful if netflow worked properly, which at least > in 11.2(7), it doesn't. The official Cisco response is: > > > Case :H82607 > > > > There are many issues with netflow switch with 11.2(7) > > that are still being addressed. Currently the estimated > > release for a fix is 11.3. Please bare with us while > > this issues are been addressed. what problems are you having? we're running it on a number of exchange point interfaces and we use: peer1.sjc1#sh ver Cisco Internetwork Operating System Software IOS (tm) GS Software (RSP-AJV-M), Version 11.1(11)CA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Synced to mainline version: 11.1(11) it's been very stable (we're running this backbone-wide) and it does support version 5 export. > Are people generally having any more luck with the 11.1CA images? It > would be really nice to get some decent traffic stats. yes, no major problems at all and we've been running it for a few months in most places. -brett

1 0

Re: [nsp] known networks for broadcast ping attacks
by Sharif Torpis 12 Aug '97

12 Aug '97

On Aug 12, 2:42am, Charles Sprickman wrote: > Subject: Re: [nsp] known networks for broadcast ping attacks > > When I type "no ip source route" on a Cisco, what exactly is that doing > for me? Is it just disallowing the router itself to generate > source-routed packets or is it saying sink all source-routed packets? > All this talk of spoofing is getting me a bit confused. What exactly is > the difference between source-routing and spoofing? > > Just trying to understand a bit more, Spoofing is forging a packet's source address. Source routing is including information in the packet that tells the route the packet should take to get to its destination. See ftp://ftp.greatcircle.com/pub/firewalls/FAQ -- Sharif Torpis (storpis(a)pbi.net) Network Engineering Pacific Bell Internet PGP Key at http://www-swiss.ai.mit.edu/~bal/pks-toplev.html

1 0

NANOG 11 Registration
by Pam Ciesla 12 Aug '97

12 Aug '97

NANOG registration fee correction on registration response. Please note the Registration fee for NANOG is $150 with the late fee being $170. Sorry for any confussion. Pam

1 0

Re: [nsp] known networks for broadcast ping attacks
by Jon Lewis 12 Aug '97

12 Aug '97

On Mon, 11 Aug 1997, some anonymous source wrote: > the program you are referring to is smurf.c which i believe was already > discussed on this list. I knew that...but I'd forgotten the name of the program. > the answer to the problem is the fact that there are hard coded > broadcast addresses within the programs. the people who are taking out > servers from irc are the idiots who would not know how to change these. This may be true, but what's to stop the writers of smurf and the other programs from distributing version 2 with all new network addresses? Fixing the 119 networks used to attack FDT will help, but I doubt it will solve the problem. Here's a sorted list of the networks used to attack FDT (pulled from my 1.5mb of tcpdump data which was just a brief sample of the data from our attack Sunday. If any of them belong to you, shame on you. The really interesting ones are the 0.0.0.0 and 255.255.255.255 sources. 18:55:54.836177 0.0.0.0 > 205.229.48.20: icmp: echo reply (ttl 245, id 61586) 18:55:55.816177 255.255.255.255 > 205.229.48.20: icmp: echo reply (ttl 249, id 4 Are these just misconfigured devices on some network from the list below? I suppose for bonus points, I could write a script to get the contact addresses from as many of these as possible and email them a note about how they're being used for network attacks. 0.0.0 4.0.1 4.0.144 4.0.84 38.146.219 128.101.101 128.101.233 128.101.87 128.102.18 128.135.181 128.135.23 128.161.1 128.190.156 129.16.1 129.237.128 129.237.129 129.237.130 129.237.131 129.237.2 129.237.80 129.237.83 129.237.86 129.237.87 129.241.181 129.241.56 129.241.57 129.43.7 130.132.1 130.132.143 130.132.159 131.119.0 131.119.58 134.24.38 134.84.254 136.142.185 136.142.254 137.39.130 137.39.136 137.39.166 137.39.184 144.228.20 144.232.8 160.147.28 163.179.230 165.154.1 166.48.35 170.140.3 170.140.35 170.140.4 170.140.5 170.140.6 192.160.127 192.88.114 192.9.9 193.10.85 198.137.140 198.163.155 198.3.101 198.41.0 198.53.119 198.53.145 198.53.33 198.53.44 198.80.46 199.0.154 199.0.216 199.166.6 199.183.24 199.199.93 199.227.0 199.227.28 199.242.23 204.112.14 204.162.96 204.186.0 204.186.95 204.225.245 204.50.176 204.7.246 204.7.247 204.70.59 204.71.242 205.147.225 205.149.75 205.150.207 205.150.221 205.164.8 205.177.10 205.177.4 205.211.8 205.211.9 205.252.5 205.253.29 206.102.224 206.129.122 206.13.28 206.141.250 206.161.255 206.170.28 206.171.128 206.222.98 206.54.225 206.98.160 207.107.244 207.137.200 207.154.150 207.171.87 207.181.65 207.19.74 207.216.162 207.240.8 207.25.16 207.51.36 207.67.241 207.91.124 209.12.0 209.20.130 209.82.1 255.255.255 ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

4 3

Re: Packet size data
by Paul G. Donner 12 Aug '97

12 Aug '97

What about cflowd? At 11:23 AM 8/11/97 -0700, Justin W. Newton wrote: >Hi, > Does anyone have any /recent/ information on the breakdown of packet sizes >crossing the net right now? I have seen some of the older data, but am >interested in whether or not the percentages are changing over time, and if >so, how. I.e. I could see people moving from interactive services such as >telnet for reading mail and news to going to a client based system would up >the packet sizes. Likewise, the use of some of the streaming video and >audio applications out there might lower it again. In my mind, recent is >anything that has been done in the last 6 months or so. > >************************************************************** >Justin W. Newton voice: +1-415-482-2840 >Senior Network Architect fax: +1-415-482-2844 >PRIORI NETWORKS, INC. http://www.priori.net >Legislative and Policy Director, ISP/C http://www.ispc.org >"The People You Know. The People You Trust." >************************************************************** > >

4 3

Re: Packet size data
by pkavi＠pcmail.casc.com 12 Aug '97

12 Aug '97

Justin, Try the following web pointer maintained by the good folks at the National Lab for Advanced Network Research (NLANR). http://www.nlanr.net/NA/Learn/packetsizes.html Lots of useful recent and historical information there (most recent is a packet distribution recorded as of 6/25/97). The average packet size passed 250 bytes over a year ago, and still seems to be rising although I haven't calculated the exact value. Prabhu Kavi IP Business Marketing Manager Ascend Communications prabhu.kavi(a)ascend.com 508-952-1047 ______________________________ Reply Separator _________________________________ Subject: Packet size data Author: "Justin W. Newton" <justin(a)priori.net> at smtplink Date: 8/11/97 11:23 AM Hi, Does anyone have any /recent/ information on the breakdown of packet sizes crossing the net right now? I have seen some of the older data, but am interested in whether or not the percentages are changing over time, and if so, how. I.e. I could see people moving from interactive services such as telnet for reading mail and news to going to a client based system would up the packet sizes. Likewise, the use of some of the streaming video and audio applications out there might lower it again. In my mind, recent is anything that has been done in the last 6 months or so. ************************************************************** Justin W. Newton voice: +1-415-482-2840 Senior Network Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net Legislative and Policy Director, ISP/C http://www.ispc.org "The People You Know. The People You Trust." **************************************************************

1 0

Re: Backup Power Schemes
by Bill McCauley 12 Aug '97

12 Aug '97

>All share the same hassles to some extent or another. They have to >be run, UNDER LOAD, an hour+ per month. They need the oil changed. >They need clean fuel; #2 Diesel tends to grow weird bugs that clog >the filters. The propane and natural gas can feed modified gasoline >piston engines and turbines. Some Diesels run on a fix of #2 and >gases. [The ultimate example -- a sewage plant will recover sewer >gas and use it w/Diesel. If your userbase is full of BS; or your >tie curls and your boss has 2 horns, you might go this route...] >Natural gas has advantages of no storage hassles; propane does >not go stale. In earthquake country, natural gas is as prone to interruption as any other utility. The utility companies actually have shut off valves in the lines which shut off gas mains when seismic activity over a certain level is detected. Being as how gas lines themselves are prone to shearing fractures in the seismic event itself, natural gas doesn't buy you much as a backup fuel. Unless, you maintain your own tank, which takes you back to most of the problems noted above. Regards, Bill McCauley

5 4

Question ??
by Ignacio Funes Maderey 12 Aug '97

12 Aug '97

I have tried to run mrtg with my router (Cisco 7500). This router has a controller which accept an E1 and divides it as you want. The interfaces that are not directly connected to this controller are OK (for example interfaces such as Serial5/2, Ethernet3/5, etc...), but I have problems with those interfaces such as (Serial5/0:14, Serial5/0:13, etc.). The problems arise since I run cfgmaker public@router_ip, because the ports related with the interfaces directly connected to the controller are wrong. In fact, when I run ./mrtg mrtg.cfg I get the next error messages: CFG Error in "maxbytes[enepacatlan(rdi/e1)]": 256000 must be a Number smaller than maxint ........ What should I do?????? I will appreciate your help. Thank you!!!!!!

2 1

NANOG 11 UPDATE
by Pam Ciesla 12 Aug '97

12 Aug '97

I have had several people register for the NANOG 11 Meeting. I am working with NorthWest & America West on discount and NO Saturday Stay requirements fares. I hope to have both contract numbers later today. SO STAYED TUNED. I will also give a list of alternate hotels within 10 minutes of the meeting site. Thanks xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0