Cope bad peering of ISP Deutsche Telekom

Rico

MTU issue?
Test download URL? I have access to ~30 Sites with Deutsche Telekom to check.

-Rico

Bob.Dig

@rico said in Cope bad peering of ISP Deutsche Telekom:

MTU issue?
Test download URL? I have access to ~30 Sites with Deutsche Telekom to check.

So I noticed it myself with the snort subscriber rules, you can test this yourself, if you have a snort account (for example snortrules-snapshot-29161.tar.gz).
I also have found problems with a small tool (500KB) hosted on AWS, but right now I can download it fast so sharing the url doesn't make sense. Yesterday evening the download coudn't finish at all.

Also what I noticed since having the new ISP, the thinkbroadband quality monitor is showing much blue for 12 hours.

uk peering.png

DaddyGo

@bob-dig said in Cope bad peering of ISP Deutsche Telekom:

you can test this yourself, if you have a snort account (for example snortrules-snapshot-29161.tar.gz).

This is clearly a problem....

what does a traceroute point to snort.org?

there is no problem for us with this, I just tried:

have you tried this?
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router

Bob.Dig

@daddygo said in Cope bad peering of ISP Deutsche Telekom:

what does a traceroute point to snort.org?

Shows not much I think, but dl speed defers drastically

@daddygo said in Cope bad peering of ISP Deutsche Telekom:

have you tried this?
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router

No, because everything else is working as expected, it is a peering problem at least to AWS.

So guys, what to do in practice?

DaddyGo

@bob-dig said in Cope bad peering of ISP Deutsche Telekom:

So guys, what to do in practice?

this will be hard to circumvent with NAT and things like that...

as I understood the German articles on the theme...

Deutsche Telekom is misbehaving with large network traffic suppliers "players" such as Hurrican Electric, AWS, etc.

open a ticket with measurements evidence and if they can't help you will have a reason to get rid of it

https://www.peeringdb.com/net/196

Bob.Dig

@daddygo said in Cope bad peering of ISP Deutsche Telekom:

this will be hard to circumvent with NAT and things like that...

Couldn't I use pfBlocker to create an alias for AWS and then selectively route this through a vpn (on WAN though) or create a static route for that somehow?

JKnott

@bob-dig

What do you mean by "peering". That's where carriers and ISPs meet to exchange data. For example, my ISP peers at the Toronto Internet Exchange. You mention AWS, but unless they have a point of presence at the same location as your ISP, they're not peering.

stephenw10

You can try to do that. If you can make an alias of all of AWS you can static route it via a VPN gateway. That will apply all traffic including any client traffic not policy routed.

Steve

DaddyGo

@bob-dig said in Cope bad peering of ISP Deutsche Telekom:

Couldn't I use pfBlocker to create an alias for AWS

but yes, you only have to do this with all the intermediate network players

it would be a horror job and you don’t know when your packages will travel and which route

f.e.:
in the EU travels a lot of package on the HE network

BTW:
Telekom is also in a bad relationship with them

+++edit:
like you said you don't just notice this problem towards AWS....(?!)

Bob.Dig

@stephenw10 said in Cope bad peering of ISP Deutsche Telekom:

You can try to do that. If you can make an alias of all of AWS you can static route it via a VPN gateway. That will apply all traffic including any client traffic not policy routed.

Steve

Thanks steve, but where to "put" it. It should be used at least by Suricata and pfBlocker.

stephenw10

Add is as a static route in Sys > Routing > Static Routes.

It might get ugly with an alias that tries to include all of AWS as that will be huge. Your routing table will end up.... large!

There is no way to policy route traffic from the firewall itself so it will apply to all traffic that isn't otherwise policy routed.

Steve

Bob.Dig

@stephenw10 I checked with a rule on lan, worked flawlessly with the snort rules download.

That table I created has 2,055 records though...

How could I do that or at least test it on "wan"? Is it doable in the gui?
I can't load these pfBlocker Aliases under System/Routing/Static Routes.

@DaddyGo To be clear, I want to get rid of them asap, but I signed a two year contract...

Bob.Dig

@bob-dig said in Cope bad peering of ISP Deutsche Telekom:

How could I do that or at least test it on "wan"? Is it doable in the gui?
I can't load these pfBlocker Aliases under System/Routing/Static Routes.

For the lols I guess, I tried this, but also wasn't working:

I do have a VPS though and routing it there seems to be a viable solution. But I have configured it to connect to me and not the other way around and I am somewhat noobish when it comes to my own OVPN-installations, so the firewall itself will be the last to have internet.

Bob.Dig

@jknott said in Cope bad peering of ISP Deutsche Telekom:

You mention AWS, but unless they have a point of presence at the same location as your ISP, they're not peering.

Ok, then I meant routing because of bad peering or just bad routing in general.

stephenw10

Yeah, it would need to actually route to it using a static route. Outbound NAT does not route traffic.

You're right though, you can't use a URL alias in a static route. Which is reasonable since adding 2055 routes to the table would be.... ugly at best!

Steve