After 2.0.2 upgrade unable to upload at same speed.



  • Hello,

    I was hesitant to post here as it just doesn't sound rite….

    Last Friday night I noticed there was a 2.0.2 upgrade available.  I applied the update,  loaded one or two sites,  things seemed fine.  Then I went home.

    came in on monday and by the afternoon we were getting many complaints about slow internet.    I tested and sure enough it seemed to be having issues.

    typically we can push/pull 90-95 megabits/sec,  now we can pull 87 megabits but can only push 3 megabits!  I involved the ISP,  they did an end to end test and confirmed all was well.

    Our set up is as such:  INTERNET <> JUNIPER ROUTER <> PFSENCE <> INTERNAL NETWORK

    with a routed (not nat) DMZ hanging off the Juniper.  The Juniper also handles the NATn' for the internal address space,  the pfsense box does not nat,  only firewall and route,  no Queues defined,  or limiters or anything for that matter.  Just Squid(transparent) and a few monitoring report generating things installed.

    the reason I suspect the pfsence box at this point is due to the fact machines in the DMZ are able to push/pull data as expected.  its only when you are on a machine behind the pfsence box do you see the 2 megabit xfer rate.  from pfsence box itself I'm not seeing the rates I'm expecting either.  tried a few sites and got up to 300/K sec..

    I've confirmed all interfaces are running clean and the port speed/duplex is set correctly.  Everything seems ok that i've looked at thus far.

    Prior to this incident,  the box was in service for about 2 years or so,  updated a few times,  rebooted a few times,  all without issue.  it wasn't until this week it would appear there is something not happy..

    anyone else experience this post upgrade?  I suspect it has nothing to do with the upgrade and is a coincidence ..

    take care,
    greg



  • Indeed that's unlikely to have anything to do with the upgrade. That sounds a lot like the symptoms of a duplex mismatch, where your WAN NIC is set for autonegotiation and the port you're plugging into from your provider is fixed speed and duplex, or vice versa. Usually upload speed takes a major hit and download not as much in such circumstances. What is your WAN plugged into? You have your side set for autonegotiation or fixed speed/duplex?



  • @cmb:

    WAN plugged into? You have your side set for autonegotiation or fixed speed/duplex?

    The ISP link is fixed at 100/FD,  the others were auto for 1G,  tried both hard and auto on both sides in an effort to eliminate that as a suspect.  When I view the interface stats within the gui they report zero. (btw do you happen to know the flag for ifconfig which will display the media errors?)  The switch is reporting no errors as well.  I too suspected it was a duplex/speed mismatch but that wouldn't appear to be the case.

    We recently 'turned on' jumbo frames on the network,  this would of been the first time the pfsence box was rebooted since that happened.  My understanding of jumbo frames on network gear is "i'll accept a frame up to this size" so it shouldn't have any effect I'd have thought.  but i'm wondering now as I write this if perhaps the switch isn't negotiating window send size with the pfsence's interface perhaps…  I'll do a port mirror and sample the data there to see if maybe that is it..

    that all said,  today things seem to be better.  haven't done any threw-put testing but i do see DNS answers are quicker and pages are not having the same delay before loading as before.

    BR-SSH@CORE0>show interfaces ethernet 2/22
    GigabitEthernet2/22 is up, line protocol is up
      Hardware is GigabitEthernet, address is 748e.f83e.6800 (bia 748e.f83e.682d)
      Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
      Configured mdi mode AUTO, actual MDI
      Member of L2 VLAN ID 199, port is untagged, port state is FORWARDING
      BPDU guard is Disabled, ROOT protect is Disabled
      Link Error Dampening is Disabled
      STP configured to ON, priority is level0
      Flow Control is config enabled, oper enabled, negotiation disabled
      Mirror disabled, Monitor disabled
      Not member of any active trunks
      Not member of any configured trunks
      Port name is TO_INTERNET-VIA-PFSENSE-bce1
      IPG MII 96 bits-time, IPG GMII 96 bits-time
      IP MTU 10218 bytes, encapsulation ethernet
      300 second input rate: 34635272 bits/sec, 3672 packets/sec, 3.51% utilization
      300 second output rate: 5824496 bits/sec, 2221 packets/sec, 0.61% utilization
      380057288 packets input, 410302643116 bytes, 0 no buffer
      Received 358 broadcasts, 0 multicasts, 380056930 unicasts
    **  0 input errors, 0 CRC, 0 frame, 0 ignored
      0 runts, 0 giants**
      268451618 packets output, 113011198307 bytes, 0 underruns
      Transmitted 1053 broadcasts, 886490 multicasts, 267564075 unicasts
    0 output errors, 0 collisions
      Relay Agent Information option: Disabled



  • Ok since the ISP's port is forced, whatever you're plugging that port into must be forced. If the firewall is straight into that port, set 100/full on the WAN. If there's a switch in between, the port where the ISP's gear plugs in must be 100/full and leave the firewall and its port on auto.

    If it were jumbo frames related that would almost certainly have much different symptoms. That most always exhibits itself as certain sites not loading fully or at all, but other sites working perfectly fine.



  • Any reason why you need the Juniper and the pfsense, why not ditch one or the other (preferably the juniper)…?



  • Oh I overlooked the Juniper in between. Can you get proper speed to/from the DMZ off the Juniper? That may at least further narrow down where the issue exists.



  • Yup, process of elimination

    ISP –> direct to computer
    ISP--> Juniper --> Computer
    ISP--> PFSense --> Computer



  • @cmb:

    Ok since the ISP's port is forced, whatever you're plugging that port into must be forced.

    yes,  I think i indicated this was the case already,  and I have re-confirmed it to be so.  Zero errors on all interfaces involved in the path.  8(

    using iperf and testing threw ISP3:

    internal network to DMZ's: full rate.
    pfsence box to DMZ: full rate.

    DMZ to internet: full rate.
    pfsence to internet:  slow (5 megabits)
    internal to internet via pfsence/squid: slow (5 megabits)

    it feels as if some limiters or QoS I set up before were 'turned on' again,  but i've confirmed via the GUI the config for them are all gone,  including the acl's set up in squid.

    At this point I think I'll just fail it over and re-stage it.  the other pfsence box works as expected,  thinking I don't want to consume to much  more company time problem solving it.

    thanks cmb,
    -g



  • @SysIT:

    Any reason why you need the Juniper and the pfsense?

    yes.

    -g



  • just as a follow up,  everything is normal again after re-staging.  I've no idea what it may of been or if the re-stage is related to regaining our threwput to that particular ISP (we had 3 ISPs,  with only one affected by this issue)  but we are good again.

    take care and thanks for the attention,

    greg



  • What does "re-staging" mean?

    Did you wipe clean the disk / cflash and re-install pfsense 2.0.2 and restore the .xml config file?



  • @dhatz:

    What does "re-staging" mean?

    to clear and set up a device for redeployment,  after it had been in service.

    Did you wipe clean the disk / cflash and re-install pfsense 2.0.2 and restore the .xml config file?

    format yes,  restore no.  I didn't want to potentially import the issue.  As I mentioned my set up is simple,  it firewalls,  proxies,  routes, reports  and has fail over set up.  everything else is basically disabled or at default values so there wasn't a lot of vaule to use the xml.  Only took a few minutes to put it back to where it was.  Keeps you familiar with where the settings are which you don't often access.  8)

    -g


Locked