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.
"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.
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 ?
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...