Hello Everybody…
We would like to inform you about an issue that we faced when we connected a force 180 to an ePMP 3000 sector. The issue is the client that is connected to our network can get all the services with good performance, but he can not access anything related to Real Time Applications such as Netflix unless VPN is used. Keep in mind that clients who are using Force 300-16 on the same sector are not facing any issues.
Best Regards…
I would think one of two issues are at play here. One: there is a configuration issue. Double check everything. Or two, its on the clients side that the problem exists.
Without knowing your network config and how you have clients setup it is impossible to be deterministic on this, no I dont actually need your configs to help point you in the correct direction for this.
Plug a laptop directly into the SM and load netflix, if it works then its the client side. Netflix isnt actually IPTV, its a stream service like youtube, Amazon Prime and Disney Plus. If you can get google then you can get Netflix.
IPTV services is what you provide over multicast and the set top box has to be bridged to the IPTV services network (vlan). If you client subscribes to a third-party IPTV service, you may have to put some additional helper config in your routers to get the foreign multicast service to work but this is not usually needed unless your border routers block multicast connections.
Is the only client or do you have others on same AP ?
Does client use PPPoE ? Netflix and many other streaming services will not work if you are fragmenting all the packets. I mentioned PPPoE because MTU / MSS Clamping / Path MTU is not as uncommon a problem as I would like when using PPPoE.
Also, is the public IP static ? Is it possible their IP is on some blackhole list ? Possible the VPN works because they have a different IP when using it ?
Brubble is on to a couple good possibilities.
If pppoe isnt setup correctly for the network it will cause havoc with some stream services. The pppoe mtu needs to be less than 1500 but the network mtu you support needs to be large enough to add all of the headers you are using (pppoe/vlan/priority/etc). We still have some pppoe clients, but the pppoe mtu is 1492 and mss clamp enabled with the radio mtu set to 1700 and all of our backhauls are 1700 or more as well.
Ip blackhole issues are always fun to solve. Use MXTOOLBOX.COM to check it as it checks a lot of lists. You cant check private lists but it wont hurt. If your IP allocation comes from an upstream provider then you may need them to get involved as its their reputation on the line too.
Vpns just add another header and in some cases also add encryption between the endpoints. The vpn endpoints bridge the traffic between networks and you get the vpn servers outside IP as yours. So IP blackholing isnt effective when a vpn provider is used.
It is also possible that you have some ports blocked on your network that they need.
there’s another client on the same sector that doesn’t face any issues while streaming netflix.
the only difference between the two is that the client facing the problem is using a force 180 sm meanwhile the other client is using force 300-16
i don’t think the pppoe is the cause of this.
all other clients are not facing this issue that this client is facing
I have force180, force200, force300-25 and none of my clients have issues streaming. From experience pppoe can cause issues, but if one SM has issues and no other has this issue its either the outside IP or the radio itself. Since a vpn allows the service to work, I am thinking outside IP. How many ip addresses do you have? Are you doing CGN with pppoe being you delivery and control? Or do you assign the public ip to the pppoe session. Setup an sm for you to use the same pppoe session and outside IP to verify that its the outside ip and not the radio (if it was the radio a vpn would not work)
Just a note. If it is fragmenting packets the VPN works because even though your packets between the two ends of the VPN may be fragmented the connection between the far end of the VPN and the Internet (nextflix for example) is not being fragmented. Also as stated elsewhere if it is a problem with the IP the VPN works because it has a different IP.
We ran 1492 Max MTU/MRU on our Mikrotik/ePMP PPPoE for many years then one we started having a lot of random “I can’t reach 1/2 the internet !” calls. It looked like a MTU / TCP MSS related problem and in the end changing the Max MTU/MRU to 1480 on the PPPoE servers being used by ePMP fixed it. I’ve never had the free time to figure out why.
Brubble, We are saying the same thing!
To give an opinion regarding your unknown: shrinking the MTU by 12 bytes gives more header room, thats all. This would also be what is needed if your wireless MTU was set to 1500. A proper, full pppoe packet is 1512 bytes with no mss clamping. If mss clamping to 1480 or smaller is enabled then your pppoe packet should be 1500 or less.
the “cant reach half the internet” calls are usually because the client is trying to exceed the max packet size for the wireless link with the pppoe headers. VPNs usually use smaller packet sizes (typically 1000 bytes from general snooping) and this ensures that the packet doesnt get filtered due to size after the headers are applied and generally ensures no in route fragmentation, though fragmentation is still possible just unlikely.
in M_Al-Mutterdi’s case reducing the pppoe max packet size could help or at least reduce a possibility, however he must also reduce the mss-clamp size to be smaller than the pppoe mtu by at least 8 bytes.
Link MTU should be more than 1500 on an ISP network, epmp can do 1700 and should to ensure no fragmentation on your network. Not sure about your upstream providers but ours have no problems with 1700 for MTU size from us. but that is also something you need to discuss with them too. There is also your network policy to factor in too, ours in this regard is simply large is good but too large is not good. We commonly see packets with MTUs larger than 1536 bytes and we take advantage of the 1700 bytes MTU available with our inter-NOC backups. But that is also our opinion and not always best practice either. 
it worked! thank u so much sir!