June 1998 - Test - lists.nanog.org

flat vs non-flat charging
by Jerry Scharf 07 Jun '98

07 Jun '98

I think the idea of distance charging is going away in many cases. With WDM, the cost of the WDM and SONET eqiupment on the ends of a fully populated 32 channel per fiber, 144 strand pull vastly outweight end-to-end fiber costs of anything pulled through the ground. When you add routers and the like on top of that, the distance issue really goes away and it becomes on of network topology hops. Can anyone with figures for new intercontinental pulls say whether this is true there as well (project oxygen marketing claims this, but...)? Using archaic telephone pricing models to argue cost of providing bulk IP services is just not right. jerry

5 5

Re: More smurf networks. FIX YOUR ROUTERS.
by John Fraizer 07 Jun '98

07 Jun '98

While you IRC people are out checking for SMURF amplifier networks, perhaps you should check your own: [root@eth0-core0]:~ # ping 132.249.66.0 PING 132.249.66.0 (132.249.66.0): 56 data bytes 64 bytes from 132.249.66.6: icmp_seq=0 ttl=245 time=83.0 ms 64 bytes from 132.249.66.159: icmp_seq=0 ttl=244 time=84.3 ms (DUP!) 64 bytes from 132.249.66.148: icmp_seq=0 ttl=244 time=84.8 ms (DUP!) 64 bytes from 132.249.66.109: icmp_seq=0 ttl=244 time=85.3 ms (DUP!) 64 bytes from 132.249.30.7: icmp_seq=0 ttl=245 time=85.8 ms (DUP!) 64 bytes from 132.249.66.154: icmp_seq=0 ttl=53 time=86.3 ms (DUP!) 64 bytes from 132.249.66.62: icmp_seq=0 ttl=244 time=87.0 ms (DUP!) 64 bytes from 132.249.66.208: icmp_seq=0 ttl=244 time=87.4 ms (DUP!) 64 bytes from 132.249.66.140: icmp_seq=0 ttl=244 time=89.6 ms (DUP!) 64 bytes from 132.249.66.146: icmp_seq=0 ttl=244 time=90.1 ms (DUP!) 64 bytes from 132.249.66.45: icmp_seq=0 ttl=244 time=90.6 ms (DUP!) 64 bytes from 132.249.66.124: icmp_seq=0 ttl=53 time=91.1 ms (DUP!) 64 bytes from 132.249.66.229: icmp_seq=0 ttl=244 time=91.6 ms (DUP!) 64 bytes from 132.249.66.166: icmp_seq=0 ttl=244 time=92.1 ms (DUP!) --- 132.249.66.0 ping statistics --- 1 packets transmitted, 1 packets received, +13 duplicates, 0% packet loss round-trip min/avg/max = 83.0/87.7/92.1 ms [root@eth0-core0]:~ # ping 132.249.66.255 PING 132.249.66.255 (132.249.66.255): 56 data bytes 64 bytes from 132.249.66.159: icmp_seq=0 ttl=244 time=85.0 ms 64 bytes from 132.249.66.148: icmp_seq=0 ttl=244 time=86.1 ms (DUP!) 64 bytes from 132.249.66.109: icmp_seq=0 ttl=244 time=87.0 ms (DUP!) 64 bytes from 132.249.30.7: icmp_seq=0 ttl=245 time=87.5 ms (DUP!) 64 bytes from 132.249.66.154: icmp_seq=0 ttl=53 time=88.0 ms (DUP!) 64 bytes from 132.249.66.6: icmp_seq=0 ttl=245 time=88.5 ms (DUP!) 64 bytes from 132.249.66.62: icmp_seq=0 ttl=244 time=88.9 ms (DUP!) 64 bytes from 132.249.66.140: icmp_seq=0 ttl=244 time=89.5 ms (DUP!) 64 bytes from 132.249.66.146: icmp_seq=0 ttl=244 time=91.3 ms (DUP!) 64 bytes from 132.249.66.208: icmp_seq=0 ttl=244 time=91.8 ms (DUP!) 64 bytes from 132.249.66.45: icmp_seq=0 ttl=244 time=92.4 ms (DUP!) 64 bytes from 132.249.66.229: icmp_seq=0 ttl=244 time=92.9 ms (DUP!) 64 bytes from 132.249.66.124: icmp_seq=0 ttl=53 time=93.4 ms (DUP!) 64 bytes from 132.249.66.166: icmp_seq=0 ttl=244 time=93.9 ms (DUP!) --- 132.249.66.255 ping statistics --- 1 packets transmitted, 1 packets received, +13 duplicates, 0% packet loss round-trip min/avg/max = 85.0/89.7/93.9 ms ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1

follow up for: System Hack and Data Stolen
by James McKenzie 07 Jun '98

07 Jun '98

Thank you to everyone who responded to this request for help. Colorado University has contacted me and we are working on the problem. Please do not think of this reflects in any way on the University, the user involved had a legitimate account and specifically used it as the user considered the site secure. James James McKenzie mcs(a)1ipnet.net http://www.1ipnet.net

1 0

Warning
by Jared Mauch 07 Jun '98

07 Jun '98

I'm doing a sweep of various networks that may be smurf amps. If you log an attempt from 204.42.254.5 trying to hit your boxes, it's just me. I will post a link to my results once I have the data. It should take me some time though. Thanks for your understanding in this matter. - jared -- Work: jared(a)qual.net - We Make The Internet Work for Your Business 9-5pm(ET) 800 637 4424x2634 - 24x7 NOC - 800 424 3223 pgp key available via finger from jared(a)puck.nether.net

1 0

Re: Hello, Detriot! This is not an operational message...
by elezar＠pfrc.org 07 Jun '98

07 Jun '98

On Sat, Jun 06, 1998 at 05:31:27PM -0400, Al Reuben wrote: > So, we're here. In the same lines, I'm interested to hear if anyone wants to do a Spam BOF or something similar sometime in the evening. I'll be here for the rest of the evening until after the "Interesting things you can do with ospf" talk. If anyone's interested, lets say we meet in the terminal room afterwards? -- Jeffrey Haas "He that breaks a thing to find out what it is has elezar(a)pfrc.org left the paths of wisdom." (Or works for Fermilab...)

1 0

Re: BGP4 and gated for Linux
by swright＠merit.edu 07 Jun '98

07 Jun '98

The latest public release of gated is 3.5.9 and is available at: ftp://gated.merit.edu/net-research/gated/gated-3-5-9.tar.gz Lots of information regarding licenses, bug reports, and releases can be found at http://www.gated.org/ Cheers, Shane -- Shane W. Wright /~_ _ _|_ _ |~\ Systems Research Programmer \_/ (_| | (/_ |_/ Merit Network, Inc. w w w . g a t e d . o r g

1 0

System Hack and Data Stolen
by James McKenzie 07 Jun '98

07 Jun '98

I'm looking for contacts for Colorado.edu. I'm the system administrator for Pathway Communications. Earlier to day our site was compromised. Data files were taken and the hardrive wiped. We have tracked him back to refuge.Colorado.edu and his home provider fastelane.net. Currently I have sent email to the contacts listed on Colorado.edu. I'm hoping someone reading this list may be with Colorado.edu or know someone who is. Any information you can provide is appreciated. The following is my contact information. James McKenzie mcs(a)1ipnet.net voice: 408/249-4780 pager: 408/233-9164 Thank you for your time. James James McKenzie mcs(a)1ipnet.net http://www.1ipnet.net

1 0

BGP4 and gated for Linux
by Roeland M.J. Meyer 07 Jun '98

07 Jun '98

Where can I get latest and which is the latest. I prefer open-source but I'll take binary-only if I don't have to cough-up the $110KUS for it. GAWD, what a rip-off! Is 3.5.5 still the latest sources? ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer(a)mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ SecureMail from MHSC.NET is coming soon!

1 0

MTU problems with GRE tunnels
by philip bridge 07 Jun '98

07 Jun '98

I'm experiencing problems with fragmentation due to Cisco GRE tunnel overhead: the way I understand it, the MTU if a GRE tunnel will always be less than the MTU of the underlying IP cloud (in our case 1500 bytes) due to the IP encapsulation overhead. So 1500 byte packets attempting to traverse the tunnel will be fragmented, or dropped if the DF bit is set, in which case an ICMP message is send back to the originating host We're trying to use GRE tunnels extensivly in some fancy added-value Internet services, and it seems that there is a small but significant amount of application traffic out there that has problems when traversing a GRE tunnel with MTU < 1500. We've seen two problems: - 1500 byte packets with DF set. This is either application traffic, or MTU path discovery is broken, because the same packets get sent repeatedly - 1500 byte packets get fragmented, but the destination host cannot cope with the fragmentation (firewall issues?) We see this on a variety of platforms (from 2500, 7507) and a variety of IOS releases (11.1(18)CC, 11.1(2), 11.2(5). Talking to another provider indicates that the same problem exists with other vendors, and is having the same severe impact. Thinking about it, this is a problem is to be expected with IP tunnels of all types, but I am surprised at the extent it's influence on our customer's applications (such as large emails). I do not want to overstate the proportion of traffic we see with this problem - but it does seem to be enough to render GRE tunnels very problematic - to say the least. But I know lots of people are using GRE for this or similar applications...so what am I missing here. thanks in advance for help/tips Phil ______________________________________________________________ Philip Bridge ++41 31 688 8262 bridge(a)ip-plus.net www.ip-plus.ch PGP: DE78 06B7 ACDB CB56 CE88 6165 A73F B703

3 2

Re: Load balancing/Multiple CNAME's (Was: Re: Beyond DNS...)
by shields＠crosslink.net 07 Jun '98

07 Jun '98

In article <357981AD.D7950B99(a)san.rr.com>, Studded <Studded(a)san.rr.com> wrote: > In any case, all this does is reinforce Paul Vixie's statement in the > FAQ that I quoted previously. Basically he said that multiple CNAME's > are allowed now, but may go away at some point in the future. That > doesn't mean it's not a valid tool now, especially since there aren't > any better tools yet. It's not wise to deploy more instances of something which is clearly deprecated. -- Shields, CrossLink.

1 0