- Test - lists.nanog.org

Re: backbone routers' priority settings
by vaananen＠NASBPD01BS.ntc.nokia.com 04 Feb '98

04 Feb '98

>>> ICMP in general is or should be given higher priority, since it is >>> necessary for congestion control. Echo requests (pings) could be thrown >> >>Please, tell me of this magic ICMP that is used for congestion control. >>Obsolete things that are now recommended against don't count. >Where is ICMP made obsolete or recommended against? I don't see it. >From rfc1812: ... stuff deleted Also from RFC1812: 4.3.3.3 Source Quench A router SHOULD NOT originate ICMP Source Quench messages. As specified in Section [4.3.2], a router that does originate Source Quench messages MUST be able to limit the rate at which they are generated. DISCUSSION Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion. See, for example, [INTERNET:9] and [INTERNET:10]. Section [5.3.6] discusses the current thinking on how routers ought to deal with overload and network congestion. A router MAY ignore any ICMP Source Quench messages it receives. DISCUSSION A router itself may receive a Source Quench as the result of originating a packet sent to another router or host. Such datagrams might be, e.g., an EGP update sent to another router, or a telnet stream sent to a host. A mechanism has been proposed ([INTERNET:11], [INTERNET:12]) to make the IP layer respond directly to Source Quench by controlling the rate at which packets are sent, however, this proposal is currently experimental and not currently recommended. Pasi

2 1

Re: MAE-Central
by Sean M. Doran 04 Feb '98

04 Feb '98

"Kent W. England" <kwe(a)geo.net> writes: > (BTW, isn't it scandalous that MFS would copy the PacBell NAP and build a > MAE using S'com BPX switches? No, just tragically stupid. Sean.

5 5

BGP mailing list
by Bradley Reynolds 04 Feb '98

04 Feb '98

Because I was tired of BGP questions coming onto a wide variety of lists, I created a mailing list for them. To subscribe, send mail to bgp-request(a)iagnet.net with 'subscribe' in the body. Note: This list deals with more of the ground level BGP understanding. It is not intended to replace/duplicate bgp(a)ans.net. Just a wishful attempt to improve the clue factor :). BR brad reynolds ber(a)cwru.edu

1 0

Re: with a flap flap here and a flap flap there...
by Sean M. Doran 04 Feb '98

04 Feb '98

Marc Slemko <marcs(a)znep.com> writes: > 3333 6905 5623 1136 3300 7018 6478 1 701 814 7189 1691 852 6171 (history entry) > Am I the only one that has a problem with this? You withdraw a > route once, and it has flapped enough to be dampened in numerous > places. I could have been half convinced that we had gone back to > distance vector routing seeing this going on... BGP *is* a distance-vector routing protocol. What you were witnessing was a counting-to-infinity problem that is bounded by timers and toplogical constraints. Welcome to the wonderful world of BGP == RIP. This is precisely why a mechanism which constrains the amount of prefix transitions is so important: magnification of flapping is predictable. However, welcome to the wonderful world of lack of filtering, too. There is no apparent reason why a number of those ASes should have reannounced your routes to each other. Each BGP peering (customer and peer alike) should either explicitly allow announcements only from a list of appropriate ASes, or explicitly disallow announcements which have been through peers and (at least large) other BGP-talking customers. This is an Incredibly Smart Thing To Do. On a Cisco, the _ operator is your best regexp friend... Sean.

2 1

Re: Transparent Caching Solutions - Information Wanted
by Paul A Vixie 04 Feb '98

04 Feb '98

several folks have sent replies to me personally which may be of general interest: > Hit rates are user population dependent. We have seen hit rates > as high as 30% from a single T1 connected customer (with a population > of less then 500 people). so have we. but that was a computer club with its own POP and they were mostly sharing interesting (i.e., pornographic) URL's over an IRC back channel. we've got ~80 transparent caching units out in the field, and most of them are in "normal" modem pools where the users don't know each other and the communitities of interest have broader splay. > ... in some special cases you really can predict what would best be in the > cache beforehand. You then win from a speed standpoint (pre fetched data > is served up faster). yes, that's true -- in some special cases you can exercise prescience and if you can then the hit rate goes up by a lot as does the downstream data rate. however, to make this work you have to continuously feed the primary caches new prescient data (or prescient metadata by which prescient data can be fetched). interest factor is in other words dynamic and shortlived.

2 1

Re: MAE-Central
by Sean M. Doran 04 Feb '98

04 Feb '98

Dave Siegel <dave(a)rtd.net> writes: > Dave (who's waiting to see a NAP built with a GSR (or similar) ) Almost. Well, that is, this is almost what you are waiting for. What you should want is a NAP that scales upwards from a level below the interfaces that the GSR can give you. In effect, what you want is a NAP that looks like this: {ethernet,atm,POET,HSSI}--7507--POS---1 blabla------7507--POS---2 0---POS---customer 1---POS---customer 2---POS---customer of course, in order for this to work, you really want to be running MPLS on all the devices from the *connectee* inwards. This gives you a multi-media connection to a NAP at speeds ranging from slow (you could do DS0s on a 7507, for example) to fast (you could do STM-16c/OC48c out the 12012). Note that I was even really nice and left "atm" up there as a potential access method. This is similar to what Milo and I wanted to do with the MAE-WEST conspiracy to let the NSF declare the PAC*Bell and MAE-WEST facilities to be co-priority-NAPs. Unfortunately someone (ahem) played politics better than us on that one front. On the other hand, the PAC*Bell NAP has hardly been a model of stunning success as a result... Anyway, the idea is that you can colocate or not colocate at this facility as you see fit, and you can use several access technologies including some carrier's ATM fabric. The NAP is extensible -- you could have a really big ATM channel into the 12012 with lots of VCs talking MPLS, for example, if that was really popular. There are some interesting questions about what to do when multiple load-balanced OC48s among several 12012s don't provide enough bandwidth at a decent cost, but those interesting questions plague other parts of the Internet where that will be a ceiling faster (probably). Deployment problem #1: MPLS availability. Interim gross hack #1: GRE tunnels across a private small-i internet using RFC-1918 space. (GRE tax is high, but it is perhaps less gross a hack than several other possibilities that have sprung to mind). The JUUNIPERMCIWORLDPALMPEXETC people reading this may wish to advance alternatives to the 12012, or a supplement for the 12012 for "robustness". tli has, after all, also proposed designs very similar to this; i think one was even posted to NANOG... Sean. P.S.: POET (packet over E3/T3) is very cool as a sort of lower-speed alternative to point-to-point POS. It does very well in this type of environment... Thank you auntie Cisco.

1 0

Re: Transparent Caching Solutions - Information Wanted
by Paul Gauthier 04 Feb '98

04 Feb '98

Paul Vixie wrote: > > Inktomi <URL:http://www.inktomi.com> has announced their intention to offer > transparency but they are not an appliance (like Cisco, Vixie, and NetApp) > and last I heard they were waiting on some Solaris kernel changes before > they could actually ship transparency. > Paul Vixie gave a nice summary of some of the cache solutions available. To be absolutely correct, Inktomi's Traffic Server network cache does very much ship with integrated transparency today! It also provides a bunch of cache services that people like including multicast clustering, HSRP-derived failover, centralized management, adaptive networking and a fast raw-disk object store. We have some info on Inktomi's home page (www.inktomi.com) if you are curious. Paul

1 0

smurf... still?
by Daniel Reed 04 Feb '98

04 Feb '98

I was looking through a modified copy of smurf.c I had (it listened on a port and when an incoming connection was detected, it asked for a host and then smurfed it--or so the documentation says, I just wanted to see how the port listening was achieved) and just wanted to check how many of the broadcasts in the default bcastaddr[] still were smurfable, and noted that the *very first one* was. How would I go about finding out the administrative contact for a network given its broadcast address? Specifically I'm looking for 165.154.1.255, but there are probably some others as well... root@narnia:~# ping -c2 165.154.1.255 PING 165.154.1.255 (165.154.1.255): 56 data bytes 64 bytes from 165.154.1.26: icmp_seq=0 ttl=241 time=287.2 ms 64 bytes from 165.154.1.66: icmp_seq=0 ttl=241 time=309.0 ms (DUP!) 64 bytes from 165.154.1.7: icmp_seq=0 ttl=241 time=338.9 ms (DUP!) 64 bytes from 165.154.125.53: icmp_seq=0 ttl=242 time=358.8 ms (DUP!) 64 bytes from 165.154.1.1: icmp_seq=0 ttl=241 time=388.9 ms (DUP!) 64 bytes from 127.0.0.2: icmp_seq=0 ttl=241 time=399.1 ms (DUP!) 64 bytes from 165.154.1.8: icmp_seq=0 ttl=241 time=418.8 ms (DUP!) 64 bytes from 165.154.1.57: icmp_seq=0 ttl=241 time=439.0 ms (DUP!) 64 bytes from 165.154.1.4: icmp_seq=0 ttl=241 time=449.0 ms (DUP!) 64 bytes from 165.154.1.21: icmp_seq=0 ttl=241 time=459.0 ms (DUP!) 64 bytes from 165.154.125.53: icmp_seq=1 ttl=242 time=219.8 ms --- 165.154.1.255 ping statistics --- 2 packets transmitted, 2 packets received, +10 duplicates, 0% packet loss round-trip min/avg/max = 219.8/378.0/468.9 ms root@narnia:~# (what the heck is that 127.0.0.2 doing in there...?) -- Daniel Reed <n(a)narnia.n.ml.org> (3CE060DD) System administrator of narnia.n.ml.org (narnia.mhv.net [199.0.0.118]) What does not destroy me, makes me strong. -- Friedrich Nietzsche

6 5

Re: mae-east problems...
by Henry Clark 04 Feb '98

04 Feb '98

At 05:09 PM 2/3/98 -0500, Rich Fulton wrote: >Anyone else seeing odd packet loss through mae-east? ^^^ At least your packet loss is predictable, and far superior to that so-called "random" loss. henry

1 0

Re: Transparent Caching Solutions - Information Wanted
by Bill Unsworth 04 Feb '98

04 Feb '98

Interesting discussion - no many comments from ISPs currently using caching regarding the effectiveness - cache hit rates or bandwidth "saved". Any strategies for populating caches (in addition to user hits)? Bill At 12:08 PM 2/3/98 -0800, you wrote: >> Or, if you are a "Cheap Bastard (tm)", you can take a copy of Squid >> (http://squid.nlanr.net) and an OS which can handle transparent proxying >> (Solaris, Linux, etc), a high performance RAID, and have yourself the >> equivilent. Squid is a heirarchial web cache/proxy/accelerator available for >> free. > >i love squid. i use it as a nontransparent proxy and also as the web server >accelerator for all of the content we publish. squid is really cool, >especially squid-novm. > >i worry a bit about the supposed proxy capabilities of these other os's. we >don't think of ourselves as idiots here when it comes to kernel programming, >and so the fact that it's taken a year of wizard level kernel muckraking to >get a system that can do thousands of simultaneous transparent sessions makes >me think that it's actually a hard problem. > >we got basic kernel transparency working in an afternoon. the devil is in >the details though. > > U-NET Limited - Global Transit Division Transit for ISPs from PAIX, MaNAP or Telehouse London mailto:world@u-net.net http://world.u-net.net Tel 44 1925 484444 Fax 44 1925 484466

3 2