cablecom nervt:

marzili:~# traceroute www.nts.ch traceroute to www.nts.ch (212.103.67.8), 30 hops max, 38 byte packets 1 192.168.1.1 (192.168.1.1) 3.551 ms 3.712 ms 2.639 ms 2 10.163.128.1 (10.163.128.1) 10.812 ms 11.113 ms 9.909 ms 3 ch-gva01a-ra1-ge-1-1-0.aorta.net (213.46.171.53) 18.101 ms 18.371 ms 18.046 ms 4 ch-gva01a-ra1-ge-1-1-0.aorta.net (213.46.171.53) 19.260 ms 19.274 ms * 5 v326.mpd01.par01.atlas.cogentco.com (130.117.14.93) 114.371 ms 110.048 ms 210.843 ms 6 nts_workspace_ag.demarc.cogentco.com (130.117.240.186) 49.326 ms 30.877 ms 33.158 ms 7 r4.colobern.nts.ch (212.103.65.23) 29.277 ms * *

zu init7 komme ich momentan gar nicht durch ...

marzili:~# traceroute www.init7.net traceroute to www.init7.net (82.197.165.66), 30 hops max, 38 byte packets 1 192.168.1.1 (192.168.1.1) 2.699 ms 1.571 ms 1.565 ms 2 10.163.128.1 (10.163.128.1) 9.572 ms 11.617 ms 10.895 ms 3 * * * 4 * * * 5 nl-ams01a-rd1-ge-4-1.aorta.net (213.46.160.25) 40.022 ms 41.455 ms 41.158 ms 6 fr-par03a-rd1-ge-4-0.aorta.net (213.46.163.82) 40.285 ms 41.913 ms 46.195 ms 7 fr-par03a-ra1-ge-0-0-0_0.aorta.net (213.46.163.90) 40.701 ms * *

super-sach mit aorta.net!

Fredy Kuenzler schrieb:

Steven Glogger schrieb:

...

no, from cybernet seems to be fine:

Thanks, issue is resolved. We had a DDos attack to a customer server, which filled up the STM-1 from 702. Sunrise (and Cablecom too) did route towards Init7 over 702 (since we are outbound heavy, I didn't gave this much attention yet). BTW DDOS still going on.

I changed now our routing policy. They won't see us anymore over 702, which forces them to route over their upstreams towards us (towards 13030 is now flowing over 1299), unless they agree to peer.

http://debby.sunrise.ch/lg/ Tracing the route to www.init7.net (82.197.165.66)

1 g5-0.zur01b04.sunrise.ch (193.192.234.198) 4 msec 0 msec 0 msec 2 t2a2-ge0-1.ch-zur.eu.bt.net (166.49.219.1) [AS 5400] 0 msec 0 msec 0 msec 3 t2c2-ge7-0.ch-zur.eu.bt.net (166.49.186.44) [AS 5400] 0 msec 0 msec 4 msec 4 t2c1-p8-0.de-fra.eu.bt.net (166.49.164.161) [AS 5400] 4 msec 4 msec 8 msec 5 t2a4-ge6-0.de-fra.eu.bt.net (166.49.172.20) [AS 5400] 8 msec 8 msec 8 msec 6 de-cix-1.telia.net (80.81.192.35) [AS 6695] 4 msec 8 msec 8 msec 7 ffm-bb2-link.telia.net (80.91.249.142) [AS 1299] 12 msec 8 msec 12 msec 8 zch-b1-pos2-0.telia.net (213.248.65.170) [AS 1299] 20 msec 20 msec 20 msec 9 init-113677-zch-b1.c.telia.net (213.248.96.46) [AS 1299] 16 msec 20 msec 20 msec 10 r4.core.init7.net (213.144.128.4) [AS 13030] 24 msec 20 msec 24 msec 11 www.init7.net (82.197.165.66) [AS 13030] 24 msec 24 msec 24 msec

BTW is anyone aware of a working Cablecom LG or at least Traceroute?

F. _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

The current routing policy of 8404 is questionable. The seem to prefer any route over 6830, even though they learn them directly over peering.

full ACK. they seem to love asymmetric routing ,-) i think the quality of cablecom will go down by 1st of november when they will shut down may swiss peerings. nice cablecom erm... UPC ,-)

-steven

Good Morning

[..]

It is a general thing. I would have thought swiss ISPs buying a bit more selective based on rtt and peering being local or close by. Disclaimers apply left and right, for you know who I am etc. But I am really surprised, believe it or not.

yes we do care about rtt - but we can't ignore the prices. it's the usual trade-off :-( If you have to pay twice the price for peering transit as for full transit the decision is clear - at least from my point of view.

Think about it this way - before there were 2 ISPs you had with 'interesting' domestic peering policies. Now you have three... I could bet with you these three do not react so much about traffic over their upstream unless it is some 500m sustained...? I speak of experience, in a way

[..]

in the past it showed, that this "bad" domestic peering policies even brought customers to our network. You can very well explain the peering policy of a big domestic ISP to your own customers and earn their sympathy and support.

Regards

Nik

We're not receiveing a route for that network although we're buying transit from AS1299:

#@...mainlab.net>show ip bgp 217.29.66.75 BGP4 : None of the BGP4 routes match the display condition

Some performance measurements from Frankfurt: # traceroute www.cablecom.ch traceroute to www.cablecom.ch (62.2.16.94), 64 hops max, 40 byte packets 1 80.242.128.1 (80.242.128.1) 0 ms 0 ms 0 ms 2 tx016113.in-addr.bellaxa.net (217.118.16.113) 1 ms 1 ms 1 ms 3 tx016050.in-addr.bellaxa.net (217.118.16.50) 11 ms 1 ms 1 ms 4 gige-1-0-0-de-cix.aorta.net (80.81.193.111) 1 ms 1 ms 1 ms 5 213.46.179.41 (213.46.179.41) 1 ms 1 ms 1 ms 6 ch-zrh01a-ra1-ge-1-0-0.aorta.net (213.46.160.46) 12 ms 12 ms 12 ms 7 mlrOTF008-xge-3-4.aorta.net (213.46.171.50) 12 ms 12 ms 12 ms 8 vlan701.mesOTF009.cablecom.net (62.2.25.162) 18 ms 12 ms 18 ms 9 ...

# traceroute www.init7.net traceroute to www.init7.net (82.197.165.66), 64 hops max, 40 byte packets 1 80.242.128.1 (80.242.128.1) 1 ms 0 ms 0 ms 2 tx016113.in-addr.bellaxa.net (217.118.16.113) 1 ms 1 ms 1 ms 3 tx016050.in-addr.bellaxa.net (217.118.16.50) 1 ms 1 ms 1 ms 4 de-cix.init7.net (80.81.192.67) 1 ms 1 ms 1 ms 5 r7.core.init7.net (82.197.168.3) 8 ms 7 ms 7 ms 6 r4.core.init7.net (213.144.128.4) 10 ms 10 ms 10 ms 7 www.init7.net (82.197.165.66) 13 ms 13 ms 12 ms

Regards, Gunther

-----Ursprüngliche Nachricht----- Von: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Alexander Koch Gesendet: Freitag, 22. September 2006 09:24 An: swinog@swinog.ch Betreff: Re: [swinog] Sunrise network issues?

On Fri, 22 September 2006 07:56:12 +0200, Alexander Koch wrote:

...

many ms that would be. Maybe do a ping to 217.29.67.18, and

217.29.66.75 might be better to test from some Nordic operator, that is their MIX IP. I would be curious how many ms that are, if more than 5 ms it would prove my point unfortunately. That network might not be routed though.

Alexander

---

swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

On Fri, 2006-09-22 at 15:07 +0200, Gunther Stammwitz wrote:

Some performance measurements from Frankfurt:

Back to our studies, we tried to implement a system, that periodically stores traceroutes from looking glass servers to some other endpoints. The main goal was to display a map which shows which provider uses wich route and detect routing changes (well, this had never been reached).

If someones interessted, leave me a PM.

Have a nice weekend! - Dan

Hello Jeroen,

Very good hint. I've always been trying to measure performance to deutsche telekom but they don't really offer test-locations. With the TTM-boxes one can do that. We have just ordered ours and it should be operational within the next 4 weeks. The TTM-project is a really good tool for network operators. Especially with latency crtical applications like VoIP or gaming the ttm-boxes are the last option you have for troubleshooting.

Regards, Gunther