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 -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------
On Sun, 23 Oct 2005, 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.
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.
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. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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","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 -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason
On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote:
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 -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
* Daniel Roesen:
On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote:
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. 8-)
On Sun, Oct 23, 2005 at 08:00:10PM +0200, Florian Weimer wrote:
On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier wrote:
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 -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
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 and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason
* 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. ----- Original Message ----- From: "Niels Bakker" <niels=nanog@bakker.net> To: "Peter Dambier" <peter@peter-dambier.de> Cc: <nanog@merit.edu> Sent: Sunday, October 23, 2005 3:48 PM Subject: Re: h-root-servers.net
* 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.
On Sun, 23 October 2005 16:07:03 -0500, John Palmer (NANOG Acct) wrote:
No, why don't you stop insulting people, Niels. You attack Peter because of his involvment in the Inclusive Namespace. FYI:
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
On Sun, Oct 23, 2005 at 04:07:03PM -0500, John Palmer (NANOG Acct) wrote: 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.
Niels wrote:
* 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.
-- Sabri please do not throw salami pizza away
Sabri Berisha wrote:
On Sun, Oct 23, 2005 at 04:07:03PM -0500, John Palmer (NANOG Acct) 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 -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason
On Mon, Oct 24, 2005 at 02:40:14PM +0200, Peter Dambier wrote:
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. -- Sabri please do not throw salami pizza away
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
On Mon, Oct 24, 2005 at 03:06:35PM +0100, Michael.Dillon@btradianz.com wrote: Dear Michael,
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.
Last time I checked, the O in [EU|NA|AFRI]NOG stands for 'operator'. Niels made a perfectly valid point by saying that it is impossible for an end-user to be connected to the AMS-IX and he was flamed for it. If Peter Dambier has no clue about end-hosts vs intermediate systems, let alone how to parse a traceroute with his grey mass, he needs to be educated. Just as I needed many years ago. Anyway, this is going way off-topic so this will be my last post in this subthread. Feel free to reply off-list. -- Sabri please do not throw salami pizza away
Thank you Michael, for throwing light into this. Yes, I see, Sabri and me are on two different rails, one leading north, the other one leading east. I hope Sabri still has got all his hairs. I am counting mine now. Kind regards and thank you again, Peter Dambier Michael.Dillon@btradianz.com wrote:
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
-- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason
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 -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason
On Sun, 23 Oct 2005, Daniel Roesen wrote:
On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier 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?
; <<>> 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?
That could be as well, I might be able to ask them perhaps as well.
Christopher L. Morrow wrote:
On Sun, 23 Oct 2005, Daniel Roesen wrote:
On Sun, Oct 23, 2005 at 11:59:15AM +0200, Peter Dambier 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 -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr http://www.kokoom.com/iason
On Sun, 23 Oct 2005 11:16:58 PDT, Randy Bush said:
A friend of mine has got a colo box sitting, single-homed
friends don't let friends home singly
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?
On Mon, 24 Oct 2005, Valdis.Kletnieks@vt.edu wrote:
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
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
On Nov 11, 1:14pm tony.li@tony.li wrote:
The only way to get 32-bit AS number support deployed is to run out of AS numbers in the 16 bit space.
Exactly. - When will the Internet deploy X? - Just before it's too late. How many people on this list remember the transition from BGP3 to BGP4 and CIDR? This was, uhh, about 12 years ago. Before that there was an EGP to BGP transition, but that was less of an issue. But history will repeat itself. Not that I see any great evil in that -- people are always busy, have always been. It's a case of which priorities are most pressing, so, indeed, yes, the only way is to run out of the existing resource. Likewise for whatever will provide more address space.-) -- Per
On Fri, Nov 11, 2005 at 09:41:49PM +0000, Per Gregers Bilse wrote:
On Nov 11, 1:14pm tony.li@tony.li wrote:
The only way to get 32-bit AS number support deployed is to run out of AS numbers in the 16 bit space.
Exactly.
- When will the Internet deploy X?
- Just before it's too late.
How many people on this list remember the transition from BGP3 to BGP4 and CIDR? This was, uhh, about 12 years ago. Before that there was an EGP to BGP transition, but that was less of an issue.
EGP-BGP BGP-BGP2 BGP2-BGP3 BGP3-BGP4 cidr ... did them all. CIDR was a pita. took years. something about presumtions by equipment vendors and burning those assumptions into silicon. for most of the rest, we clustered the engineers into the IETF terminal room (or the Interop NOC, back in the day) and "rebooted" the net. :) most fun was the folks writing the code, hung-over from the night before, trying to meet the 11:00 "deadline" before the noon hackery. Ah, the bad ol'days.
But history will repeat itself. Not that I see any great evil in that -- people are always busy, have always been. It's a case of which priorities are most pressing, so, indeed, yes, the only way is to run out of the existing resource. Likewise for whatever will provide more address space.-)
i can only hope you are right. re-kindling the excitment and enthusiasim that once existed will be a highlight.
-- Per
--bill
On Nov 11, 9:50pm bmanning@vacation.karoshi.com wrote:
EGP-BGP BGP-BGP2 BGP2-BGP3
Yes ... but those were easier, more overlap was possible, especially at the edge. We had EGP peers right into BGP4 times. CIDR was more universal, outright a 'flag day' all things considered. But never mind ...
i can only hope you are right. re-kindling the excitment and enthusiasim that once existed will be a highlight.
Lemme see ... "Cisco hires Tony Li to lead next generation development." ? Interesting thought, if nothing else. Then, how about "All the big telcos rehire all the nerdy people that got p****d off and left a long time ago". I see problems ahead ... :-/ -- Per
On Fri, Nov 11, 2005 at 09:41:49PM +0000, Per Gregers Bilse wrote:
On Nov 11, 1:14pm tony.li@tony.li wrote:
The only way to get 32-bit AS number support deployed is to run out of AS numbers in the 16 bit space.
Exactly.
- When will the Internet deploy X?
- Just before it's too late.
How many people on this list remember the transition from BGP3 to BGP4 and CIDR? This was, uhh, about 12 years ago. Before that there was an EGP to BGP transition, but that was less of an issue.
But history will repeat itself. Not that I see any great evil in that -- people are always busy, have always been. It's a case of which priorities are most pressing, so, indeed, yes, the only way is to run out of the existing resource. Likewise for whatever will provide more address space.-)
-- Per
I think, however, that this will be less dramatic than other things. This is a "relatively" simple software change. The one thing it *will* do is make sure that all the old hardware out there that runs BGP won't work anymore and have to be updated. This is arguably a good thing. Also remember that this is still some time away. Getting ever closer, but still a future event. --- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
Okay, so as people pointed out, I forgot that hardware engineers like to make assumptions about software for the sake of efficiency in ASICs and the like. So add a few exponents of pain. Still shouldn't be *all* that bad I wouldn't think. On Fri, Nov 11, 2005 at 03:19:45PM -0700, Wayne E. Bouchard wrote:
On Fri, Nov 11, 2005 at 09:41:49PM +0000, Per Gregers Bilse wrote:
On Nov 11, 1:14pm tony.li@tony.li wrote:
The only way to get 32-bit AS number support deployed is to run out of AS numbers in the 16 bit space.
Exactly.
- When will the Internet deploy X?
- Just before it's too late.
How many people on this list remember the transition from BGP3 to BGP4 and CIDR? This was, uhh, about 12 years ago. Before that there was an EGP to BGP transition, but that was less of an issue.
But history will repeat itself. Not that I see any great evil in that -- people are always busy, have always been. It's a case of which priorities are most pressing, so, indeed, yes, the only way is to run out of the existing resource. Likewise for whatever will provide more address space.-)
-- Per
I think, however, that this will be less dramatic than other things. This is a "relatively" simple software change. The one thing it *will* do is make sure that all the old hardware out there that runs BGP won't work anymore and have to be updated. This is arguably a good thing. Also remember that this is still some time away. Getting ever closer, but still a future event.
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
i think you misunderstand the h/w / s/w distinction here. BGP is a 'control-plane'-driven protocol. control-plane = software. no vendor would have BGP "in hardware" per-se (although its forseeable that they may have 'AS# accounting for netflow' in h/w and that may be limited to addressing 16-bits). "forwarding a packet" (i.e. data-plane path) is typically in h/w in many {modern,large} routers. even if the routing protocol is based on AS#s, forwarding is typically based on a RIB creating a FIB. a FIB typically doesn't contain AS# information as there is no need to - you're not 'forwarding' on AS#, you're forwarding on Destination address. i think the distinction of "old hardware" that the original poster was trying to make was really one of things like RAM and Flash RAM space. if we take "Cisco routers" as an example, it may be that 32-bit AS# support mandates the use of the fictional IOS 12.666S software train which probably won't fit in the 16MB RAM and 16MB FLash on a 15-year-old c2500 series router. cheers, lincoln. NB. obvious 12.666S is fictional. don't try to read anything into that. and if its not obvious, no i'm not officially talking for Cisco. Wayne E. Bouchard wrote:
Okay, so as people pointed out, I forgot that hardware engineers like to make assumptions about software for the sake of efficiency in ASICs and the like. So add a few exponents of pain. Still shouldn't be *all* that bad I wouldn't think.
On Fri, Nov 11, 2005 at 03:19:45PM -0700, Wayne E. Bouchard wrote:
On Nov 11, 1:14pm tony.li@tony.li wrote:
The only way to get 32-bit AS number support deployed is to run out of AS numbers in the 16 bit space. Exactly.
- When will the Internet deploy X?
- Just before it's too late.
How many people on this list remember the transition from BGP3 to BGP4 and CIDR? This was, uhh, about 12 years ago. Before that there was an EGP to BGP transition, but that was less of an issue.
But history will repeat itself. Not that I see any great evil in that -- people are always busy, have always been. It's a case of which priorities are most pressing, so, indeed, yes, the only way is to run out of the existing resource. Likewise for whatever will provide more address space.-)
-- Per I think, however, that this will be less dramatic than other
On Fri, Nov 11, 2005 at 09:41:49PM +0000, Per Gregers Bilse wrote: things. This is a "relatively" simple software change. The one thing it *will* do is make sure that all the old hardware out there that runs BGP won't work anymore and have to be updated. This is arguably a good thing. Also remember that this is still some time away. Getting ever closer, but still a future event.
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
On Nov 11, 2005, at 5:19 PM, Wayne E. Bouchard wrote:
I think, however, that this will be less dramatic than other things. This is a "relatively" simple software change. The one thing it *will* do is make sure that all the old hardware out there that runs BGP won't work anymore and have to be updated. This is arguably a good thing. Also remember that this is still some time away. Getting ever closer, but still a future event.
Given the presentation at the last NANOG, the "old" routers running 16-bit code / hardware / ASICs can just keep going for a very long time. Or did I miss some important point? -- TTFN, patrick
At 04:10 PM 12/11/2005, Patrick W. Gilmore wrote:
On Nov 11, 2005, at 5:19 PM, Wayne E. Bouchard wrote:
I think, however, that this will be less dramatic than other things. This is a "relatively" simple software change. The one thing it *will* do is make sure that all the old hardware out there that runs BGP won't work anymore and have to be updated. This is arguably a good thing. Also remember that this is still some time away. Getting ever closer, but still a future event.
Given the presentation at the last NANOG, the "old" routers running 16-bit code / hardware / ASICs can just keep going for a very long time.
Or did I miss some important point?
not at all - you are correct. The presentation at the last NANOG said that if you are in a routing domain with an existing 2 byte AS number then you need to change _nothing_. Of course, after a few years, you may come to the conclusion that AS23456 has launched a nefarious plot and is popping up all over the routing world, but you will still need to change _nothing_. regards, Geoff
participants (21)
-
Alexander Koch -
bmanning＠vacation.karoshi.com -
Christopher L. Morrow -
Dan Mahoney, System Admin -
Daniel Roesen -
Florian Weimer -
Geoff Huston -
Joel Jaeggli -
John Palmer (NANOG Acct) -
Jon Lewis -
Lincoln Dale -
Michael.Dillon＠btradianz.com -
Niels Bakker -
Patrick W. Gilmore -
Per Gregers Bilse -
Peter Dambier -
Randy Bush -
Sabri Berisha -
Tony Li -
Valdis.Kletnieks＠vt.edu -
Wayne E. Bouchard