- Test - lists.nanog.org

Latest IE patch breaking non username:password@encoded websites?
by Herman Harless 04 Feb '04

04 Feb '04

We're starting to take complaints from folks who have installed the latest IE patch about various broken website functionality. The complaints are not related to folks trying to use the username:password@ functionality that was removed by the patch. Is anyone taking similar calls / seeing similar issues? Herman Harless Director, Advanced Data Network Engineering and Operations NTELOS, Inc. herman(a)ntelos.net

9 8

RE: Latest IE patch breaking non username:password@encoded websites?
by Herman Harless 04 Feb '04

04 Feb '04

Sorry - Mostly non-password encoded forms that don't refresh when you hit submit. After Submitting 3 or 4 times they seem to work. Like most ISP's, we take calls when somebody's web site doesn't work, even if we don't even host it. On Tue, 2004-02-03 at 12:24, Conrad Golightly wrote: > Can you give us some more detail about what they ARE seeing? > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Herman Harless > Sent: Tuesday, February 03, 2004 11:27 AM > To: nanog > Subject: Latest IE patch breaking non username:password@encoded > websites? > > > > We're starting to take complaints from folks who have installed the > latest IE patch about various broken website functionality. The > complaints are not related to folks trying to use the username:password@ > functionality that was removed by the patch. > > Is anyone taking similar calls / seeing similar issues? > > Herman Harless > Director, Advanced Data Network Engineering and Operations NTELOS, Inc. > herman(a)ntelos.net > > > > > --- > [This E-mail scanned for viruses] > > >

2 1

Re: Poor connectivity to new b.root-servers.net address?
by Simon Waters 03 Feb '04

03 Feb '04

NANOG Digest wrote: > > 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 178.710 ms 178.529 ms 178.500 ms > 14 * * * > 15 130.152.181.66 (130.152.181.66) 177.340 ms 177.246 ms 177.298 ms > 16 * * * I see something similar to this coming out of Level3 from Demon's direction. The was mentioned in comp.protocols.dns.bind, where some additional traceroutes and information is available, although it is clearly(?) a routing issue and I suggested here was a good place to ask for help. Still we have enough root servers to be going on with while it is fixed, lets just hope no one hijacked it.

5 7

Re: Strange public traceroutes return private RFC1918 addresses
by Kevin Oberman 03 Feb '04

03 Feb '04

> From: "Terry Baranski" <tbaranski(a)mail.com> > Date: Tue, 3 Feb 2004 16:42:55 -0600 > Sender: owner-nanog(a)merit.edu > > > Leo Bicknell wrote: > > > Since most POS is 4470, adding a jumbo frame GigE edge makes > > this application work much more efficiently, even if it doesn't > > enable jumbo (9k) frames end to end. The interesting thing > > here is it means there absolutely is a PMTU issue, a 9K edge > > with a 4470 core. > > This brings up the question of what other MTUs are common on the > Internet, as well as which ones are simply defaults (i.e., could easily > be increased) and which ones are the result of device/protocol > limitations. > > And why 4470 for POS? Did everyone borrow a vendor's FDDI-like default > or is there a technical reason? PPP seems able to use 64k packets (as > can the frame-based version of GFP, incidentally, POS's likely > replacement). 4470 was, as you surmised, to allow a full sized FDDI packet to be packed into a single POS packet. At the time FDDI was using larger packets than anything else. Now the recommendation for research and education networks (Abilene, ESnet, NASA, and many Asian and European R&Es) is 9000 and, within that community, is almost universally adopted when the hardware will support it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

1 0

Re: B.root-servers renumbering
by Daniel Kerr 03 Feb '04

03 Feb '04

On Jan 30, 2004, at 4:26 AM, John L Crain wrote: <snip> > New Hints files can be found at: > > ftp://rs.internic.net/domain/db.cache > ftp://rs.internic.net/domain/named.cache > ftp://rs.ineternic.net/domain/named.root neophyte@afi:~$ whois ineternic.net Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. No match for "INETERNIC.NET". Cheers, -- Daniel Kerr

2 1

Poor connectivity to new b.root-servers.net address?
by sthaug＠nethelp.no 03 Feb '04

03 Feb '04

I have two sites (in AS 2116 and 3307) here in Norway which cannot reach the new b.root-servers.net address, 192.228.79.201. No answers to DNS requests, no ping replies, traceroute times out. Everything works normally from a third site, in AS 224. Both prefixes (193.71.0.0/16 and 194.19.0.0/17) of the problem addresses are visible on route-views.oregon-ix.net, via multiple paths. Any suggestions why this is happening? Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no --------------------------------------------------- traceroute from AS 2116 (source address 193.71.2.2): 1 vortex-e1 (193.69.2.1) 0.211 ms 0.168 ms 0.148 ms 2 v560.rs1.osl-sand.inet.catchcom.no (193.75.4.117) 0.364 ms 0.376 ms 0.324 ms 3 ge-0-2-0-202.br3.gaus.no.catchbone.net (193.75.3.61) 0.831 ms 0.991 ms 0.718 ms 4 so-0-3-0.ar1.OSL1.gblx.net (64.213.23.65) 0.728 ms 0.717 ms 0.824 ms 5 pos12-0-2488M.cr2.HAM1.gblx.net (67.17.74.185) 18.857 ms 18.855 ms 19.101 ms 6 so0-0-0-2488M.cr2.LON3.gblx.net (67.17.64.38) 43.637 ms 43.511 ms 43.546 ms 7 so7-0-0-2488M.ar2.LON3.gblx.net (67.17.66.30) 43.604 ms 43.869 ms 43.626 ms 8 Level-3public-peering.ge-5-0-0.ar2.LON3.gblx.net (208.51.239.162) 43.768 ms 43.852 ms 43.923 ms 9 ae-0-55.mp1.London1.Level3.net (212.187.131.161) 44.186 ms 44.197 ms 44.149 ms 10 so-1-0-0.mp1.London2.Level3.net (212.187.128.49) 44.388 ms 44.417 ms 44.245 ms 11 so-1-0-0.bbr1.Washington1.Level3.net (212.187.128.138) 117.160 ms 117.296 ms 116.990 ms 12 so-3-0-0.mpls1.Tustin1.Level3.net (209.247.8.121) 178.607 ms 178.837 ms 178.576 ms 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 178.710 ms 178.529 ms 178.500 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 177.340 ms 177.246 ms 177.298 ms 16 * * * traceroute from AS 3307 (source address 194.19.15.2): 1 nethelp-gw.banetele.net (194.19.15.1) 0.987 ms 0.891 ms 0.882 ms 2 oslo-a2.banetele.net (194.19.80.13) 6.389 ms 6.234 ms 6.205 ms 3 sand.osl.banetele.net (194.19.81.45) 6.498 ms 6.337 ms 6.332 ms 4 if-1-2.core2.Oslo.teleglobe.net (80.231.89.21) 7.128 ms 6.739 ms 6.796 ms 5 if-5-0.core1.Oslo.teleglobe.net (80.231.88.5) 119.151 ms 119.004 ms 119.184 ms 6 if-4-11.core2.London2.teleglobe.net (80.231.88.14) 210.376 ms 199.959 ms 206.017 ms 7 if-9-0.core2.Newark.Teleglobe.net (66.110.8.141) 118.323 ms 118.300 ms 118.073 ms 8 if-7-0.core1.Newark.Teleglobe.net (207.45.222.161) 117.308 ms 117.072 ms 116.978 ms 9 if-5-0.core2.Ashburn.Teleglobe.net (66.110.8.17) 116.370 ms 116.979 ms 116.195 ms 10 so-1-2-0.e1.Washington1.Level3.net (65.59.88.209) 113.998 ms 113.905 ms 113.767 ms 11 so-2-1-0.bbr1.Washington1.Level3.net (209.244.11.9) 114.371 ms 113.935 ms 113.795 ms 12 so-1-0-0.mpls2.Tustin1.Level3.net (209.247.8.117) 183.813 ms 183.557 ms 183.711 ms 13 so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 183.242 ms 183.647 ms so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 183.154 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 182.641 ms 182.046 ms 185.201 ms 16 * * * traceroute from AS 224 (source address 129.241.1.16): 1 runit-sw1.runit.no (129.241.1.1) 5.753 ms 2.719 ms 0.953 ms 2 runit-gw.runit.no (129.241.249.77) 15.607 ms 13.284 ms 16.016 ms 3 trd-gw (129.241.249.14) 14.025 ms 14.839 ms 10.817 ms 4 oslo-gw1 (128.39.46.1) 22.427 ms 18.854 ms 20.827 ms 5 no-gw.nordu.net (193.10.68.101) 18.472 ms 20.159 ms 21.216 ms 6 se-kth.nordu.net (193.10.68.29) 29.554 ms 29.238 ms 29.233 ms 7 so-1-0.hsa2.Stockholm1.Level3.net (213.242.69.21) 28.094 ms 27.161 ms 29.325 ms 8 so-4-1-0.mp2.Stockholm1.Level3.net (213.242.68.205) 30.072 ms 27.242 ms 25.611 ms 9 so-0-0-0.mp1.London2.Level3.net (212.187.128.61) 61.408 ms 59.909 ms 65.957 ms 10 so-1-0-0.bbr1.Washington1.Level3.net (212.187.128.138) 137.661 ms 134.997 ms 136.561 ms 11 so-1-0-0.mpls2.Tustin1.Level3.net (209.247.8.117) 196.734 ms 198.486 ms 202.194 ms 12 so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 201.479 ms 199.805 ms so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 198.810 ms 13 67.30.130.66 (67.30.130.66) 216.913 ms 215.330 ms 214.481 ms 14 130.152.181.66 (130.152.181.66) 214.449 ms 217.795 ms 211.176 ms 15 b.root-servers.net (192.228.79.201) 216.927 ms 211.889 ms 213.429 ms

3 2

Re: antivirus in smtp, good or bad?
by Daniel Senie 03 Feb '04

03 Feb '04

At 08:58 AM 2/3/2004, you wrote: >Hi, > When investigating our mail queue it seems we have quite a lot of mails > which >are stuck in transit... > >Whats happening is we're accepting the mail as the primary MX for the >domain but >the user has setup a forwarding to another account at another ISP, they have >antivirus service on that other account. So we get the mail, spool it and >try to >forward it but then we get a "550 Error: Suspected W32/MyDoom@MM virus" after >DATA and our server freezes the mail. Hmmm, well, we certainly kick back virus-laden stuff this way. The alternatives are: 1) kick it back during SMTP. 2) drop it on the floor. or, the third option, which is EXCEEDINGLY BROKEN, 3) send a bounce to the From: address in the email. Because of spoofed sender addresses, this then goes to the wrong person, freaks out innocent, non-infected people and raises everyone's support costs. >Surely this is an incorrect way to do this as there will be lots of >similar MXs >like ours backing this mail up? They should accept the mail and then >bounce it? Why must systems accept mail that's virus laden or otherwise not desired at a site? The "bounce" you refer to invariably ends up going to the wrong person(s), so that's an exceptionally BAD idea. Many viruses (most of the recent ones) forge the sender information. So either accepting and silently dropping, or rejecting the SMTP session with a 55x are the only viable choices.

5 8

Re: [OT] Need Comcast Contact
by Tim Wesemann 03 Feb '04

03 Feb '04

> Well sure, they are sent on a date that doesn't exist. Feb 31 can never > happen. Pardon, that should have read Sunday, Feb 01 2004 AD (Chinese year of the monkey). =] -- Tim Wesemann Voicenet Systems Administration

1 0

does your ISP need more peering?
by Matthew Kaufman 03 Feb '04

03 Feb '04

A nationwide ISP I work with has decided to switch to all-transit, no-peering. They are interested in finding someone to buy or take over: an AS number, routers (and in some cases rack space) at MAE ATM East, PAIX Virginia, NYIIX, AADS NAP, MAE ATM West, and PAIX Palo Alto, along with the existing peering that is up at those (close to 200 BGP sessions total). If you're interested, please contact me directly and I will forward your inquiry in the correct direction. Note that my mailbox is protected by TMDA. Matthew Kaufman matthew(a)eeph.com ps. Please also direct flames about this being non-operational content directly to me as well... there's just not a lot of lists where names of NAPs and the concept of existing peers makes sense to anyone.

1 0

[OT] Need Comcast Contact
by Tim Wesemann 03 Feb '04

03 Feb '04

Emails sent *from residential comcast subscribers* to any '@voicenet.com' address have been disappearing in the Comcast network since Sunday, Feb 31. There are no bounces or errors of any kind. Mail sent directly to other domains with the same MX record and even to individual machines within the MX record themselves work fine, it is only when the envelope recipient states /^.*(a)voicenet\.com$/ does the mail simply disappear (i.e. mail sent to "someuser(a)voicenet.com" disappears while mail sent to "someuser(a)mail##.voicenet.com" goes through fine as well as "someuser(a)voicenet.net"). My company as well as our customers and Comcast customers have together made many, many phone calls and sent many emails and we cannot get ahold of anyone with any semblance of a clue and nobody seeems to have the ability to put us in contact with anyone in your systems and/or network admins (level 1-3 techs, managers and even "case resolution specialists"). Can someone please contact me off-list in regards to this situation? Has anyone else had similar problems? Thanks. -- Tim Wesemann Voicenet Systems Administration

1 0