Okay, so I've been reading this thread on L3, and I'm a little curious as to what this potential de-peering means in one unique situation.
A friend of mine has got a colo box sitting, single-homed, in a (3) data center. At the end of this, is this going to mean I can't reach Cogent? I've seen something in the discussions that imply this will be the case, but am not ultimately sure.
Then again, is anyone?
Thanks,
-Dan
Yes. When Level3 depeers Cogent again, unless Cogent buys transit to or makes other arrangements for reaching Level3, you will be unable to reach single-homed Cogent customers (or Cogent itself) from your friend's single-homed Level3 colo...as you were when Level3 depeered Cogent previously.
Dan Mahoney, System Admin wrote:
Okay, so I've been reading this thread on L3, and I'm a little curious as to what this potential de-peering means in one unique situation.
I means, here in germany we cannot see h.root-servers.net
soa(".","2005102201","a.root-servers.net","198.41.0.4").
soa(".","2005102201","b.root-servers.net","192.228.79.201").
soa(".","2005102201","c.root-servers.net","192.33.4.12").
soa(".","2005102201","d.root-servers.net","128.8.10.90").
soa(".","2005102201","e.root-servers.net","192.203.230.10").
soa(".","2005102201","f.root-servers.net","192.5.5.241").
soa(".","2005102201","g.root-servers.net","192.112.36.4").
error(".","h.root-servers.net","128.63.2.53","no response").
soa(".","2005102201","i.root-servers.net","192.36.148.17").
soa(".","2005102201","j.root-servers.net","192.58.128.30").
soa(".","2005102201","l.root-servers.net","198.32.64.12").
soa(".","2005102201","m.root-servers.net","202.12.27.33").
Ok, it is only one of the root servers. But have a look who
h.root-servers.net is. It is one of the originals not an
anycasted copy.
Maybe it is only dtag.de the uplink of my ISP but they are
the uplink of mostly any ISP here in germany.
I guess half of the world cannot reach your site and they
cannot even send you an email to tell you.
Here is my traceroute to h.root-servers.net right now:
2005-10-23 (296) 11:48:46 loc
2005-10-23 (296) 09:48:46 UTC
traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 40 byte packets
1 echnaton.lomiheim (192.168.48.228) 4.675 ms 5.587 ms 6.364 ms
2 DARX41-erx (217.0.116.49) 116.568 ms 132.257 ms 137.536 ms
3 sepia (217.0.67.106) 119.249 ms 124.106 ms 134.971 ms
4 62.156.131.150 230.077 ms 233.444 ms 237.907 ms
5 sl-gw31-nyc-12-0.sprintlink.net (144.223.27.133) 248.150 ms 254.276 ms 262.928 ms
6 sl-bb23-nyc-12-0.sprintlink.net (144.232.13.33) 271.683 ms 278.948 ms 286.979 ms
7 sl-bb20-nyc-8-0.sprintlink.net (144.232.7.13) 288.615 ms 296.159 ms 304.545 ms
8 0.so-2-3-0.BR1.NYC4.ALTER.NET (204.255.174.225) 153.352 ms 160.090 ms 168.617 ms
9 0.so-6-0-0.XL1.NYC4.ALTER.NET (152.63.21.78) 177.012 ms * 184.325 ms
10 0.so-7-0-0.XL1.CHI2.ALTER.NET (152.63.68.81) 202.066 ms 205.084 ms 207.531 ms
11 POS6-0.GW10.CHI2.ALTER.NET (152.63.69.169) 214.184 ms 221.166 ms 228.862 ms
12 0.so-3-3-0.dng.dren.net (65.195.244.54) 323.133 ms * 325.671 ms
13 so12-0-0-0.arlapg.dren.net (138.18.1.3) 373.705 ms 381.351 ms 393.036 ms
14 * * *
; <<>> DiG 9.1.3 <<>> . @h.root-servers.net
;; global options: printcmd
;; connection timed out; no servers could be reached
A friend of mine has got a colo box sitting, single-homed, in a (3) data center. At the end of this, is this going to mean I can't reach Cogent? I've seen something in the discussions that imply this will be the case, but am not ultimately sure.
Then again, is anyone?
I am shure I cannot reach h-root-servers.net and a lot of other sites.
Here is what I see from another host in the netherlands:
traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 40 byte packets
1 Bifroest (84.22.100.1) 0.181 ms 0.156 ms 0.155 ms
2 Charybdis (84.22.96.245) 2.016 ms 3.895 ms 3.545 ms
3 217.195.244.142 104.799 ms 103.670 ms 102.902 ms
4 213.201.252.230 103.338 ms 101.735 ms 100.100 ms
5 ge0-0-0-1.gr0.tcams.nl.easynet.net (207.162.205.113) 98.449 ms 96.802 ms 95.168 ms
6 so0-1-0-0.gr0.tclon.uk.easynet.net (207.162.205.49) 101.366 ms 100.190 ms 98.656 ms
7 ge0-3-0-0.gr1.thlon.uk.easynet.net (207.162.205.21) 96.926 ms 95.480 ms 93.871 ms
8 ge0-0-0-0.gr0.thlon.uk.easynet.net (207.162.198.12) 92.276 ms 90.543 ms *
9 ge0-2-0-0.gr0.bllon.uk.easynet.net (207.162.205.13) 22.415 ms 21.672 ms 20.266 ms
10 br0.bllon.uk.easynet.net (207.162.204.5) 21.576 ms 20.171 ms 23.452 ms
11 ge-1-0-0-0.br0.tclon.uk.easynet.net (82.108.6.122) 21.855 ms 20.237 ms 21.863 ms
12 ge0-0-0-0.br0.thlon.uk.easynet.net (195.172.211.205) 20.422 ms 23.193 ms 21.581 ms
13 ip-217-204-60-90.easynet.co.uk (217.204.60.90) 20.976 ms 20.646 ms 20.409 ms
14 ge-5-0-2.402.ar2.LON3.gblx.net (67.17.212.93) 90.475 ms 89.058 ms 87.318 ms
15 so6-0-0-2488M.ar2.NYC1.gblx.net (67.17.64.158) 97.484 ms 110.351 ms 108.752 ms
16 POS1-0.BR3.NYC8.ALTER.NET (204.255.168.133) 107.855 ms POS1-1.BR3.NYC8.ALTER.NET (204.255.168.61) 106.842 ms 118.576 ms
17 0.so-5-2-0.XL1.NYC8.ALTER.NET (152.63.19.54) 118.120 ms 116.336 ms 114.644 ms
18 0.so-7-0-0.XL1.CHI2.ALTER.NET (152.63.68.81) 137.482 ms 135.923 ms 134.144 ms
19 POS6-0.GW10.CHI2.ALTER.NET (152.63.69.169) 132.387 ms 130.567 ms 129.078 ms
20 0.so-3-3-0.dng.dren.net (65.195.244.54) 116.936 ms 116.027 ms 114.271 ms
21 so12-0-0-0.arlapg.dren.net (138.18.1.3) 126.768 ms 125.046 ms 126.627 ms
22 cperouter.arlapg.dren.net (138.18.21.2) 126.067 ms 124.259 ms 127.054 ms
23 * * *
; <<>> DiG 9.2.4 <<>> . @h.root-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 202
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;. IN A
;; AUTHORITY SECTION:
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com.\
2005102201 1800 900 604800 86400
;; Query time: 128 msec
;; SERVER: 128.63.2.53#53(h.root-servers.net)
;; WHEN: Sun Oct 23 11:56:48 2005
;; MSG SIZE rcvd: 92
Thanks,
-Dan
--
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
Kind regards,
Peter and Karin Dambier
I means, here in germany we cannot see h.root-servers.net
Nonsense. There is nothing like "geopolitical routing".
Ok, it is only one of the root servers. But have a look who
h.root-servers.net is. It is one of the originals not an
anycasted copy.
And it's not singlehomed to Cogent.
Maybe it is only dtag.de the uplink of my ISP but they are
the uplink of mostly any ISP here in germany.
Absolute nonsense again.
Here is my traceroute to h.root-servers.net right now:
So, where do you see a problem related to L3/Cogent there? Your
traceroute hits DREN, the operator of h.root-servers.net.
; <<>> DiG 9.1.3 <<>> . @h.root-servers.net
;; global options: printcmd
;; connection timed out; no servers could be reached
DREN seems to have a problem there. I can see absolutely NO connection
to any L3/Cogent dispute.
And testing from DTAG 84/8 space myself I have the same prob. Perhaps
some bogus anti-bogon-filters at DREN in place?
Please stop your constant flood of nonsense and misinformation to the
NANOG mailing list. Thank you.
Daniel
* Daniel Roesen:
I means, here in germany we cannot see h.root-servers.net
Nonsense. There is nothing like "geopolitical routing".
I wouldn't call it "geopolitical routing", "routing according to local
policy" is more appropriate. And it's quite common (especially in
Germany, for quite a few reasons).
DREN seems to have a problem there.
Not clear to me. A traceroute with the wrong protocol (i.e. not
53/UDP nor 53/TCP) is not particularly enlightening.
I can see absolutely NO connection to any L3/Cogent dispute.
This is something I can agree with. 
A friend of mine has got a colo box sitting, single-homed
friends don't let friends home singly
randy
>> I means, here in germany we cannot see h.root-servers.net
>
> Nonsense. There is nothing like "geopolitical routing".I wouldn't call it "geopolitical routing", "routing according to local
policy" is more appropriate. And it's quite common (especially in
Germany, for quite a few reasons).
He talked about "here in germany". "germany" is a nonexistant entity
in BGP and global routing. You cannot talk about observation of
connectivity problems with location specification in terms of
"countries".
> DREN seems to have a problem there.
Not clear to me. A traceroute with the wrong protocol (i.e. not
53/UDP nor 53/TCP) is not particularly enlightening.
I did the traces myself, with dest port 53. I'm not stupid (at least
not that much). Given that DREN is the operator of the root server, and
the trace ends _within_ DREN, it's highly likely that the problem is
inside DREN. Anyway, even that can be filtered by a firewall with
protocol inspection, and the actual problem can be on the path back.
This is why I said "seems to be", not "is".
Regards,
Daniel
Daniel Roesen wrote:
He talked about "here in germany". "germany" is a nonexistant entity
in BGP and global routing. You cannot talk about observation of
connectivity problems with location specification in terms of
"countries".
Hi Daniel,
I thought it might make more sense telling where I am than saying
downstream of DARX41-erx (217.0.116.49)
And here is the traceroute repeated for port 53 udp:
host_name("84.167.253.32","p54A7FD20.dip.t-dialin.net").
/usr/sbin/traceroute -p 53 h.root-servers.net
traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 40 byte packets
1 echnaton.lomiheim (192.168.48.228) 4.835 ms 5.754 ms 6.609 ms
2 DARX41-erx (217.0.116.49) 102.306 ms 109.711 ms 121.313 ms
3 sepia (217.0.67.106) 125.160 ms 132.543 ms 140.217 ms
4 62.156.131.150 230.469 ms 237.826 ms 245.680 ms
5 sl-gw31-nyc-12-0.sprintlink.net (144.223.27.133) 255.599 ms 263.358 ms 271.387 ms
6 sl-bb23-nyc-12-0.sprintlink.net (144.232.13.33) 280.600 ms 287.696 ms 296.003 ms
7 sl-bb20-nyc-8-0.sprintlink.net (144.232.7.13) 242.799 ms 250.392 ms 367.674 ms
8 0.so-2-3-0.BR1.NYC4.ALTER.NET (204.255.174.225) 156.870 ms 164.751 ms 172.858 ms
9 0.so-6-0-0.XL1.NYC4.ALTER.NET (152.63.21.78) 182.478 ms 189.745 ms 197.843 ms
10 0.so-7-0-0.XL1.CHI2.ALTER.NET (152.63.68.81) 239.347 ms 246.224 ms 254.247 ms
11 POS6-0.GW10.CHI2.ALTER.NET (152.63.69.169) 262.775 ms 270.860 ms 277.932 ms
<<no answer beyond this point>>
This traceroute is for the system that can dig h.root-servers.net.
This system lives downstream of host_name("84.22.96.245","cb-sr1-e0.cb3rob.net").
host_name("84.22.100.150","tourelle.serveftp.com").
/usr/sbin/traceroute -p 53 h.root-servers.net
traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 40 byte packets
1 Bifroest (84.22.100.1) 0.186 ms 0.155 ms 0.157 ms
2 Charybdis (84.22.96.245) 1.555 ms 3.820 ms 3.135 ms
3 217.195.244.142 11.756 ms 16.716 ms 15.451 ms
4 213.201.252.230 14.394 ms 13.954 ms 12.179 ms
5 ge0-0-0-1.gr0.tcams.nl.easynet.net (207.162.205.113) 13.406 ms 12.134 ms 13.903 ms
6 so0-1-0-0.gr0.tclon.uk.easynet.net (207.162.205.49) 21.128 ms 28.479 ms 27.220 ms
7 ge0-3-0-0.gr1.thlon.uk.easynet.net (207.162.205.21) 25.672 ms 24.268 ms 22.498 ms
8 ge0-0-0-0.gr0.thlon.uk.easynet.net (207.162.198.12) 30.448 ms 29.706 ms 28.133 ms
9 ge0-2-0-0.gr0.bllon.uk.easynet.net (207.162.205.13) 27.087 ms 25.549 ms 21.555 ms
10 br0.bllon.uk.easynet.net (207.162.204.5) 20.339 ms 27.891 ms 26.280 ms
11 ge-1-0-0-0.br0.tclon.uk.easynet.net (82.108.6.122) 25.986 ms 25.646 ms 37.109 ms
12 ge0-0-0-0.br0.thlon.uk.easynet.net (195.172.211.205) 32.720 ms 31.975 ms 31.447 ms
13 ip-217-204-60-90.easynet.co.uk (217.204.60.90) 29.707 ms 25.448 ms 21.981 ms
14 ge-5-0-2.402.ar2.LON3.gblx.net (67.17.212.93) 18.514 ms 21.786 ms 21.109 ms
15 so6-0-0-2488M.ar2.NYC1.gblx.net (67.17.64.158) 89.241 ms 91.517 ms 91.639 ms
16 POS1-1.BR3.NYC8.ALTER.NET (204.255.168.61) 90.138 ms 92.526 ms
POS1-0.BR3.NYC8.ALTER.NET (204.255.168.133) 90.929 ms
17 0.so-5-2-0.XL1.NYC8.ALTER.NET (152.63.19.54) 90.694 ms 89.473 ms 90.154 ms
18 0.so-7-0-0.XL1.CHI2.ALTER.NET (152.63.68.81) 115.216 ms 113.511 ms 116.485 ms
19 POS6-0.GW10.CHI2.ALTER.NET (152.63.69.169) 114.734 ms 115.800 ms 114.189 ms
20 0.so-3-3-0.dng.dren.net (65.195.244.54) 113.536 ms * *
21 * * *
Please note it is the same 84/8 so I dont think it is about the old 84.0.0.0 bogon.
I know of one host here in germany who can see h.root-servers.net. That host is
living in a KPN data centre directly connected to Amterdam IX. All others I have
asked cannot see h.root-servers.net.
ISPs used were t-online, gmx, heag-media, arcor, aol and manet.
Kind regards,
Peter Dambier
* peter@peter-dambier.de (Peter Dambier) [Sun 23 Oct 2005, 22:34 CEST]:
I know of one host here in germany who can see h.root-servers.net. That host is living in a KPN data centre directly connected to Amterdam IX.
Peter, please stop posting nonsense.
-- Niels.
No, why don't you stop insulting people, Niels. You attack Peter because
of his involvment in the Inclusive Namespace. FYI: Public root servers
are online and available. Maybe the h-root ops should ask the P-R technical
committee for assistance if they cannot keep their servers up.
h-root-servers.net works now,
even from dtag.de
It was not about level 3.
It was a firewall.
Kind regards
Peter and Karin Dambier
John,
I disagree. A person lacking the clues so badly and wildly
guessing (and posting it) is dangerous and has to be told.
I would prefer to see more research before such nonsense is
posted again. But with this being the 20th time for this
person I do not see that works. Procmail helps, but it still
surfaces again and again it seems.
Regards,
Alexander
> I means, here in germany we cannot see h.root-servers.net
> Here is my traceroute to h.root-servers.net right now:
So, where do you see a problem related to L3/Cogent there? Your
traceroute hits DREN, the operator of h.root-servers.net.
agreed, looks like a dren 'issue' which MAY be a planned event? DREN
probably shouldn't filter traffic to/from h-root (aside from udp/53 |
tcp/53 traffic) no 'prefix-X not allowed to have access to h-root' sorts
of things) That said, they MAY have done that, did someone (peter?) ask
them?
> ; <<>> DiG 9.1.3 <<>> . @h.root-servers.net
> ;; global options: printcmd
> ;; connection timed out; no servers could be reachedDREN seems to have a problem there. I can see absolutely NO connection
to any L3/Cogent dispute.And testing from DTAG 84/8 space myself I have the same prob. Perhaps
some bogus anti-bogon-filters at DREN in place?
That could be as well, I might be able to ask them perhaps as well.
I dunno. I got a lot of single-homed friends. If I got them all
to multihome, and everybody else on NANOG got all *their* single-homed
friends multihome, it might do something suboptimal to the routing tables.
Do we *really* want to do anything to encourage a higher burn rate of AS numbers
before we've deployed 32-bit AS number support?
Do we *really* want to do anything to encourage a higher burn rate of AS numbers
before we've deployed 32-bit AS number support?
Consider it a looming incentive to do so.
Fundamently, if economic decisions create holes in the routing infrastucture, it seems likely if not inevitable that the people who are adversly affected will plug the hole from their perspective before it affects their bottom line. Obviously it has a cost both locally and globally, but a few more people tune their risk mangement model (or decide they need one) everytime this happens.
joelja
Dear John,
No, why don't you stop insulting people, Niels. You attack Peter because
of his involvment in the Inclusive Namespace. FYI: Public root servers
are online and available. Maybe the h-root ops should ask the P-R technical
committee for assistance if they cannot keep their servers up.
Peter Dambier did post nonsense. In fact, it was total nonsense since
the AMS-IX is not present in any KPN datacentre, *and* it is impossible
for end-hosts to connect to the AMS-IX directly.
Niels his post was correctly and imho not insultive.
Christopher L. Morrow wrote:
I means, here in germany we cannot see h.root-servers.net
Here is my traceroute to h.root-servers.net right now:
So, where do you see a problem related to L3/Cogent there? Your
traceroute hits DREN, the operator of h.root-servers.net.agreed, looks like a dren 'issue' which MAY be a planned event? DREN
probably shouldn't filter traffic to/from h-root (aside from udp/53 |
tcp/53 traffic) no 'prefix-X not allowed to have access to h-root' sorts
of things) That said, they MAY have done that, did someone (peter?) ask
them?
I did ask them.
Told me it was a firewall misshap.
Problem is solved now.
Thanks,
Peter and Karin Dambier
Sabri Berisha wrote:
Peter Dambier did post nonsense. In fact, it was total nonsense since
the AMS-IX is not present in any KPN datacentre, *and* it is impossible
for end-hosts to connect to the AMS-IX directly.
Part of the traceroutes between me and the system I was talking of:
6 da-ea1.DA.DE.net.DTAG.DE (62.153.179.54) 18.334 ms 22.725 ms 33.803 ms
4 ams-e4.AMS.NL.net.DTAG.DE (62.154.15.2) 145.264 ms 152.212 ms 160.623 ms
5 amx-gw2.nl.dtag.de (195.69.145.211) 14.737 ms 13.115 ms 11.501 ms
5 gb-2-0-0.amsix1.tcams.nl.easynet.net (195.69.144.38) 169.072 ms 176.623 ms 184.463 ms
4 213.201.252.133 19.577 ms 17.808 ms 16.000 ms
6 213.201.252.10 194.043 ms 201.762 ms 209.455 ms
3 217.195.244.142 21.561 ms 21.339 ms 20.145 ms
7 Scylla (213.201.229.65) 156.335 ms 164.501 ms 171.735 ms
To my eyes it looks like the data is going through Amsterdam IX.
I did not say the host was connected to the IX. I said it was living in a
datacentre connected to Amsterdam IX.
The costumer pays for the ISP beeing present at Amsterdam IX.
If that is not the case please tell me, so they can get their money back.
I am sorry if I mixed up too computers one in the netherlands in an easynet
colocation with another one here in germany with KPN. Both could reach
h.root-servers.net
And this I found from the Amsterdam IX memberlist:
Name:
KPN Internet Solutions - AS286
AS Number: 286
URL: www.as286.net
Member since: 2002-10-14
Organisational contact: info@kpn.net
Peering contact: peering@kpn.net
Peering policy: www.as286.net
So I guess that computer too is connect not via DTAG.DE but via
Amsterdam IX
I never claimed to be a routing guru. I you feel like splitting
hairs you are welcome.
Kind regards,
Peter and Karin Dambier
Sabri Berisha wrote:
Dear Peter,
> Peter Dambier did post nonsense. In fact, it was total nonsense since
> the AMS-IX is not present in any KPN datacentre, *and* it is impossible
> for end-hosts to connect to the AMS-IX directly.Part of the traceroutes between me and the system I was talking of:
6 da-ea1.DA.DE.net.DTAG.DE (62.153.179.54) 18.334 ms 22.725 ms
4 ams-e4.AMS.NL.net.DTAG.DE (62.154.15.2) 145.264 ms 152.212 ms
5 amx-gw2.nl.dtag.de (195.69.145.211) 14.737 ms 13.115 ms 11.501 ms
5 gb-2-0-0.amsix1.tcams.nl.easynet.net (195.69.144.38) 169.072 ms
I did not say the host was connected to the IX. I said it was living in a
datacentre connected to Amsterdam IX.
You said:
I know of one host here in germany who can see h.root-servers.net.
That host is living in a KPN data centre directly connected to Amterdam
IX.
Your own traceroute clearly shows that your host is not directly
connected to the AMS-IX. Nor does the KPN datacenter it resides in. The
AMS-IX has 4 datacenters where members can place equipment which can be
directly connected to the AMS-IX:
- GlobalSwitch;
- Sara;
- Nikhef;
- Telecity2, Kuiperbergerweg;
Every statement otherwise is bogus, nonsense, crap or whatever term you
prefer to use for this.
> I know of one host here in germany who can see h.root-servers.net.
> That host is living in a KPN data centre directly connected to
Amterdam
> IX.
Your own traceroute clearly shows that your host is not directly
connected to the AMS-IX. Nor does the KPN datacenter it resides in. The
AMS-IX has 4 datacenters where members can place equipment which can be
directly connected to the AMS-IX:- GlobalSwitch;
- Sara;
- Nikhef;
- Telecity2, Kuiperbergerweg;Every statement otherwise is bogus, nonsense, crap or whatever term you
prefer to use for this.
This is a good example of a useless argument caused when one
person is speaking from a customer viewpoint and one customer
is speaking from an operator viewpoint.
Assume that there is an ISP X with a data center in Germany
and a colocated rack at Nikhef. They peer directly with many
other providers through AMS-IX from their Nikhef location.
Customer Q comes along and places a server in their data centre
in Germany because he needs to serve his users both in Germany and
in his chain of hotels throughout Holland. His network people assure
him that the server is connected directly to AMS-IX because that
is what their traceroutes say.
Of course, we know better. We know that the server is connected
directly to ISP X and indirectly to AMS-IX because we are
used to being particular about which operator owns each
hop. But the customer Q doesn't see the hops in network X.
To him, they are invisible because they are his HOME network.
Customers don't see themselves as network operators and therefore
they often think of their ISP's network as their own.
So who is right? Peter? Sabri? Both?
My opionion is that neither of them is right because they
both failed to understand what the real problem is and
they both failed to take the correct steps to solve the
problem. As it happens, this was a very, very basic
network issue which does not need to be discussed on
NANOG at all.
--Michael Dillon