cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
814
Views
0
Helpful
7
Replies

NAT and throughput problem

willy moronta
Level 1
Level 1

Hello I've recently ran into a bit of problem with an added network segment.

The basic network before said addition has clients connecting via distribution 2960s up to a 3750 which has L3 vlans IP routing enabled this sends all traffic to a CPE MPLS device (provider managed) which checks to see if its MPLS or web traffic if its web traffic its sent to our ASA than to outside 2901 router.

So inside network 10.10.10.0/24 is dynamically NAT'd on the ASA interface various vlans live on 10.10.10.0/24 each subnetted.

We now have a completely separate newtwork 172.19.2.0/24 which is at the same physical location, and has its own MPLS routes etc - managed by a different group.  In order to get internet access we've connected a Sonicwall to the core 3750 on the 10.10.10.0/24 network said sonic wall has an IP of 10.10.10.3/26 assigned to vlan500 with same DG as every other device on this vlan.  So traffic on 172.19.2.0/24 is directed to the sonicwall and outside traffic is directed to the gateway of vlan500 which than directs traffic to the web.  On the inside of the ASA I created a route 172.19.2.0/24 via 10.10.10.3/26 traffic gets in and out fine, but throughput is very low.

So a client on 172.19.2.0/24 hits gateway 172.19.2.3 (sonicwall inside interface outside interface 10.10.10.3) that device has a gateway of 10.10.10.5 (default gateway for all 10.10.10.0/26 devices) than its sent to internet passing through ASA an outside router.  The throughput on this is horrible about 10MGs up.  All cients on 10.10.10.0/26 are getting upwards of 100 with no problems. 

I've checked the switchport on the 3750 (that is connecting to the sonicwall) and the load never reaches above 75/255 - there are no errors - crc or late errors or otherwise on the switch interface (sometimes see those errors when dealing with inter vendor devices)

Could the way we're doing the NAT (from 172.19.2.0/24 to 10.10.10.0/24 to outside) be a problem for throughput?  Sadly I dont have access to the sonicwall but I want to make sure I do all I can on my side before I reach out to other team.  Any help would be appreciated.

7 Replies 7

Jon Marshall
Hall of Fame
Hall of Fame

Willy

I have read through this about 5 times and still can't understand it  although it could be me

So you are changing the 172.19.2.x addresses on the Sonicwall to 10.10.10.x addresses which then sends the traffic to your MPLS CE device which then sends it back to the ASA.

Is that correct ?

How does the return traffic work in terms of your normal clients ie. the CE device forwards it to the ASA but then the ASA simply sends it back direct to clients ie. not via the CE device ?

Perhaps you could clarify ?

Jon

Hi Jon, thanks for your answer.

"So you are changing the 172.19.2.x addresses on the Sonicwall to  10.10.10.x addresses which then sends the traffic to your MPLS CE device  which then sends it back to the ASA. " that is correct and the ASA than has a route for traffic on 172.19.2.x to go directly to 10.10.10.3 (sonicwall interface).  And this is asymetrical routing which I had to create special allowances for on the ASA (5510)

For normal clients the return traffic takes the same path in as out - so it goes via the CE.

I may be misunderstanding but  i thought  that when 172.19.2.x clients go to the internet the Sonicwall changes the IPs to it's outside interface IP 10.10.10.3 and so traffic gets sent to the CE device.

You seem to be saying in your lastest response that is what happens.

But then you say that you have route on the ASA pointing to 172.19.2.x but those  IPs would not be visible to the ASA ie. because they have all been changed by the Sonicwall on the outbound path.

I can't see how that would work.

Jon

Well yes the clients on 172.19.2.x have a gateway of 172.19.2.5 (sonicwall)

This sonicwall has inside interface 172.19.2.5 this sonicwall sends all 0/0 (web) traffic to 10.10.10.3 (sonicwall interface directly attached to switch)  Switch has GW of CE for the purpose of checking for mpls traffic - any other traffic (web) it will forward directly to the ASA.

The ASA has a permit statement to allow traffic to be sent to 10.10.10.3 as thats asymetrical (otherwise packets would be dropped) it also has a static route to 172.19.2.0/24 via 10.10.10.3 that's how return traffic gets back (until I put this statement in no traffic was returning to clients) , this is now working and traffic is getting through to internet.  The problem Im having is throughput.

Does the Sonicwall NAT all 172.19.2.x traffic to 10.10.10.3 ?

If so does that traffic then get sent to the CE device ?

If so it then gets sent to the ASA ?

So the ASA only sees 10.10.10.3 traffic ie. the route for 172.19.2.x isn't used because it will never see packets with either that as a source or destination IP because it has been changed by the Sonicwall.

If the ASA only sees 10.10.10.3 then why does it not send it back the same way it would send all other 10.10.10.x/26 IPs ?

Jon

You make a very good point Jon

Im assuming the sonic wall is NATin but it may not be - which would explain why I had to put in the route for 172.19.2.x on the ASA.  I did this without thinking it through it simply clicked in my head that return traffic had no way to respond and soon as I did it started working and left it at that.

Im going to find out if that sonicwall is in fact NATn traffic or simply redirecting to the 10.10.10.3 which in turn is doing what it normally does with unknown traffic - send it to the CE and last to the ASA - which I think is whats happening.

Question since connectivity seems stable do you have some thoughts on where I can look for the bottle neck?  Basically the switch - asa or the sonicwall - so far I've only looked at the switch, because its a live environment my window to debug on the firewall is after 6pm.

If the switch is not showing any drops on both Sonicwall interfaces then i would assume it is working okay as otherwise the existing clients would be showing the same symptoms ie. if it was high CPU for example this would affect everyone on that switch.

Have you checked both the Sonicwall interfaces on the switch. What speed are the firewall interfaces capable of and are youy running at that speed. What is the actual trhoughput of the Sonicwall etc.

I'm not definitely saying it isn't the switch but the first thing i would do is trace the full path from a 172.19.2.x client to and from the internet and one of your existing clients and see if the path diverges anywhere.

It could be something to do with that but you won't know until you find out about the NAT setup and how it is actually working.

Difficult to say more without more information but feel free to ask anything and also post back at any time if you don't make any progress with it.

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco