- Test - lists.nanog.org

PPP over Ethernet?
by Zachary DeAquila 14 Jun '98

14 Jun '98

Anyone ever heard anything about PPP over Ethernet? Is there an encapsulation standard for it? --Zachary

15 17

Re: So... what's the best routing solution for..
by Tony Li 14 Jun '98

14 Jun '98

sjsobol(a)shell.nacs.net (Steve Sobol) writes: > > He said this was an ethernet handoff from the isp; they are not simply > > going to plug him into a switch; he will most likely get a port on a > > cisco; they should be able to apply policies for him.. no? > > True. So do you _really_ want someone else configuring your packet filter? I didn't think so. > > I don't see why he even needs a router, unless there is a lack of a trust > > of the upstream's ability to filter.. Or if you know beforehand they will > > not? > > I don't know that I necessarily need a router. :> D'accord. But you probably do want a packet filter/firewall/L3 protection of some flavor. > Incidentally, if this is better discussed on another list, > I'll go subscribe to it and raise the question there... Hell no, this is operational content. ;-) Tony

2 1

Strangeness in the global routing tree?
by Alex Rubenstein 13 Jun '98

13 Jun '98

This morning, I was awaken by one of my NOC guys because a customer of mine BGP was flapping. The scoop: A cisco 7206, with three full views, 128 megs of Ram, 11.1.19(CA). I have four customers off of this router on an ethernet who are running BGP to me. I am sending them full views. Two are ciscos, one is a Bay, and the other is a PC running GATED. This morning, around 8 AM, the Gated box started going crazy. The 7206 would start the BGP session, it would feed the Gated box almost all the routes, then the session would unexpectedly just die, on the cisco side it went 'idle', on the Gated side, he got an 'unexpected EOF'. So, I thought maybe he was running out of memory; so, I filtered things so he would only get about 40 routes. It worked fine. I started adding stuff (via filter-list and as-path access-lists), and worked all they way up to 50,000 routes, and it is still ok. But, if I take the filter off and feed him full routes, it breaks again. Wierd. Remember, on the same router, on the same BGP process, I am peering with two ciscos and a Bay with no problems. Any thoughts? Anyone else see the same strange behavior from a GateD box this morning? Maybe it's y2k related, or has to do with el nino... :-) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

2 1

Re: smurf amp nets
by shields＠crosslink.net 13 Jun '98

13 Jun '98

In article <Pine.LNX.3.95.980613100514.4911B-100000(a)uplift.sparta.lu.se>, Mikael Abrahamsson <swmike(a)swm.pp.se> wrote: > I think the only way to solve this more permanently is to remove the > response of ICMP data to broadcast adresses in the OS. Is anyone > preassuring for this to happen? Is there a list of OS that actually does > respond to ICMP to broadcast adresses? Most of them do, because otherwise people complain about simpleminded network autodiscovery tools not working. That's the same complaint people made about directed broadcasts so I think that after a few people suffer from cracked machines launching attacks at undirected broadcasts, those will get turned off too. Here is a trivial patch against Linux 2.0.34. And disable your echo/chargen ports. UDP works as well as ICMP. Index: kernel-source/net/ipv4/icmp.c diff -u kernel-source/net/ipv4/icmp.c:1.1.1.2 kernel-source/net/ipv4/icmp.c:1.2 --- kernel-source/net/ipv4/icmp.c:1.1.1.2 Thu Jun 11 01:18:53 1998 +++ kernel-source/net/ipv4/icmp.c Thu Jun 11 04:05:46 1998 @@ -1108,20 +1108,13 @@ /* * RFC 1122: 3.2.2.6 An ICMP_ECHO to broadcast MAY be silently ignored (we don't as it is used * by some network mapping tools). + * [But I've decided to ignore it anyway. --Shields 1997-07-22] * RFC 1122: 3.2.2.8 An ICMP_TIMESTAMP MAY be silently discarded if to broadcast/multicast. */ if (icmph->type != ICMP_ECHO) - { icmp_statistics.IcmpInErrors++; - kfree_skb(skb, FREE_READ); - return(0); - } - /* - * Reply the multicast/broadcast using a legal - * interface - in this case the device we got - * it from. - */ - daddr=dev->pa_addr; + kfree_skb(skb, FREE_READ); + return(0); } len-=sizeof(struct icmphdr); -- Shields, CrossLink.

1 0

smurf amp nets
by Jon Lewis 13 Jun '98

13 Jun '98

I just recorded 4.5mb of a smurf attack directed at one of my servers. Here's a list of the networks used as amplifiers and the number of different hosts responding from each network. If you received this message and did not get it via the NANOG mailing list (or received multiple copies of this message), then you are listed with an IP registry as being the maintainer of one of the networks near the top of the list below. If you do no know what smurf is or why being a smurf amplifier is bad, please read http://www.quadrunner.com/~chuegen/smurf.txt. By continuing to be a smurf amplifier, you will risk portions of the Internet cutting off connectivity to your network, and may provoke attacks on your networks or hosts. 207.164.49: 87 205.68.128: 80 131.179.96: 63 206.39.81: 58 207.137.77: 46 207.123.94: 41 208.133.51: 33 207.141.205: 31 205.225.15: 29 206.39.75: 27 193.118.192: 26 192.208.46: 24 204.163.200: 23 207.102.100: 23 194.153.0: 23 194.72.186: 19 194.205.4: 19 195.224.29: 19 194.193.110: 19 192.86.78: 18 207.141.179: 17 207.204.135: 17 164.38.16: 17 193.117.190: 16 192.149.109: 16 207.87.98: 16 194.238.48: 16 204.215.181: 15 195.216.16: 15 205.225.30: 15 209.36.0: 14 195.188.206: 14 199.95.207: 14 144.85.10: 14 193.164.172: 14 198.82.184: 13 198.76.172: 13 207.243.60: 13 204.249.16: 12 140.222.56: 12 195.166.32: 12 129.210.8: 12 205.184.109: 12 207.243.45: 12 205.226.153: 12 128.11.27: 12 194.73.141: 12 206.28.165: 11 207.141.24: 11 193.115.32: 10 207.243.15: 10 204.164.100: 10 204.97.148: 10 204.107.162: 10 198.76.181: 10 194.88.77: 10 128.11.24: 10 199.242.245: 9 206.243.214: 9 198.112.240: 9 205.232.33: 9 207.233.86: 9 204.107.163: 9 206.39.78: 8 206.39.79: 8 206.119.82: 8 208.133.50: 8 140.89.18: 7 204.250.54: 7 206.39.82: 7 207.141.96: 7 192.65.144: 7 207.60.44: 7 205.225.27: 7 193.123.31: 7 164.38.19: 7 140.89.16: 6 164.67.128: 6 206.105.235: 6 206.105.236: 6 206.105.238: 6 205.181.168: 6 207.121.155: 6 129.210.11: 6 4.1.107: 6 192.216.247: 6 194.72.123: 6 207.121.91: 6 205.181.101: 6 207.243.240: 6 205.244.34: 6 207.236.112: 6 205.227.44: 6 207.87.20: 5 206.105.239: 5 207.28.162: 5 206.149.201: 5 199.240.110: 5 207.28.174: 5 166.77.235: 5 205.225.26: 5 206.119.169: 5 199.251.133: 5 207.120.147: 5 128.173.100: 4 206.39.72: 4 206.39.76: 4 207.28.163: 4 206.149.204: 4 162.127.7: 4 204.119.165: 4 207.0.88: 4 207.0.91: 4 205.218.18: 4 164.38.17: 4 164.38.18: 4 206.39.93: 3 206.149.228: 3 206.149.229: 3 195.216.24: 3 205.225.28: 3 207.233.88: 3 193.164.160: 3 205.226.152: 3 194.88.75: 3 209.178.0: 2 207.244.95: 2 194.126.66: 2 206.39.77: 2 206.34.74: 2 207.155.151: 2 206.149.208: 2 206.34.80: 2 172.16.99: 2 164.67.160: 2 206.34.91: 2 154.32.18: 2 204.167.134: 2 4.1.25: 2 12.127.147: 2 131.192.100: 2 207.21.26: 2 206.85.107: 2 206.250.100: 2 207.242.71: 2 209.155.16: 2 206.34.100: 2 206.34.101: 2 194.51.203: 2 195.92.210: 2 144.85.14: 2 193.164.161: 2 205.244.33: 2 195.200.12: 2 207.122.94: 2 207.240.2: 2 206.34.46: 1 195.50.72: 1 193.115.33: 1 128.97.251: 1 206.105.227: 1 164.38.32: 1 4.1.1: 1 206.105.231: 1 194.247.64: 1 206.39.70: 1 199.93.199: 1 144.85.200: 1 194.154.13: 1 137.52.109: 1 165.113.56: 1 144.85.207: 1 206.34.78: 1 206.98.32: 1 12.127.114: 1 128.97.46: 1 205.125.0: 1 157.130.0: 1 195.5.1: 1 206.39.92: 1 206.39.94: 1 206.39.98: 1 204.70.226: 1 12.127.209: 1 205.68.129: 1 205.202.164: 1 206.34.95: 1 204.59.1: 1 195.15.6: 1 195.89.160: 1 207.60.45: 1 195.89.163: 1 193.118.193: 1 204.70.164: 1 128.97.79: 1 4.0.128: 1 154.32.26: 1 195.99.124: 1 192.221.137: 1 4.0.63: 1 4.0.64: 1 12.127.232: 1 194.177.180: 1 144.85.1: 1 4.0.132: 1 194.80.132: 1 4.0.135: 1 206.41.10: 1 166.48.6: 1 137.39.135: 1 207.123.112: 1 196.7.77: 1 131.32.39: 1 209.4.206: 1 166.77.10: 1 204.119.168: 1 194.74.17: 1 207.165.237: 1 255.255.255: 1 12.127.163: 1 207.87.97: 1 4.0.144: 1 12.127.37: 1 149.142.122: 1 207.140.148: 1 4.0.80: 1 196.7.126: 1 192.216.246: 1 195.166.6: 1 207.0.84: 1 131.192.31: 1 131.192.32: 1 12.127.177: 1 207.233.85: 1 12.127.179: 1 204.97.134: 1 149.142.76: 1 169.139.60: 1 193.36.37: 1 4.1.66: 1 207.0.90: 1 206.149.195: 1 12.127.180: 1 207.217.50: 1 207.123.29: 1 4.0.240: 1 4.0.160: 1 194.72.131: 1 195.92.201: 1 128.97.113: 1 137.145.112: 1 207.68.13: 1 198.247.230: 1 194.205.68: 1 195.232.0: 1 157.130.193: 1 172.16.0: 1 172.16.1: 1 194.38.93: 1 131.119.18: 1 4.0.182: 1 192.221.96: 1 131.119.26: 1 131.119.28: 1 12.127.81: 1 128.97.147: 1 12.127.83: 1 164.67.72: 1 131.119.36: 1 131.119.38: 1 204.59.224: 1 128.97.230: 1 193.118.200: 1 194.164.1: 1 194.88.82: 1 131.119.49: 1 207.240.1: 1 207.137.76: 1 205.182.0: 1 ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

8 10

Terminology for replication
by Howard C. Berkowitz 13 Jun '98

13 Jun '98

In determining customer requirements for "multihomed" or generic high-availability services, I often find there is a major terminology problem. Customer expectations may not be met because they are using "cache" or "mirror" differently than an ISP person. After the April IETF meeting, Jacob Palme posted to the general IETF mailing list what I tink is an excellent start on the problem. There was almost no response, other than a comment or two that different application communities use the terms differently. Perhaps these issues would be more of interest in NANOG, because I think they are very operational at the requirements definition end. Unless a more useful place to collect comments emerges, I'd like to record the consensus in my I-D on multihoming requirements, currently http://www.ietf.org/internet-drafts/draft-berkowitz-multirqmt-01.txt My thoughts would to be to get one more round of comments, see if the IETF Operations Area wants to consider it, and if not send it to the IESG as an individual contribution in a month or two. The subject is one of those things that doesn't quite fit the RFC model. ----------- Date: Thu, 2 Apr 1998 15:38:13 +0100 To: IETF general mailing list <ietf(a)ns.ietf.org> From: Jacob Palme <jpalme(a)dsv.su.se> Subject: Terminology for replication What is the correct term for various kinds of replication. Below is a proposal as a basis for a discussion. Function Proposed term -------------------------------------------------------+------------------- A general term for all kinds of copying of identical Replication to several stores. Replication, where the stores which hold the ori- Mirroring gal knows about where copies are held and periodic (I have also heard automatic updates ensure conformance between mirror the term push- copies and the original. caching) Replication, where a store saves a copy of a docu- Caching ment which it happens to get, without 100 % safe methods against outdated objects in the cache. Caching with some added facilities, such as Controlled caching? "Expiry" fields, to reduce the risk of outdated objects in a cache. Replication, where all copies are equally valid, ????? none of them is the "original", as in Usenet News. ------------------------------------------------------------------------ Jacob Palme <jpalme(a)dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme

1 0

Re: smurf amp nets
by Eric McClelland 13 Jun '98

13 Jun '98

On Jun 13, 12:47am, Jon Lewis wrote: > Subject: smurf amp nets > 205.227.44: 6 We've been checking the networks on the posted list, not only for ourselves but for our downstream customers, and attempting contact with customers where necessary to have them configure 'no ip directed-broadcast' or an equivalent. The administrator of the 205.227.44.0/24 network has asked that we post a confirmation that their network has been fixed. Thanks, Eric McClelland GTE Internetworking

1 0

FW: IANA Applications for TLDs
by Jim Fleming 13 Jun '98

13 Jun '98

---------- From: Jim Fleming[SMTP:JimFleming@unety.net] Sent: Saturday, June 13, 1998 6:03 AM To: 'DOMAIN-POLICY(a)LISTS.INTERNIC.NET' Cc: 'dns(a)iia.net.au'; 'tld-wg(a)ripe.net' Subject: IANA Applications for TLDs I suggest that ANY company serious about being a REGISTRY for a Top Level Domain send the following form to <comments(a)iana.org>. This will help to time-stamp people's intentions on the web site. http://www.iana.org/comments-mail/maillist.html 0a. (N)ew (M)odify (D)elete....: New 0b. Auth Scheme................: 0c. Auth Info..................: 1. Comments...................: Application for Top Level Domain 2. Complete Domain Name.......: Organization Using Domain Name 3a. Organization Name..........: 3b. Street Address.............: 3c. City.......................: 3d. State......................: 3e. Postal Code................: 3f. Country....................: Administrative Contact 4a. NIC Handle (if known)......: 4b. (I)ndividual (R)ole........: 4c. Name (Last, First).........: 4d. Organization Name..........: 4e. Street Address.............: 4f. City.......................: 4g. State......................: 4h. Postal Code................: 4i. Country....................: 4j. Phone Number...............: 4k. Fax Number.................: 4l. E-Mailbox..................: Technical Contact 5a. NIC Handle (if known)......: 5b. (I)ndividual (R)ole........: 5c. Name (Last, First).........: 5d. Organization Name..........: 5e. Street Address.............: 5f. City.......................: 5g. State......................: 5h. Postal Code................: 5i. Country....................: 5j. Phone Number...............: 5k. Fax Number.................: 5l. E-Mailbox..................: Billing Contact 6a. NIC Handle (if known)......: 6b. (I)ndividual (R)ole........: 6c. Name (Last, First).........: 6d. Organization Name..........: 6e. Street Address.............: 6f. City.......................: 6g. State......................: 6h. Postal Code................: 6i. Country....................: 6j. Phone Number...............: 6k. Fax Number.................: 6l. E-Mailbox..................: Prime Name Server 7a. Primary Server Hostname....: 7b. Primary Server Netaddress..: Secondary Name Server(s) 8a. Secondary Server Hostname..: 8b. Secondary Server Netaddress: Jim Fleming Unir Corporation - http://www.unir.com 1998 - The Year of the C+@ IS Coordinator for the AM Radio Station Registry - http://www.DOT.AM

1 0

Every Active Member Deserves A Paycheck!
by XE28q6ol4＠oprai11ders.com 13 Jun '98

13 Jun '98

Every Active Member Deserves A Paycheck! No Sponsoring Required To Get A Paycheck! ***The True Network Marketers Dream.*** Simple And Unbelievably Lucrative! Click Here For More Information> http://www.gwc1.com/members/fd79/gwc1.htm To be removed - remove58(a)hotmail.com or call 904-282-0945

1 0

The Cidr Report
by Tony Bates 12 Jun '98

12 Jun '98

This is an auto-generated mail on Fri Jun 12 12:00:00 PDT 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 12Jun98 0) General Status Table History ------------- Date Prefixes 050698 50625 060698 51451 070698 51501 080698 51191 090698 51499 100698 51418 110698 51862 120698 51404 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3625 Number of ASes announcing only one prefix: 1735 (917 cidr, 818 classful) Largest number of cidr routes: 357 announced by AS3561 Largest number of classful routes: 1128 announced by AS701 1) Gains by aggregating at the origin AS level --- 12Jun98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 463 240 223 48.2% IMCI AS2493 501 291 210 41.9% iSTAR Internet, Inc. AS3602 506 313 193 38.1% Sprint Canada Inc. AS1740 545 353 192 35.2% CERFnet AS701 1128 939 189 16.8% Alternet AS3749 220 65 155 70.5% TECNET AS174 728 583 145 19.9% Performance Systems International AS4262 213 125 88 41.3% CERFnet Los Angeles SMDS AS3221 112 42 70 62.5% EENet Autonomous System AS4755 98 31 67 68.4% Videsh Sanchar Nigam Ltd. India AS10928 109 43 66 60.6% UNKNOWN AS7046 207 142 65 31.4% UUNET-CUSTOMER AS5668 114 49 65 57.0% Century Telephone Inc. AS3804 206 144 62 30.1% Bell Solutions AS271 113 54 59 52.2% BCnet Backbone AS1221 289 233 56 19.4% AARNET-AS AS549 205 152 53 25.9% ONet Backbone AS4740 375 323 52 13.9% ASN-OZEMAIL (Ozemail Pty Ltd) AS4539 74 24 50 67.6% NETROPOLIS AS72 85 37 48 56.5% Schlumberger Information Network AS6335 68 20 48 70.6% NTRNET AS8517 122 75 47 38.5% ULAKNET-ASN AS4200 148 101 47 31.8% AGIS (Apex Global Information Ser AS1239 541 494 47 8.7% SprintLink Backbone AS852 159 118 41 25.8% AGT Advance Communication AS7657 122 84 38 31.1% The Internet Group Limited AS762 115 78 37 32.2% WELLFLEET-AS AS719 443 406 37 8.4% LANLINK autonomous system AS6181 65 28 37 56.9% FUSE-NET AS803 72 36 36 50.0% SaskNet Backbone For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0