Hi,
Not strictly a North American problem but I was wondering if anyone had seen
this behaviour.
We currently have two blocks of IP address space, 195.224.206/24 and
193.193.186/23. Everything works fine from 195.224.206 but from 193.193.186
there are often problems accessing web servers - either they don't respond for
ages then are suddenly OK, send just the headers in response to a GET request
then stop or just plain don't respond to HTTP queries at all. This appears to
happen mostly with Netscape servers although I only have a few examples so far
so I'm not sure. (www.real.com, www.cisco.com, www.etrade.com, www.bt.com)
We also have two lines out of the building, although I've tried routing in
various ways and the problem seems to follow the IP address rather than the
outbound line. (IP addresses are, for the moment, tied to the line until we
get BGP on the line currently serving 195.224.206/24 however I can't see how
this could be an inbound line problem.)
I believe this to be a DNS problem as I can't see anything else that could be
causing a problem - it doesn't seem to matter what web browser is used (IE,
Netscape, Lynx or even telnet) or if a web cache (Squid) is used or not.
There are three reverse DNS servers in totally different locations (One on our
site, one on the UK Joint Academic Network and one in Switzerland) so I don't
think part of the net being unreacable from somewhere can be the problem.
The only *POSSIBLE* explanation I can come up with is that the IPv6 AAAA
entries for 193.in-addr.arpa are confusing some nameservers and causing this
problem. I'm really grasping at straws though - does anyone have even the
slightest idea what cound be going on? (Even off-list wild-guess suggestions
would be appreciated.)
Thanks.
I also had one to ti.com bounce.
D.
In article <4.1.19990817105005.00a44360@mailhost.broadcast.com>,
ddivinia@broadcast.com (Darin Divinia) wrote:
I also had one to ti.com bounce.
At about 9:30 UTC h.root-servers.net was returning NXDOMAIN for most
though not all .com domains. For example, amazon.com and netsol.com
were broken.
msrl.com worked, but all of its nameservers are in .net; ibm.com
worked, but all of its nameservers are within ibm.com and are covered
by glue records. The pattern seemed to be that any domain with all of
its nameservers in .com but outside of its own zone would fail to
resolve from h.root-servers.net. I only tried about a dozen domains
so the actual pattern may have been different.
I sent a mail this morning to hostmaster@internic.net (with no
response of course, but that's the SOA contact for .) and cc'd to
nanog (but I had neglected to subscribe to nanog-post).
It's interesting that there was no mention of this outage, which
caused hard mail bounces and other problems.
One of my clients in the Caribbean is seeing similar behavior. Some
websites are reachable, others not. It's not clear if this is DNS or
some sort of core routing instability.
Your message said you see everything fine from one netblock you have,
but not from another. This sounds like someone's messing with
advertisements and perhaps made a mess. It also correlates with data
I've seen from other clients in other locales.
We currently have two blocks of IP address space, 195.224.206/24 and
193.193.186/23. Everything works fine from 195.224.206 but from
193.193.186 there are often problems [...]
Did you try registering a "route" object for 193.193.186.0/23 in the
routing registry? That might improve connectivity to those addresses.
At least from here (Switzerland) we don't see the announcement for
193.193.186.0/23 from our European transit provider, presumably
because it is filtered out.
swiCE1>trace 195.224.206.1
Type escape sequence to abort.
Tracing the route to gatekeeper.olf.co.uk (195.224.206.1)
1 switch.ch.ten-155.net (212.1.192.169) [AS 8933] 4 msec 4 msec 0 msec
2 ch-se.se.ten-155.net (212.1.192.46) [AS 8933] 52 msec 52 msec 52 msec
3 sw-gw.nordu.net (212.1.192.154) [AS 8933] 52 msec 52 msec 52 msec
4 west-gw.nordu.net (193.10.252.133) [AS 2603] 52 msec 52 msec 52 msec
5 et0-llb-x-dg.DG1.core.rtr.xara.net (194.68.128.46) 92 msec 92 msec 92 msec
6 at0-0-llb-pvc202-dg1.TH1.core.rtr.xara.net (194.143.164.105) [AS 5519] 92 msec 92 msec 92 msec
7 fd1-0-0-llb-x-many.TH28.core.rtr.xara.net (194.143.163.36) [AS 5519] 92 msec 92 msec 92 msec
8 hs0-0-0-llb-th28.HE1.core.rtr.xara.net (194.143.164.166) [AS 5519] 92 msec 92 msec 96 msec
9 fd1-1-0-llb-x-many.HE2.core.rtr.xara.net (194.143.163.114) [AS 5519] 92 msec 96 msec 96 msec
10 fd5-0-0-llb-x-many.HE5.core.rtr.xara.net (194.143.163.115) [AS 5519] 96 msec 92 msec 92 msec
11 olf-avnet-router.olf.co.uk (195.224.74.230) [AS 5519] 104 msec 104 msec
se0-xfs-d600-he5.aviators.cust.rtr.xara.net (195.224.219.105) [AS 5519] 96 msec
12 olf-avnet-router.olf.co.uk (195.224.74.230) [AS 5519] 100 msec 100 msec 100 msec
13 olf-router-01.olf.co.uk (193.193.186.254) 128 msec 168 msec 172 msec
14 gatekeeper.olf.co.uk (195.224.206.1) [AS 5519] 112 msec 120 msec 144 msec
swiCE1>trace 193.193.186.1
Type escape sequence to abort.
Tracing the route to gatekeeper.olf.co.uk (193.193.186.1)
1 swiEZ1-A0-0-0-8.switch.ch (130.59.33.26) 8 msec 4 msec 8 msec
2 swiEG1-F1-0-0.switch.ch (130.59.20.211) 4 msec 8 msec 4 msec
3 swiNY1-A5-0-0-1.switch.ch (130.59.33.2) 100 msec 100 msec 100 msec
4 39.atm4-0-0.GW3.NYC4.ALTER.NET (157.130.13.61) 104 msec 100 msec 100 msec
5 110.ATM2-0.XR1.NYC4.ALTER.NET (152.63.21.202) 100 msec 100 msec 100 msec
6 189.ATM2-0.TR1.NYC1.ALTER.NET (146.188.179.18) 104 msec 100 msec 104 msec
7 104.ATM5-0.TR1.DCA1.ALTER.NET (146.188.136.213) 104 msec 108 msec 104 msec
8 199.ATM7-0.XR1.DCA1.ALTER.NET (146.188.161.133) 104 msec 104 msec 108 msec
9 195.ATM9-0-0.GW3.DCA1.ALTER.NET (146.188.161.77) 108 msec 112 msec 108 msec
10 abovenet-dca-gw.customer.ALTER.NET (157.130.37.254) 108 msec 104 msec 108 msec
11 main1-core1-oc3-1.iad.above.net (209.249.0.18) 108 msec 272 msec 104 msec
12 u-net.customers.iad.above.net (209.249.97.37) 156 msec 200 msec 168 msec
13 195.102.254.61 [AS 5669] 180 msec 192 msec 156 msec
14 195.102.254.70 [AS 5669] 172 msec 160 msec 180 msec
15 195.102.208.214 [AS 5669] 184 msec 192 msec 188 msec
16 gatekeeper.olf.co.uk (193.193.186.1) 180 msec 192 msec 208 msec
Problem appears to be MTU related - if I reduce the ethernet MTU to 1400 on
the web cache everything runs fine. (Cheers to Rush at GX Networks for
suggesting this) I've yet to find a common router though.
Upon further investigation mail appeared to be OK because failed mail is going
to our backup MX which reachs us via a different route.
I have a potential need to get traffic into Mexico for multi-media. It's
pretty regular high-band-width stuff. If anyone can help, please send
reply directly to me. I'm on NANOG, but only monitor it indirectly.