2-5% constant packet loss WAN



  • I've attached my Quality graph for the last hour, but this is pretty regular.  I am getting 2-5% constant loss going on WAN.  No Snort / Suricata.  Minimal network usage (Me browsing while trying to figure this out).  NIC is a I350-T4 using one port only.  I also have Charter and just had them come out here to service all the lines and connectors.  Any thoughts or ideas?

    Specs are:
    Version 2.3.4-RELEASE (amd64)

    CPU Type Intel(R) Xeon(R) CPU E31240 @ 3.30GHz
    Current: 3300 MHz, Max: 3301 MHz
    8 CPUs: 1 package(s) x 4 core(s) x 2 SMT threads

    State table size
    0% (160/1631000)

    MBUF Usage [Auto set on install for this amount]
    4% (38476/1016034)

    CPU usage
    0%

    Memory usage
    6% of 16319 MiB

    /boot/conf.local has:
    autoboot_delay="3"
    legal.intel_ipw.license_ack=1
    legal.intel_iwi.license_ack=1
    comconsole_speed="115200"
    hw.usb.no_pf="1"

    P.S.  This is a direct install, not a VM.


  • Rebel Alliance Global Moderator

    what are you pinging for the monitor?  I assume your isp gateway.  Pinging doesn't actually mean packet loss, maybe the device your pinging is just busy and not answering all pings..  Trying changing what your monitoring..



  • Ok, I haven't changed it and this problem started a few days ago.  Prior to that I never had any issue with leaving it the default (ISP IP).  What's good to use then? 8.8.8.8?

    Edit: Tried google DNS (8.8.8.8) and (8.8.4.4) and still seeing immediate spikes down to ~5%.  Also having noticeable lag spurts when browsing / trying to play any online games (to add to the load)


  • Rebel Alliance Global Moderator

    well then you got an ISP problem would be my guess..



  • run a mtr to see where the loss starts.


  • Banned

    Try rebooting your modem



  • I would try out searching many common things first and then starting perhaps to play with some NIC or hardware tuning
    to get rid of that problem. Often there will be one or more things to do or tune and not even one point that is changing
    the whole game play. Please think about that.

    • Is this a real and pure modem or is it a router, provided by your ISP?
      Or in other words are you able to tell us the complete vendor name, model and model number?
    • Is it perhaps a negotiation mismatch between the modem and the pfSense firewalls WAN port?
      Can you please try out setting that port to 100 MB full-duplex on the modem site?
      Or better on both sites if able to realize that you are safe to get the right speed!
    • If this is a router from your ISP please set up on the pfSense´s WAN port a static IP from the network of the router
      such 192.168.1.0/24 is the network and you set up 192.168.1.250/24 and this out of the DHCP range of that router please. (only if so)

    pfSense is creating for each cpu core and pending on the Ethernet ports queues, and this queues can be differ from
    other systems based on the used Ethernet card driver such em or igb!

    The amount of the queues and the mbuf size is now important to watch out, because this both numbers playing here
    together in that situation. It is important how fast or not a queue will be saturated or will be filled with data pakcets
    and on the other site how many of them must be filled!

    hw.igb.num_queues="4"
    

    or

    hw.igb.num_queues="2"
    

    with HT disabled or enabled would be my first try and then you could try out to play with the entire mbuf size from 1000000
    up or downwards.

    This can be done in here:
    /boot/loader.conf.local
    kern.ipc.nmbclusters="1000000"
    (this must be tested out by your own)

    machdep.hyperthreading_allowed="0"
    (1 or 0 as on/off)

    hw.igb.num_queues="4"
    (2 or 4 I would try out)


  • Rebel Alliance Global Moderator

    "- Is it perhaps a negotiation mismatch between the modem and the pfSense firewalls WAN port?"

    It would be way higher than 5% packet loss if it was..



  • I would rule out the modem first…

    Disconnect the PFSense box and plug a laptop into that same port. If you are using a DHCP WAN it should pull an address from the modem (unless you had it scripted otherwise) and you can do a continous ping check to an external site. Check packet lose over time of 20 minutes or so.

    If you are on a static, simply configure your laptop NIC to the static information the ISP provided you and perform the same test.

    Once you know if it is the modem or not, we can provide you with better answer. (other things it could be, bad WAN cable, issue with PFSense Port, Issues with Modem Port etc....) doing this test can rule some of those out.

    As for preferred DNS.

    You could use something like namebench to find best DNS near you.

    https://namebench.en.softonic.com/

    I was using my default ISP dns for awhile, after running the tool I found OpenDNS was 200% quicker. I changed to that, its been pretty nice.

    Make sure to run the tool though because depending on your area/routes, you may get different results.


  • Rebel Alliance Global Moderator

    Or just use unbound and let it resolve vs forward.  Now you have dnssec for sure and doesn't matter how shitty your isp dns is ;)  200% faster vs what.. 30ms 60ms – lets say you go from 60ms to 10ms - what does it matter since once you get it once its cached anyway.  Your talking .6 of a sec vs .1 of second - doesn't make much a difference either way.  I would much rather resolve and have full dnssec vs shave a couple of ms off looking up something.



  • @johnpoz:

    Or just use unbound and let it resolve vs forward.  Now you have dnssec for sure and doesn't matter how shitty your isp dns is ;)  200% faster vs what.. 30ms 60ms – lets say you go from 60ms to 10ms - what does it matter since once you get it once its cached anyway.  Your talking .6 of a sec vs .1 of second - doesn't make much a difference either way.  I would much rather resolve and have full dnssec vs shave a couple of ms off looking up something.

    It does matter, especially if his ISP DNS is having issues….

    Other DNS providers also provide features that standard ISP DNS's do not, such as content filtering, more redundancy etc... and shorter load times.

    This is why I said run the tool. it will give you those results and even a log you can review to see how stable your ISP DNS really is. If it warrants a change. Its worth trying.

    It worked just fine for me and I've noticed an decrease in my loading times overall on my network by simply doing this.

    As for caching, again it kinda does matter since there is a TTL for cached sites and they will have to rehit the website to pull new changes. This helps with that and also assists in pages not cached.

    There is quite a few reasons to move from the default ISP DNS...

    Normally for my clients, leave them on the default DNS unless there is a reason to warrant a change (such as unstable or very slow lookups). However, that doesn't mean that is everyone's preference.



  • Indeed there is a lot of gotchas in running your own resolver.

    For caching, the likes of google dns since they have so much traffic the chances of something been cached is much higher vs using your own resolver, unbound has a prefetch system but it is poorly implemented.

    My own setup is now something like this.

    Unbound as a local network forwarder, dnssec is disabled as its a forwarder.
    In forwarding mode it will still cache dns results, I have it set to force the min ttl to 86400 which is very aggressive.  But the lan is just me, I accept the consequences of that.  In the internet world, many large sites now use extremely low TTL records which for the most part means a local dns server is always going to have uncached records as these TTLS are often under 1 minute, in some cases less than 10 seconds.
    Unbound forwards to my own BIND server via dnscrypt, the BIND server has dnssec enabled and also prefetching enabled, BIND's implementation of prefetch is a lot superior to unbound and configurable, I have configured it to more or less always prefetch a new record whenever the cache is accessed.

    I would only enable dnssec on on unbound if its the resolver, not a forwarder.  I still have some other security features enabled tho such as use-caps-for-id which BIND has no implementation off.


  • Banned

    @AndroBourne:

    @johnpoz:

    Or just use unbound and let it resolve vs forward.  Now you have dnssec for sure and doesn't matter how shitty your isp dns is ;)… ...Your talking .6 of a sec vs .1 of second - doesn't make much a difference either way...

    It does matter, especially if his ISP DNS is having issues….

    No it doesn't, resolver doesn't use his ISP's DNS at all, for anything.