raspbian.net/raspbian.org ipv6 peering problems
Hello, I am not sure if I am right here with my question. Does someone measurements to the server of "raspbian"? Their hoster (bytemark, iomart, zayo?) seems not to be able to establish correct peerings. At least the peering to AS3320 is broken. I already contacted 3320. They say zayo doesn't fulfill the minimum security requirements. Are more peerings broken? Regards, Thomas
On Tue, Jun 25, 2019 at 09:58:25AM +0200, Thomas Schäfer <tschaefer@t-online.de> wrote a message of 17 lines which said:
Does someone measurements to the server of "raspbian"?
Indeed, it's not perfect (the sad state of IPv6 connectivity): % blaeu-reach --requested 100 --by_probe 2001:41c9:1:3ce::1:10 99 probes reported Test #22099153 done at 2019-06-25T10:03:22Z Tests: 86 successful probes (86.9 %), 13 failed (13.1 %), average RTT: 71 ms Comparison with a server with good connectivity (F.root-servers.net): % blaeu-reach --requested 100 --by_probe --old_measurement 22099153 2001:500:2f::f Warning: --requested=100 ignored since a list of probes was requested 99 probes reported Test #22099157 done at 2019-06-25T10:06:11Z Tests: 99 successful probes (100.0 %), 0 failed (0.0 %), average RTT: 39 ms
Thomas Schäfer <tschaefer@t-online.de> writes:
Hello,
I am not sure if I am right here with my question.
Does someone measurements to the server of "raspbian"?
Their hoster (bytemark, iomart, zayo?) seems not to be able to establish correct peerings. At least the peering to AS3320 is broken. I already contacted 3320. They say zayo doesn't fulfill the minimum security requirements.
The staff at Bytemark are both clueful and responsive in my experience. Did you try to contact them? In what way is the peering broken? Hmm.... I see at https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg that AS3320 seems be missing all the Bytemark IPv6 routes. Looks like they don't have any connectivity to Bytemark's transit upstream, which is AS20860 according to the RIPE db. I believe this is a fault at AS3320. It's not just Bytemark they are filtering out here. You can look up for example 2001:1b40::/32 or 2a01:b040::/32. They are also missing in the AS3320 table. Bjørn
Am Dienstag, 25. Juni 2019, 12:47:57 CEST schrieb Bjørn Mork:
Hmm.... I see at https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg that AS3320 seems be missing all the Bytemark IPv6 routes. Looks like they don't have any connectivity to Bytemark's transit upstream, which is AS20860 according to the RIPE db. I believe this is a fault at AS3320. It's not just Bytemark they are filtering out here.
I used the looking glasses at both sites. They don't see each other. I already contacted the peering guy at AS3320. He wrote me that zayo doesn't maintain a "AS-set" anymore, so DTAG cannot filter on it. I have no much clue about bgp, as-sets, peeringdb, rpki and so on. It's not my business. I am just a user/customer of the DTAG and other ISPs. Of course there are discussions about security filtering and money, even if bigger ISPs are involved. In this case it seems to me it's a security thing. For me it is just one connectivity failure. ( I am part of the costumer trial ipv6-only at DTAG) Regards, Thomas
Thomas Schäfer <tschaefer@t-online.de> writes:
Am Dienstag, 25. Juni 2019, 12:47:57 CEST schrieb Bjørn Mork:
Hmm.... I see at https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg that AS3320 seems be missing all the Bytemark IPv6 routes. Looks like they don't have any connectivity to Bytemark's transit upstream, which is AS20860 according to the RIPE db. I believe this is a fault at AS3320. It's not just Bytemark they are filtering out here.
I used the looking glasses at both sites. They don't see each other. I already contacted the peering guy at AS3320. He wrote me that zayo doesn't maintain a "AS-set" anymore, so DTAG cannot filter on it.
AS20860 (IOMART) is the transit provider for Bytemark, and they maintain the AS-IOMART as-set which includes the AS-BYTEMARK as-set among others. AS20860 again use AS174 (Cogent) and AS6461 (Zayo) for transit, and peers with a number of other ISPs mostly at LINX. For some reason not AS3320 though. But this should not matter AS3320 is obviously peering with Cogent, and should get the routes there at least. But they could obviously improve their connectivity a bit.... And there is something odd about their Cogent peering. Looking for the IPv6 prefixes DTAG has received from via AS174: https://f-lga1.f.de.net.dtag.de/index.php?pageid=lg&query=ipv6+bgp+regexp¶=.*+174+.*&server=194.25.0.222&EXEC=Execute Not much to see there. There should have been a *lot* more routes there, especially given their lack of other peers.
I have no much clue about bgp, as-sets, peeringdb, rpki and so on. It's not my business. I am just a user/customer of the DTAG and other ISPs.
Well, it's all a part of the IPv6 fun isn't it? :-)
Of course there are discussions about security filtering and money, even if bigger ISPs are involved. In this case it seems to me it's a security thing.
Nope. You don't drop parts of the Internet because you don't like their policies. The Zayo thing is a bad excuse. They should explain why they don't take the routes from Cogent then, and also why they don't peer with IOMART at LINX.
For me it is just one connectivity failure. ( I am part of the costumer trial ipv6-only at DTAG)
I suggest pushing your contacts at DTAG. As it is, they provide only limited IPv6 connectivity to you. This is incompatible with any IPv6-only product, trial or not. Bjørn
Hi Thomas, I've done multiple traceroutes https://atlas.ripe.net/measurements/?page=1&af=6&search=target:raspbian.org#tab-traceroute and it looks like only AS3320 is affected. PS: I've added you to the list of people who can use my credits so you can do your own measurements. Regards, Stefan
participants (4)
-
Bjørn Mork -
Stefan Spühler -
Stephane Bortzmeyer -
Thomas Schäfer