- NANOG - lists.nanog.org

Re: PPPOE, MTU, and boom.
by Scott Silzer 18 Jul '01

18 Jul '01

I have found 4 ways to get around the problem: 1) A somewhat effective fix is to have your users use a cache/proxy server. 2) Have your users lock there MTU to 1492 not 1500. 3) Some CPE routers will force 1492 MTU sessions. 4) Try to explain that ICMP is not just pings rate limit it don't drop it. Cisco's writeup on the problem: http://www.cisco.com/warp/public/794/router_mtu.html At 7:53 +0100 7/18/01, Simon Lockhart wrote: > >I have confirmed that when I block all ICMP to/from a website, we cannot >>browse that site -- which is somewhat obivious. The question is, how, as >>an internet community as a whole, do we fix this? >> >>Seems to me that most people using PPPOE would have a problem here. Or, am >>I alone? >> >>My testing has been limited to Win2k, but I've heard similar reports on >>WinME, 98, etc. > >We've come across this too, and spent quite a while diagnosing. The >problem exists wherever there's an MTU reduction, and is caused by a >combination of ICMP filtering (breaks PMTUD), and Microsoft's attempt at >PMTUD (they just set the DF bit on all packets and expect to get an ICMP >reply back if the packet is too large). > >Simon >-- >Simon Lockhart | Tel: +44 (0)1737 839676 >Internet Engineering Manager | Fax: +44 (0)1737 839516 >BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk >Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/ -- Scott A Silzer

1 0

PPPOE, MTU, and boom.
by Alex Rubenstein 18 Jul '01

18 Jul '01

(this is not intending to be a PPPOE holy war, so, please read on). Over the last few days, I've be pfutzing with getting PPPOE working (it's really our only choice, as Verizon only offers a 1483 service). We're using Cisco 7200's and 4700's to aggregate them on our side, from DS3 and OC3 ATM circuits. We're using VPDN in 12.1T, with PPPOE. The PPP and AAA and all that seem to work fine, however, we're having a browsing issue. I've checked every setting I can think of, including MTU (which is obvious and set to 1492), IP Header Compression (which when turned off fixed 99% of the problems), but there is still a few websites that we cannot get to, no matter what. I have confirmed that when I block all ICMP to/from a website, we cannot browse that site -- which is somewhat obivious. The question is, how, as an internet community as a whole, do we fix this? Some significant sites are like this -- the bill-checking portion of www.americanexpress.com, www.intuit.com, www.visa.com, some portions of www.chase.com, etc. Seems to me that most people using PPPOE would have a problem here. Or, am I alone? My testing has been limited to Win2k, but I've heard similar reports on WinME, 98, etc. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

3 2

Utilization of the redundant ring in SONET
by srihari varada 18 Jul '01

18 Jul '01

Hello: I would like to know how typical it is to have the redundant ring in SONET used for the transport of data while still providing protection switching features. Also, could any one give me insight into a few vendors that does it. I would appreciate, if some one could provide input on the above. Regards, Srihari Varada

3 2

When will 128M not be enough?
by Christopher A. Woodfield 18 Jul '01

18 Jul '01

Is there any research out there that tries to estimate how long it will be before BGP routers with 128M of RAM start to choke on the routing table? I know there are a lot of factors - the number of BGP peers, how much "other stuff" the router is doing, etc. - I'm really looking for a ballpark estimate, if one exists. I'm trying to convince someone NOT to use a Cisco 2650 for BGP multihoming, and my argument will, IMO, be a bit more effective if I can say "you'll need to replace it within X months/years"... -C --------------------------- Christopher A. Woodfield rekoil(a)semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

14 20

FW: BigRed.com - cache poisoning for com/net/org domains (SOLVED)
by Mike Batchelor 18 Jul '01

18 Jul '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have determined how my Windows 2000 DNS cache got poisoned, resulting in non-existent domains resolving instead to the bigred.com website. There are two registered hosts, NS1.REFRACT.COM (66.34.52.240) and NS2.REFRACT.COM (66.34.52.241) that are authoritative for some 543 domains under the generic TLDs. The list of domains is in the attached text file, for those who are interested (thanks to Joseph McDonald <joe(a)vpop.net> for grepping his copies of the gTLD zone files at my request). The addresses given are the ones in the glue from the gTLD servers. REFRACT.COM is registered through OpenSRS with NS[1-4].MYDOMAIN.COM as nameservers. Mydomain.com's servers give different addresses for NS[12].REFRACT.COM, 65.194.192.211 and 65.194.192.212, respectively. In practice, modern DNS software ignores the glue from the delegated-to nameservers, preferring to cache the glue from the parents, in this case, the gTLD servers. But even so, nameservers are in fact running on the addresses given in the REFRACT.COM zone by the Mydomain.com servers, and they behave the same way as described here. A DNS cache, following delegations from the roots, and the gTLD servers, for one of these domains, will encounter bogus glue in the responses to _iterative_ queries made to one of these poison servers. The bogus glue assigns false address records to [a-m].gtld-servers.net, assigning 66.34.52.224 to all of them. Depending on the state of the already-cached records for the gTLD server addresses, a naive DNS cache, such as Windows 2000 DNS server in its default setup, or very old BIND servers prior to ~4.9.1, may become poisoned by caching this bogus data. When that happens, future queries for gTLD domains will be directed to the server at 66.34.52.224. This bogus gTLD server at 66.34.52.224 is the one that responds to any _iterative_ query with the IP address of the bigred.com search engine website. It's rather simple to get a client of a vulnerable cache to make a query for one of the domains registered with the REFRACT.COM nameservers. HTML spam will do the trick. I emphasize _iterative_ query, because all these servers - all four NS[12].REFRACT.COM servers and 66.34.52.224 - are lame for any domain when given a recursive query. They simply give a referral back to the roots, with correct glue. A poor schmuck (like me) who is trying to track down the source of his Win2K cache poison, would encounter the bogus gTLD glue in his cache's answers, and would naturally query the server at the bogus address to see what is going on. But the common query tools perform recursive queries unless told otherwise. Caches use iterative queries to resolve domains for their clients. That these poison servers respond with bogus glue only to iterative queries is slightly clever, and provides a little cover while DNS caches continue to be poisoned. It confused me for a while in any case! I couldn't have done it better myself, even if I were Eugene Kashpureff. For Windows 2000 DNS, the solution is to click on the "Advanced" tab on the Properties screen of the DNS server control panel, and check the box labelled "Secure cache against pollution". Duh. Why this is not on by default ... ah why bother: it's Microsoft, just be glad it's there, for gods' sakes. Once your Win2K cache is a little less naive, you can flush the cache in the same control panel, and your DNS resolution should return to normal. No more bigred.com when you'd expect a "Cannot find server or DNS Error" page, no more replies to ping from hosts that don't exist, etc. Older BIND software simply must be replaced with a modern version that has some kind of poison protection. D. J. Bernstein's dnscache was never vulnerable, since it always tosses out-of-zone glue. I hope this proves useful to someone. I searched all over many search engines, and found a handful of references to the problem in various (sometimes funny) contexts, but no solution or explanation. Hopefully this message will be archived and easily found on Google, and the next poor schmuck that tries to solve this problem will find this post and save himself a few days' hair-pulling. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO1TfGUksS4VV8BvHEQIJXQCgoGXUsOBZ+PjgPbbwdMe39Pj/3hMAoK8p NJB5lesgwY1HyBnl4PUsuvYK =geCR -----END PGP SIGNATURE-----

1 0

Bush plan would revamp Net security
by Mitch Halmu 18 Jul '01

18 Jul '01

Very interesting article on c|net: Bush plan would revamp Net security http://investor.cnet.com/investor/news/newsitem/0-9900-1028-6594259-0.html?… --Mitch NetSide

1 0

Re: Utilization of the redundant ring in SONET
by Frank Coluccio 17 Jul '01

17 Jul '01

Some WAN Carriers make their 'protection' bandwidth available to ISPs and other takers on a preemtable basis. That is, when a ring failure occurs the protection bandwidth is reclaimed, or preempted, by the carrier for restoration purposes, thus "bumping" the original occumpant (you) into the ditch. Since this type of bandwidth comes at a discount, one has to weigh the operational risks (SLAs?) against the financial tradeoffs, which is what I suspect you are doing. It isn't all that bad if used in a straightforward mesh topology, or one where one for one link protection is used, because the ISP will normally design to recover their mesh through regular Layer 3 routing routines, anyway. It can get out of hand, however, if the particular ring in question is having intermittent troubles, causing the ISP to encounter an undesirable number of convergences per unit of time (hours, day, week, etc). > Hello: > > I would like to know how typical it is to have the redundant ring in > SONET used for the transport of data while still providing protection > switching features. Also, could any one give me insight into a few > vendors that does it. I would appreciate, if some one could provide > input on the above. > > Regards, > > Srihari Varada > > >

1 0

Public peering points in the Detroit, MI Area
by John Palmer (NANOG List) 17 Jul '01

17 Jul '01

Are there any public peering points in or around Detroit, MI?

6 5

Maintaining a central config database
by David Curran 17 Jul '01

17 Jul '01

I was wondering if anyone had any pointers on how to go about maintaining a central repository for various router configs. Specifically what I'm looking for is a way to keep access-lists, route-maps, prefix-lists, etc. in a central "store" and either push that info out at boot time or have the router request it. Any info would be appreciated, -david

2 1

Open Peers at MAE-Central
by Lee, Hansel 17 Jul '01

17 Jul '01

Does anyone have an list equivalent to the list below for MAE-Central? Thanks, Hansel -----Original Message----- From: Pete Ashdown [mailto:pashdown@xmission.com] Sent: Thursday, June 28, 2001 12:46 To: nanog(a)merit.edu Subject: Open Peers at PAIX What follows is a list I compiled of organizations at PAIX who peer without restrictions. Restrictions are "requirements" like nationwide or international OC-48 backbone, 45Mbit minimum traffic, four geographically disparate peering locations, bicoastal peering, and a standing seat on the Trilateral Commission. These restrictions are impossible for a small network like my own to fill. Usually by the time I am financially able to meet these restrictions, new ones have been crafted in their place. This list was compiled after an exaustive attempt to contact and peer with everyone participating at PAIX. The PAIX organization is unable to compile such a list, as it would violate their neutrality. I, however, am interested in peering with anyone and anything at PAIX, and I would presume that most networks who have made an investment to get there, would actually want to utilize their equipment. Without rehashing the endless debate on open peering, I believe it is more productive to promote the networks who are open peers, so time is not wasted filling out NDA's and applications only to be told, "No." I have only listed participants who are actively peering with me now. Several are still awaiting equipment and transit and have reacted positively to my requests. Also, I have not listed a particular network whom with I have peered for over two years. They have decided to place a "bicoastal restriction" on peering, and they are actually going through and depeering with former peers. This hasn't happened to me yet, but I'd imagine after this email, they'll accelerate their isolation. If anyone has any corrections or additions to this list, please email them to me directly. I will send this list to NANOG periodically unless there are major objections. Organization IP address AS# Email contact Vixie Enterprises 198.32.176.3 3557 noc(a)unnwo.net AboveNet 198.32.176.11 6461 noc(a)above.net DSL.net Santa Cruz 198.32.176.13 4436 admin(a)tycho.net Exodus 198.32.176.15 3967 peering(a)exodus.net Hurricane Electric 198.32.176.20 6939 mleber(a)he.net U-Net 198.32.176.22 5669 aid(a)u-net.net ValuServe 198.32.176.28 6123 noc(a)valuserve.com Global Crossing 198.32.176.29 3549 peering(a)gblx.net I.Net Technologies 198.32.176.30 3976 noc(a)nuri.net Lightning Internet 198.32.176.34 6427 noc(a)cp.net Critical Path 198.32.176.37 10627 wayne(a)criticalpath.net WebTV 198.32.176.39 6469 soc(a)corp.webtv.net XMission 198.32.176.42 6315 peering(a)xmission.com DACOM Corporation 198.32.176.43 3786 peering(a)bora.net Maxim Computer Systems 198.32.176.45 11388 peering(a)maxim.net PFM Communications 198.32.176.48 4513 help(a)pfmc.net SingTel 198.32.176.50 7473 peering(a)ix.singtel.com Zocalo 198.32.176.53 715 peering(a)zocalo.net KDDNet 198.32.176.65 2516 peering(a)kddnet.ad.jp WinterLAN 198.32.176.73 5081 noc(a)winterlink.net Hanaro Telecom 198.32.176.75 9318 peering(a)hanaro.com Hotmail 198.32.176.77 12076 dmcgilli(a)microsoft.com ViaNetWorks 198.32.176.80 7091 noc(a)via-net-works.com Open Data Network 198.32.176.86 4725 as-admin(a)gw.odn.ad.jp Digital Island 198.32.176.99 6553 mrose(a)digisle.net StarNet 198.32.176.100 6316 peering(a)starnetusa.net Electronic Arts 198.32.176.107 14891 rcortez(a)ea.com Sunrise Communications 198.32.176.110 6730 helpdesk(a)sunrise.ch Open Data Network 198.32.176.115 4725 as-admin(a)gw.odn.ad.jp Advanced Telcom Group 198.32.176.116 6971 peering(a)atgi.net DirecTV Broadband 198.32.176.119 12050 peering(a)telocity.net Nominum 198.32.176.120 17204 peering(a)nominum.com Thrunet 198.32.176.122 9277 noc(a)eng.thrunet.com Akamai 198.32.176.127 12222 peering(a)akamai.com One Call Communications 198.32.176.133 6402 rirving(a)onecall.net SITA Equant 198.32.176.140 2647 Juan.Vadillo(a)sita.int Compaq 198.32.176.241 33 noc(a)compaq.net Compaq 198.32.176.242 33 noc(a)compaq.net Internet Mainstreet 198.32.176.249 3856 woody(a)pch.net RSNG 198.32.176.251 178 rsngpeer(a)rsng.net RSNG 198.32.176.252 178 rsngpeer(a)rsng.net

1 0