How to reject some ISP ranges on the wan?

Installing and Using OpenWrt
1

My ISP has more than 7 millions public ipv4 addresses and cause of that they have several different ip ranges like 177.XXX.XXX.XXX, 189.XXX.XXX.XXX, 200.XXX.XXX.XXX and etc.

They provide me with dynamic public ipv4 IPoE FTTH connection. The problem is that some of those ranges are completely fucked up, either high ping, poor performance(download speeds from several different sources), being saturated at peak hours(packet loss + really high ping) and etc

While other ranges are 100% fine!

So what i want to know if there is a way to reject\drop\idk a connection to the wan from the problematic ranges to force the ISP to give one of those ranges that are working 100% fine or block the connection to one or more of their internal routers that use 100.XXX.XXX.XXX to force a re-route of my connection?

My ping to this ip is suppose to be 10-15 and I have to deal with performance like this /\ every day for at least 6 hours, from 18:00 to 00:00 to several destinations, unless i am on a good range, then it does not happen.




PS: Contacting the ISP is not an option, cause its a really big ISP and its basically impossible to reach someone that actually takes care of the network! Every contact you do, you are only able to reach the support who tells you to restart the modem\ONT or want to send a technician to my house when the problem in on their routers\backbone.
The ISP also right now is on a bankruptcy recovery and i dont have other ISP options available. Right now they only care about aggressively expanding their FTTH last mile to capture more clients while there are monkeys managing their backbone and routers.

2

Nothing you can do about how the ISP assigns your WAN IP, or routes to the endpoint.

Even if you paid for a static IP, it's no guarantee that you would get a "clean" route.

WinMTR uses ICMP Echo Request packets, which some servers will drop.

I would be interested in seeing what happens with TCP packets.

Best way to test that is MTR.

I installed Windows Subsystem for Linux 2 on my Windows 10 21H2 Pro machine, and run MTR from there.

MTR TCP trace to 8.8.8.8 (replace 8.8.8.8 with the IP of the endpoint you want to test)

mtr -P 80 -c 10 -T -w 8.8.8.8

The bigger issue is packet loss at the endpoint.

3 Likes
3

Thx for the answer :smiley:

Its not the destination servers dropping the ICMP, its my ISP dropping packets indeed... How do i know that? Cause if i do the same test using a tier 1 vpn, my 4g connection from the same ISP as my FTTH connection or my neighbor small ftth ISP connection, there is no packet loss at all or high ping like on this WinMTR print screen.

Then why not change to the small ftth isp provider someone might ask? Cause their last mile is shit and goes down a lot(bad up time), and they give you ipv4 CGNAT and no ipv6.

What about Telegraf input plugin: Ping? Those graphics are from it, do you have any idea if it uses TCP or ICMP echo?

4

Hop 9 (the endpoint) in your WinMTR screenshot is dropping packets (18%).

Hops 4 and 5 are your ISP's routers...hops 6, 7, 8 and 9 are outside of the ISPs network (which is left at hop 6, where Level 3 picks it up).

Do an MTR TCP test to that IP.

I would also try a couple of speed test servers, get their IPs (run Wireshark while you're doing a speed test, and then do the MTR tests.

You're at least building documented tests to show the ISP that back you up.

5

Yes, hop9 is dropping packets cause my ISP routers are fucked up being unstable(you can see hop5 with really unstable ping and dropping packets too).

Trust me, if i use any other connection to reach the server of the WinMTR print screen or the ones from the grafana graphics besides my main FTTH line, there is not packet loss or high ping at the endpoint when doing a winmtr test to any of the servers, and some of these connections even use the exact same route besides the same internal 100.XXX.XXX.XXX routers ofc.

As i already explained, there is no point in contacting the ISP:

"Contacting the ISP is not an option, cause its a really big ISP and its basically impossible to reach someone that actually takes care of the network! Every contact you do, you are only able to reach the support who tells you to restart the modem\ONT or want to send a technician to my house when the problem is on their routers\backbone."

Also if you send them an e-mail with proof, the person who responds who is a PR person and not a network person, says that they only thing they guarantee is the contracted speed to the Internet exchange.

Anyway ill try with TCP tomorrow, cause today its already 00:10 so peak hours are gone and so is the packet loss\high ping.

6

I read it...doesn't change the facts that the ISP controls what WAN IP you are assigned, and how packets are routed inside their network.

If you're playing round robin WAN IPs by rebooting, or doing ifup wan, stick with the one that works.

2 Likes
7

Are these real situations, or testing tools?

I say this because e.g. tracing thru the ISP is futile, as you don't know why the packets are blocked, dropped, etc. Some ISPs drop packets that will die in transit (i.e. traces).

But you do seem to have thru-and-thru pings...

  • You could try to ID the hop/router/range combo causing this - you may already have that data from your tests
  • There could be another logical reason for this (e.g. one of those IP blocks are used to statically address your neighbors...and they have heavy traffic, lol - but bad for you)
  • Literally knock on the door at the headend (the facility at the other end of your last mile) one day...if you know where it is...maybe leave a note/card...say hello to the engineer/tech (this is likely impractical in a very dense city)

This sux.

8

This is really not a conclusive test. You need mtr/traceroute results in both directions to be able diagnose half-way reliably where packets are dropped (and I mean halfway reliably, even with mtrs along both sides of the path localizing drops is not necessarily easy). Also if truly your ISP would drop indiscriminately you would expect the loss rate to increase by a more or less constant amount to all targets "behind" that overloaded router, but in your example the two Level3 routers outside of your ISP's network show no packetloss (and also less worst case delay).*

But in your case it appears that your ISP uses differential routing for different IP ranges (probably as part of its internal trffic engineering), and apparently some of these alternative routers are overloaded in regards to the servers you want to reach, but you really do not know whether your ISP's routers drop the packets or something higher up.

This is a nice NANOG presentation on interpreting traceroute/mtr that expands on some of the challenges.

But you have the "solution" already at hand, use a competent VPN or rent a VPS at a datacenter well connected with your ISP and your target servers and use that path to route around your ISPs problematic peerings/transit points....

*) I like to run mtr form the router (if not already installed and the rputer not being out of storage space already, you can install mtr like this: opkg update ; opkg install mtr):
mtr -ezb4w -c 100 185.41.140.61
to get a report for 100 samples, or
mtr -ezb4w 185.41.140.61
for an online updated version that goes on forever...
If you add -T mtr will use TCP and if you add -u mtr will use UDP instead of ICMP.

EDIT: Regarding your initial question, some ISPs "randomize" the IP and the IP range every time the end-user connects (be that via DHCP or via PPPoE) so you can try whether restarting the wan interface on your router actually helps in getting a better address.... if yes, you can start thinking about scripting that. Personally however I would look at the private VPN via a well-connected VPS solution instead, assuming you will find a hosting com[any that is well connected with your ISP independent of your current IP address.