March 1998 - Test - lists.nanog.org

Re: Questions: Long Range Dependence
by Vern Paxson 16 Mar '98

16 Mar '98

> 1. Single VBR video source traffic is considered as LRD traffic. What are > the characteristics of multiplexing traffic of multiple sources, (e.g., > does the output traffic of an ATM multiplexer have the property of LRD?). Yes - multiplexed LRD is likewise LRD. > 2. Since Internet traffic (i.e., LAN/WAN) is partly considered as LRD > traffic, what impact does it have on design of Bridge/Router? You need a whole lot of buffer to absorb bursts. > 3. Where can I find Video traffic database (e.g., film compressed by > Mpeg-2)? I know these exist, but unfortunately can't point you at any. > 4. Are there any mail groups discussing LRD and/or ATM? I don't know of any for LRD. ATM is discussed in the newsgroup comp.dcom.cell-relay. To get more detailed answers, you should dig through the past five years of SIGCOMM proceedings, and also the past three or so years of IEEE/ACM Transactions on Networking, both of which have had a number of LRD-related papers. Vern

1 0

Questions: Long Range Dependence
by Zhang Peng 15 Mar '98

15 Mar '98

Hi, I am greatly interested in doing some work on Long Range Dependence of ATM traffic modeling. I have several questions as follows. 1. Single VBR video source traffic is considered as LRD traffic. What are the characteristics of multiplexing traffic of multiple sources, (e.g., does the output traffic of an ATM multiplexer have the property of LRD?). 2. Since Internet traffic (i.e., LAN/WAN) is partly considered as LRD traffic, what impact does it have on design of Bridge/Router? 3. Where can I find Video traffic database (e.g., film compressed by Mpeg-2)? 4. Are there any mail groups discussing LRD and/or ATM? Thanks, Zhang Peng

1 0

BGP: IOS 11.2(12)P & Route-Map problems?!
by jlixfeld＠idirect.ca 15 Mar '98

15 Mar '98

I recently upgraded to IOS 11.2(12)P and I'm having some trouble with route-maps taking. I'm wondering if anyone has had a similar incident: neighbor 205.150.206.65 route-map UUNET in neighbor 206.47.45.128 route-map BGS in ! ip as-path access-list 100 permit _816_ ip as-path access-list 100 permit _701_ ip as-path access-list 100 permit _1673_ ip as-path access-list 100 permit _2548_ ip as-path access-list 100 permit _3602_ ip as-path access-list 100 permit _1239_ ip as-path access-list 100 permit _6463_ ip as-path access-list 100 permit _2493_ ip as-path access-list 100 permit _174_ ip as-path access-list 101 permit .* ip as-path access-list 110 permit _2493_ ip as-path access-list 110 permit _174_ ip as-path access-list 110 permit _3804_ ip as-path access-list 110 permit _577_ ip as-path access-list 110 permit _3561_ ip as-path access-list 110 permit _6453_ ip as-path access-list 110 permit _2551_ ip as-path access-list 110 permit _6996_ ip as-path access-list 110 permit _1324_ ip as-path access-list 110 permit _1_ ip as-path access-list 110 permit _6347_ ip as-path access-list 110 permit _6463_ ip as-path access-list 110 permit _3602_ ip as-path access-list 110 permit _1239_ ip as-path access-list 110 permit _1673_ ip as-path access-list 110 permit _2548_ ip as-path access-list 111 permit .* ! route-map BGS permit 10 match as-path 100 set local-preference 50 ! route-map BGS permit 20 match as-path 101 set local-preference 60 ! route-map BGS permit 30 ! route-map UUNET permit 10 match as-path 110 set local-preference 40 ! route-map UUNET permit 20 match as-path 111 set local-preference 60 ! route-map UUNET permit 30 c7# sh ip bgp reg 701 * 16.0.0.0 206.222.95.53 60 0 6463 1239 701 33 i * 206.47.45.128 60 0 3804 577 6453 701 33 i *> 205.150.206.65 60 0 816 701 33 i The path 3804 577 6453 33 should have a local preference of 50 (access-list 100), not 60! (access-list 101) Path 816 701 33 is correct at 60 (access-list 111) c7# sh ip bgp reg 3561 * 12.10.14.0/23 206.47.45.128 60 0 3804 577 3561 10815 ? *> 205.150.206.65 60 0 816 701 3561 10815 ? It looks as though it is tagging everything as .*.. but this is odd. It tagged this route properly: * 24.231.0.0/19 206.47.45.128 50 0 3804 577 3561 2493 2493 8160 8160 i Anyone have any ideas?! I've done clear ip bgp xxx soft in but not clear ip bgp xxx I was running 11.2(5) before which had an route cache bug so I'm used to doing a clear ip cache after each reload. Did that too, and nothing. -- Regards, Jason A. Lixfeld jlixfeld(a)idirect.ca System Administrator [L5] jlixfeld(a)torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 ext 18 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------

1 0

Re: Someones being naughty again...
by Pat Darisme 15 Mar '98

15 Mar '98

I don't see a problem here ? According to RFC 1918 the Net 10 and Net 172.16/12 and 192.168/16 addresses are for use privately or internally such as when : " - Interfaces of routers on an internal network usually do not need to be directly accessible from outside the enterprise." These addresses are however not advertised to the outside world and should thus cause no problem here. We are simply seeing those net 10 addresses as a source address for those packets returned by the traceroute, but that address should not be reacheable or advertised from outside the internal network. See http://www.cis.ohio-state.edu/htbin/rfc/rfc1918.html for more details. Thanks Pat @Home Network Operations Once upon a time, Marc Hurst arranged the electrons in @Home's private scaleable, ATM, OC3 BackBone to write: > Subject: Someones being naughty again... > (Mar 13, 6:56pm) > Here is a traceoute from BBN Planet to my machine... (sorry D, couldn't > resist...:) > > traceroute to 24.112.43.xx (24.112.43.xx), 30 hops max, 40 byte packets > 1 netgwb (205.227.188.1) 196 ms 611 ms 9 ms > 2 oakland-cr2.bbnplanet.net (4.0.68.77) 20 ms 15 ms 19 ms > 3 oakland-br2.bbnplanet.net (4.0.16.17) 16 ms 15 ms 22 ms > 4 sanjose1-br1.bbnplanet.net (4.0.1.74) 25 ms 16 ms 15 ms > 5 bb.mae-w.home.net (198.32.136.70) 19 ms 17 ms 21 ms > 6 172.16.2.174 (172.16.2.174) 110 ms 108 ms 107 ms > 7 r3-fe0-0-100bt.rdc1.on.wave.home.net (24.2.9.4) 121 ms 108 ms 112 ms > 8 10.0.184.34 (10.0.184.34) 153 ms 109 ms 106 ms > 9 pc-30xxx.on.rogers.wave.ca (24.112.43.xx) 110 ms 111 ms 110 ms > > Nice 10.x.x.x. > End of included message written by Marc Hurst on Mar 13, 6:56pm, >

11 16

Operational: For a smurfy time, try...
by dlr＠bungi.com 15 Mar '98

15 Mar '98

Here's this weekends latest smurf amplifier networks. Please folks - all of your networks are on here. Check these addresses. Call your customers. Help them configure no ip directed broadcast. Thanks much! Dave Rand +1 408 254-7111 12.10.0.0 12.2.0.0 24.235.0.0 38.146.0.0 38.2.0.0 130.105.0.0 131.103.0.0 131.119.0.0 131.204.0.0 132.158.0.0 132.226.0.0 132.245.0.0 132.249.0.0 134.114.0.0 134.192.0.0 134.197.0.0 136.164.0.0 137.39.0.0 139.181.0.0 140.176.0.0 141.106.0.0 142.165.0.0 144.228.0.0 147.133.0.0 148.139.0.0 151.196.0.0 152.148.0.0 155.193.0.0 157.130.0.0 157.95.0.0 158.100.0.0 158.43.0.0 164.128.0.0 165.113.0.0 165.22.0.0 165.79.0.0 165.85.0.0 166.109.0.0 166.48.0.0 166.77.0.0 167.132.0.0 172.16.0.0 176.1.0.0 192.100.64.0 192.102.230.0 192.107.3.0 192.111.222.0 192.132.65.0 192.146.226.0 192.149.231.0 192.154.128.0 192.154.129.0 192.154.130.0 192.156.209.0 192.160.103.0 192.160.216.0 192.160.217.0 192.160.218.0 192.160.219.0 192.160.220.0 192.175.16.0 192.175.19.0 192.175.21.0 192.190.239.0 192.203.180.0 192.206.211.0 192.207.87.0 192.227.35.0 192.231.232.0 192.233.200.0 192.234.72.0 192.239.76.0 192.246.79.0 192.68.112.0 192.80.71.0 192.83.206.0 192.84.22.0 192.91.252.0 192.94.230.0 193.227.31.0 193.227.54.0 193.227.55.0 193.246.40.0 194.131.104.0 194.6.129.0 194.6.145.0 195.101.37.0 195.112.66.0 195.112.67.0 195.112.71.0 195.112.75.0 195.186.1.0 198.11.57.0 198.11.58.0 198.112.196.0 198.112.232.0 198.112.234.0 198.112.235.0 198.114.169.0 198.114.171.0 198.169.210.0 198.17.202.0 198.185.178.0 198.211.85.0 198.211.93.0 198.242.208.0 198.242.209.0 198.242.210.0 198.242.211.0 198.247.225.0 198.252.208.0 198.252.209.0 198.49.207.0 198.53.245.0 198.6.222.0 198.6.223.0 198.60.85.0 198.60.89.0 198.72.0.0 198.72.1.0 198.79.217.0 198.80.11.0 198.88.160.0 198.88.161.0 198.88.162.0 198.88.163.0 198.88.165.0 198.98.32.0 198.98.33.0 198.98.35.0 198.98.37.0 198.98.38.0 198.98.39.0 198.98.40.0 198.98.41.0 198.98.42.0 199.0.65.0 199.1.22.0 199.125.29.0 199.164.150.0 199.170.88.0 199.171.184.0 199.171.21.0 199.171.7.0 199.172.48.0 199.199.130.0 199.199.131.0 199.33.234.0 199.35.154.0 199.35.188.0 199.35.250.0 200.245.144.0 200.246.164.0 203.255.161.0 203.255.190.0 203.85.36.0 204.151.43.0 204.151.56.0 204.152.148.0 204.155.96.0 204.155.99.0 204.157.146.0 204.167.9.0 204.17.178.0 204.177.154.0 204.177.170.0 204.177.175.0 204.181.152.0 204.181.40.0 204.181.41.0 204.191.152.0 204.191.160.0 204.191.162.0 204.191.212.0 204.215.209.0 204.233.137.0 204.243.141.0 204.254.220.0 204.255.192.0 204.30.35.0 204.50.14.0 204.57.67.0 204.70.164.0 204.70.226.0 204.70.38.0 204.70.40.0 204.89.131.0 204.95.203.0 205.138.108.0 205.138.109.0 205.138.225.0 205.139.208.0 205.139.210.0 205.147.63.0 205.149.7.0 205.158.49.0 205.187.161.0 205.217.46.0 205.218.193.0 205.218.196.0 205.221.255.0 205.225.27.0 205.225.30.0 205.240.8.0 205.252.144.0 206.1.179.0 206.136.84.0 206.136.86.0 206.136.87.0 206.136.9.0 206.150.138.0 206.151.255.0 206.154.22.0 206.156.13.0 206.156.16.0 206.156.17.0 206.156.20.0 206.156.21.0 206.156.22.0 206.159.102.0 206.163.82.0 206.168.216.0 206.168.217.0 206.181.161.0 206.181.238.0 206.2.75.0 206.20.150.0 206.20.23.0 206.204.56.0 206.204.58.0 206.204.59.0 206.216.49.0 206.224.86.0 206.235.62.0 206.235.63.0 206.243.142.0 206.243.196.0 206.246.101.0 206.246.102.0 206.246.104.0 206.246.106.0 206.246.107.0 206.246.108.0 206.246.110.0 206.246.111.0 206.246.96.0 206.246.97.0 206.30.70.0 206.30.71.0 206.33.98.0 206.48.34.0 206.48.39.0 206.67.19.0 206.68.9.0 206.69.93.0 206.74.211.0 206.74.212.0 206.9.223.0 206.9.225.0 206.9.228.0 206.96.216.0 207.100.95.0 207.108.162.0 207.12.151.0 207.13.5.0 207.137.76.0 207.137.77.0 207.152.64.0 207.16.150.0 207.164.115.0 207.164.49.0 207.170.5.0 207.170.53.0 207.201.200.0 207.207.8.0 207.217.173.0 207.230.75.0 207.230.90.0 207.236.112.0 207.243.81.0 207.68.2.0 207.68.8.0 207.8.5.0 207.86.188.0 207.86.189.0 207.94.44.0 208.129.189.0 208.133.50.0 208.133.51.0 208.159.7.0 208.160.130.0 208.160.134.0 208.160.135.0 208.193.137.0 208.2.77.0 208.224.90.0 208.24.34.0 208.24.35.0 208.24.40.0 208.24.41.0 208.25.61.0 208.25.63.0 208.6.2.0 209.166.164.0 209.44.32.0 209.50.230.0 209.50.237.0 209.50.251.0 209.50.252.0 209.56.114.0 209.56.115.0 -- Dave Rand dlr(a)bungi.com http://www.bungi.com

4 3

RE: IP Space Management Software
by James Philpott 14 Mar '98

14 Mar '98

Phil - I meant the cost of the software in the $xxx.00 range, as opposed to $xx,xxx.00 range. How much are you paying for an Intel based server anyway? Sincerely, James Philpott >---------- >From: Phil Howard[SMTP:phil@charon.milepost.com] >Sent: Saturday, March 14, 1998 1:12 AM >To: James Philpott >Cc: nanog(a)merit.edu >Subject: Re: IP Space Management Software > >> For a little simpler architecture MetaIP from MetaInfo is worth a look. >> We handle DNS, DHCP, DDNS, and run on NT. >> >> http://www.metainfo.com/products/metaip/index.htm >> >> Pay close attention to the price. > >Yikes! > >Add to that the cost of adding another machine, NT server, and administering >it, and ... I think I'll go back to my plan to write my own web based one. > >-- >Phil Howard | ads2suck(a)no90ads7.net no5way22(a)noplace4.org >no1way37(a)spam8mer.edu > phil | stop5ads(a)no4where.net w3x1y1z6(a)dumb0ads.edu >no1spam8(a)dumb3ads.edu > at | no60ads8(a)spam1mer.edu die3spam(a)dumb9ads.net >end1it31(a)spammer8.org > milepost | end2ads0(a)no51ads5.net suck7it2(a)anywhere.edu >end4ads9(a)dumbads0.edu > dot | no38ads1(a)noplace0.edu stop8it3(a)no6place.edu >no31ads9(a)lame9ads.com > com | end4it10(a)no4place.org eat29me7(a)no6where.net >a4b8c1d0(a)s6p5a6m1.edu >

1 0

Re: Someones being naughty again...
by markp＠perki.net 14 Mar '98

14 Mar '98

> On Sat, 14 Mar 1998, Blake Willis wrote: > > It _does_ break things if not done with very careful attention. Most of > the people using it have no clue about how it can break things and are > bewildered when it is explained to them. > > For example? A router with one ATM interface going to the world with a > high MTU with an ethernet on the other side. Say you use private IP space > for links on that router. Say someone on the Internet filters traffic > from private netblocks; lots of people do. There _can_ be machines that > are completely unable to transfer data (eg. download a web page) from > another because you just broken path MTU discovery. This is not a made up > situation, this is a real example that I have had to deal with of how > using private IP space for > network interfaces used for public traffic does break things in some > situations. Also protocols like CUSeeMe that embed IP addresses in the protocol will break for any leaf nodes that have a private netblock address. > >

1 0

Old NANOG (NSF Techs?) Meeting notes.
by Alex Rubenstein 14 Mar '98

14 Mar '98

I was just enjoying myself reading through the notes from previous NANOGs, and there is a reference in one: from http://www.academ.com/nanog/feb1997/welcome.html "NANOG started as the NSFNET Regional Techs meeting in 1988. In 1994 during the privatization of the Internet, NANOG evolved from the NSFNET Regional Techs meetings. The purpose of both groups was to provide a forum for the exchange of information on the operation of the Internet." So, my question is, are there any notes for the meetings from the Regional Techs meeting? Just curious. After reading these notes, we've come a *long* way.

2 1

Someones being naughty again...
by Marc Hurst 14 Mar '98

14 Mar '98

Here is a traceoute from BBN Planet to my machine... (sorry D, couldn't resist...:) traceroute to 24.112.43.xx (24.112.43.xx), 30 hops max, 40 byte packets 1 netgwb (205.227.188.1) 196 ms 611 ms 9 ms 2 oakland-cr2.bbnplanet.net (4.0.68.77) 20 ms 15 ms 19 ms 3 oakland-br2.bbnplanet.net (4.0.16.17) 16 ms 15 ms 22 ms 4 sanjose1-br1.bbnplanet.net (4.0.1.74) 25 ms 16 ms 15 ms 5 bb.mae-w.home.net (198.32.136.70) 19 ms 17 ms 21 ms 6 172.16.2.174 (172.16.2.174) 110 ms 108 ms 107 ms 7 r3-fe0-0-100bt.rdc1.on.wave.home.net (24.2.9.4) 121 ms 108 ms 112 ms 8 10.0.184.34 (10.0.184.34) 153 ms 109 ms 106 ms 9 pc-30xxx.on.rogers.wave.ca (24.112.43.xx) 110 ms 111 ms 110 ms Nice 10.x.x.x.

2 1

RE: IP Space Management Software
by James Philpott 14 Mar '98

14 Mar '98

For a little simpler architecture MetaIP from MetaInfo is worth a look. We handle DNS, DHCP, DDNS, and run on NT. http://www.metainfo.com/products/metaip/index.htm Pay close attention to the price. James Philpott >-----Original Message----- >From: Cathy_Allison(a)BayNetworks.COM [SMTP:Cathy_Allison@BayNetworks.COM] >Sent: Thursday, March 12, 1998 2:12 PM >To: bjones(a)cte.net; nanog(a)merit.edu >Subject: IP Space Management Software > >Check out NetID at >http://www.baynetworks.com/Products/nav/f_netid_3_0.html. It's an >enterprise IP address, DNS and DHCP management product. Has added >functionality for VLSM design - recursively partitions networks and >automatically calculates subnet masks. > >Cathy Allison > >Return-Path: <owner-nanog(a)merit.edu> >>X-Sender: bjones(a)nt1.centuryinter.net >>Date: Thu, 12 Mar 1998 15:08:50 -0600 >>To: nanog(a)merit.edu >>From: Brantley Jones <bjones(a)cte.net> >>Subject: Re: Q: IP Space Management Software >>Sender: owner-nanog(a)merit.edu >> >>At 03:16 PM 3/12/98 -0500, you wrote: >>> >>>Are any of you using software that you would recommend for large-scale >>>management of IP space across AS', subnets from /16 to /32, >>>differentiating IP blocks from IP hosts? >>> >>>Would love to hear from you if you do! >>> >>>Mike. >> >>Excel !...hehe, I would (obviously) also love to hear if somebody is using >>something better, that is commercially available. I would worry about the >>program's ability to handle VLSM. >> >>Brantley >> >

2 1