SG-135 Bandwidth Issues

I have to ask - why are you even using the Barracuda when your filtering is/could happen at the SG-135?  Are you filtering on both devices?  If so, I would be surprised that you aren't reporting other speed issues.  I would check that first.  The hub might also be an issue if it's not a managed switch, and not sure why its there...

From how you are describing it, it's very possible your routing is through the T-1.  Can you show us a diagram of this layout?  I know Bob would ask for that one, as would I.  I'm a really visual guy.    You can click and drag the pic right into the text field of the forum to show it.

Thank you for the reply, Amodin. Like I mentioned, I inherited this, ummm, interesting configuration. :) So I'm still trying to unpack everything as I've only been here a few weeks. I suspect the Barracuda is still there because my predecessor maybe didn't know any better and the business users have been without meaningful IT assistance for several months.

It is an unmanaged hub, it's there because the Comcast modem is at the other end of the building, so there's only actually a single run of Ethernet from the Comcast modem to the server room, so that's why the hub sits between Comcast & the FWs. The FW engineer at our fintech did rule out the unmanaged hub as a failure point (coincidently, it was replaced recently). Between his feedback and I'd find it hard to end up with TWO bad hubs (Yes, not out of the realm of possibility), I don't think that's it. That's why I was landing on possible FW configuration and/or could it be routing outbound traffic over the PTP T1? I'll see if I can put together a basic diagram of the setup

Thank you,

Rob

Attached is my attempt at the diagram. The Barracuda is functioning as the default gateway for connected devices on the LAN. The near side of the PTP has a LAN IP, as does the Sophos FW. So I'm wondering, when running a speed test, is the DOWN test coming through Comcast, while the UP is being routed out to the PTP, over to the LAN at our main branch, and out the internet that way???

It just seems awful coincidental that the UP speed hovers around 1.5Mbps, which is also the speed of a T1.

Thanks,

Rob

1072.Network Diagram.pdf

Have you tried a traceroute to see what route that traffic is going? 

Thanks for the diagram, it seems to me that you have some 'extras' in the network, i.e., the Barracuda.  The SGs can perform all the functions you mentioned.

I probably should have mentioned to show some IPs (doesn't have to be all of the IP, just something like - 10.2.x.x, etc.) to see the routing, but I would wager the Barracuda is probably routing traffic through the PTP line, and my guess is someone at corporate IT wants it that way for some kind of filtering of traffic.

Your PTP might also be an issue - Is this a secondary connection, in addition to your internet connection?  You could do an MPLS connection if so, but I believe that would require an ISP change (for everyone to be on the same provider).

Agreed on your comments about the Barracuda. Still trying to unpack why things are the way they are in the environment. One thing I've heard is because the Barracuda provides/provided fancy web filtering/traffic reports to the VP of Ops and CEO.

I'm completely onboard with your comments about removing the Barracuda, I just need to go to our 3rd party fintech and say "CEO is used to X with the Barracuda, how can we produce something similar with the Sophos?" And then, remove them (plural, see below). 

Main Location: Verizon ISP = 67.98.x.x, LAN = 192.168.1.x (LAN1)

2ndary Location: Comcast ISP = 75.145.x.x, LAN = 192.168.2.x (LAN2)

The PTP is connecting the two LANs together.

So a tracert from the 2ndary location (where the problem exists) to www.microsoft.com, hits the LAN2 default gateway (i.e. the Barracuda), then hits the Comcast ISP, and while response times are sub 20ms, RTT3 is an * on just about every hop. Here's where it gets interesting (at least I think so). Doing the same thing from the main branch, hits the LAN1 default gateway (another Barracuda), then hits the Sophos, then hits the Verizon ISP. All hops are normal.

That is, the localized LAN traffic appears to be routing out of each location's corresponding ISP. The difference is traffic at the 2ndary branch goes from the Barracuda straight to the ISP. Whereas the main branch goes to the Barracuda, then to the Sophos, then to the ISP. And yes, I need to remove the Barracudas from each location... 

And for some added context, I've done all kinds of configurations regarding removing pieces of equipment to eliminate points of failure...That is, I've removed the hub, the Sophos. the Barracuda, the LAN switch, etc. The only thing I haven't been able to do is go directly off the Sophos (e.g. Comcast --> Sophos --> Laptop (even setting static IPs and gateways)). However, every time I reintroduce the Sophos into the mix the bandwidth constraints reappear. So that's why I'm convinced there's some kind of misconfiguration with the Sophos. If the Sophos is not in the chain, I'm getting advertised speeds from the ISP.

Part of my goal is to also remove the PTP with something else, but still researching what that should be. At my former company we did a Windstream MPLS between a 3rd party and our data centers, I just need to research if there are better technologies out there, but they need to be budget friendly for a mid-sized business.

Agreed on your comments about the Barracuda. Still trying to unpack why things are the way they are in the environment. One thing I've heard is because the Barracuda provides/provided fancy web filtering/traffic reports to the VP of Ops and CEO.

I'm completely onboard with your comments about removing the Barracuda, I just need to go to our 3rd party fintech and say "CEO is used to X with the Barracuda, how can we produce something similar with the Sophos?" And then, remove them (plural, see below). 

Main Location: Verizon ISP = 67.98.x.x, LAN = 192.168.1.x (LAN1)

2ndary Location: Comcast ISP = 75.145.x.x, LAN = 192.168.2.x (LAN2)

The PTP is connecting the two LANs together.

So a tracert from the 2ndary location (where the problem exists) to www.microsoft.com, hits the LAN2 default gateway (i.e. the Barracuda), then hits the Comcast ISP, and while response times are sub 20ms, RTT3 is an * on just about every hop. Here's where it gets interesting (at least I think so). Doing the same thing from the main branch, hits the LAN1 default gateway (another Barracuda), then hits the Sophos, then hits the Verizon ISP. All hops are normal.

That is, the localized LAN traffic appears to be routing out of each location's corresponding ISP. The difference is traffic at the 2ndary branch goes from the Barracuda straight to the ISP. Whereas the main branch goes to the Barracuda, then to the Sophos, then to the ISP. And yes, I need to remove the Barracudas from each location... 

And for some added context, I've done all kinds of configurations regarding removing pieces of equipment to eliminate points of failure...That is, I've removed the hub, the Sophos. the Barracuda, the LAN switch, etc. The only thing I haven't been able to do is go directly off the Sophos (e.g. Comcast --> Sophos --> Laptop (even setting static IPs and gateways)). However, every time I reintroduce the Sophos into the mix the bandwidth constraints reappear. So that's why I'm convinced there's some kind of misconfiguration with the Sophos. If the Sophos is not in the chain, I'm getting advertised speeds from the ISP.

Part of my goal is to also remove the PTP with something else, but still researching what that should be. At my former company we did a Windstream MPLS between a 3rd party and our data centers, I just need to research if there are better technologies out there, but they need to be budget friendly for a mid-sized business.

Interestingly, I just Googled "T3 Timeouts" and it seems it may be a normal/common thing with Comcast? However, it does seem to also suggest it could be "upstream noise." So could a misconfiguration in the Sophos be creating this upstream noise?

Rneal1973 said:

If the Sophos is not in the chain, I'm getting advertised speeds from the ISP.

Well keep in mind that web filtering is doing its job and you will see a hit, depending on the hardware versus number of LAN clients, due to the filtering action of the SG.  There is also the possibility that the hardware does not support # of clients and could be underperforming.  This is where I would get the reseller involved who can provide support in that field.  I'm betting that not only is Barracuda filtering, but so is the SG - and that is overdoing it immensely.

T3 timeouts are a common occurrence with just about any cable internet provider, I get them all the time with my ISP (Cox).  If you are using cable internet for the bank, I'd suggest something else, and even just a T-1 line would be not only more secure, but a lot more stable.  If this is your current setup with Comcast (cable), you could have a lot of noise in the line due to misconfigurations on their end.  Cable splitting is a horrible thing for internet as well, as it can and will cause T3 errors.  I'd also double check the cables and connectors themselves.  If anything is damaged, or even loose, it can cause you grief.

And to comment about reporting, yes Sophos has reporting ability built in for reports and they aren't bad at all.  I even use them at home for checking my firewall.

You probably need to start re-evaluating your internet usage at the bank, and determine if your needs are being met and you are getting what you actually need.  Upload speeds by default are slow, because almost all residential and some commercial don't actually upload anything - they download and your internet plan most likely reflects it - (50down/3up or something like that) which will be slow uploading.  

Fiber is getting a lot more cost effective now if they are implementing it in your area, and your Comcast account might just be that of a residential plan.  They can also work with you on changing that upload speed if it is slow (I didn't see where you mentioned what your actual ISP service plan was).

Got the FW engineer on the phone this morning and we isolated the issue to ETH0 dropping frames.

Swapped to another ethernet port on the FW and we're cooking with gas!