Wired Intelligent Edge

Greetings....

I'm transitioning our current network from OLD Dell Switches, vintage 2004, to new Aruba 8230CX Switches. While that process is pretty easy, the network is another story.  A quick background... At one point in time someone merged three organizations. You would think that they would have taken a bit of time to merge them into a coherent scheme. LOL, no. Chaos ensues. 

Now I'm transitioning all the networks into a new Scheme while maintaining all the old ones temporarily. Ugh. The primary switch already has all the routing to the OLD Firewall (SonicWall TZ500) in place. (Not that it could handle the incoming bandwidth, but that's another story.)

My strategy for this network transition is going to put the new network/switches between the Old Network, and the new HA Firewalls (Sonicwall NSA 5650). This is where my questions start... 

1. Assuming the NSA 5650's IP is 10.10.10.1 and the new 8320 is 10.20.200.1. Using ports 1/1/47 and 1/1/48 (Primary and Secondary) on the 8320, how do I configure the 8320 to use 47 as primary and 48 as secondary? Is there an example I could see?

2. Do you have any other recommendations on migrating the primary routing to the new 8320?

Thanks for everything.

Piet

Hi! interesting...very first question first: you wrote Aruba 8320 switches...thus...are you planning to deploy a VSX (two Aruba 8230 Switches forming a Virtual Framework for connected peers)?

The answer to the above preliminary question has some effects on your deployment strategies (especially against your Firewall Cluster [Primary]/[Backup(HA)]), at least related to physical connections used to connect uplink peers.

Thanks for the response question... Oh. Hmmm... 

I hadn't planned on it, since I didn't have the funds to implement it. Yet, I can see the benefits of it. Suggestions?

Currently we're implementing End of Rack Row (RR) Switching..

With RR-B and RR-C both having a single 8320 (48 10G ports, 6 40G ports)

RR-B is connected via 1/1/47 & 1/1/48 to RR-C 1/1/45 & 1/1/46

(They would be connected 40G, but I can't afford it.)

Row D has the 2 SonicWall 5650s which are connected via a single 10Gb connection to in each one to RR-C 1/1/47 & RR-C 1/1/48

Thanks for any suggestions or changes you would suggest. 

(OR if you know a good place to get the 40GB transceivers from would be awesome.)

Thanks.

Piet

Ah...one Aruba 8320 as EoR Switch on each Row...OK. I suppose the (interface to interface cable) distance between your two Aruba 8320 EoR (Row B and Row C) is longer than 5 meters...otherwise a couple of HPE X242 40G QSFP+ to QSFP+ 5m DAC Cable (JH236A) shouldn't be too expensive (in relationship with the price of the whole solution).

I miss the point of connecting the Firewall HA Cluster located on Row D to EoR Switch located on Row C only...but that's probably related to the fact that Row B and Row C represent the new networks while maybe a Row A represents the old (legacy) networks...that's because you wrote your plan is to place new switches - I read the Aruba 8320 - between the Firewall HA Cluster Row D and the old network (or, maybe, simply there isn't a Row A and so Row B is just the old while the Row C is just the new). Anyway it looks like you're going to create a chain where Firewall HA Cluster Row D <----> EoR Row C standalone Switch <-- 2 interface simple LAG --> EoR Row B standalone Switch...at least from the physical point of view.

Back on track, you initially asked:

---

@pietvw wrote: Assuming the NSA 5650's IP is 10.10.10.1 and the new 8320 is 10.20.200.1. Using ports 1/1/47 and 1/1/48 (Primary and Secondary) on the 8320, how do I configure the 8320 to use 47 as primary and 48 as secondary? Is there an example I could see?

---

So the standalone Aruba 8320 (EoR Row C) should be connected via at least two physical links to the SonicWall NSA 5650 HA Cluster...is that deployed as an Active/Active Clustering (so with Cluster Virtual IP address)?

Who will do the IPv4 Routing (the Aruba 8320 in EoR Row C?)? what I think is simply that LAN ports (from both NSA nodes) would be tagged carrying a transit VLAN id and those ports should land to tagged (access) ports on the EoR Row C standalone switch...then you can use the dedicated transit VLAN id (a /29 should be enough) to route traffic from the Aruba to your Firewall HA Cluster...but probably that's too simple because you need to deal with and existing router somewhere (legacy/old networks) at least until you decide to route old to new via another dedicated transit VLAN id and that would happen also between old network router and one of the two Aruba EoR Switches.

Edit related to VSX:

---

@pietvw wrote: I hadn't planned on it, since I didn't have the funds to implement it. Yet, I can see the benefits of it.

Well...VSX technology came at no extra cost (ArubaOS-CX is already full featured)...at best you have just to (a) add in your BoM cables or transceivers to interconnect both Aruba 8320 to form the VSX (this can be cheap with DAC cables or expensive with Transceivers, especially if the interconnection is done using 40 Gbps ports) and have - more importantly - (b) a valid reason to create and use a VSX solution (potentially it could be your case...or not)...it really depends on the topology you want to deploy and your "resiliency/SPoF" requirements on that topology: if each Servers' Row is simply going to end into its EoR Switch and nothing more (no resiliency against potential EoR Switch failure)...I mean if each Row is isolated and the only interconnection point(s) between Rows are - correctly - the link(s) you will deploy between each EoR Switch...then it is quite clear that you don't need benefits the VSX adds exactly because the particular design adopted is going to made the VSX approach useless (or difficult at best...cabling should go back and fort between Rows)...if, instead, you're going to consider a more resilient approach on each Row...then the EoR Switch should have a technology/feature to offer it (so you need some sort of inter-Row resilient solution - call it VSX, VSF, virtual switching - on each EoR or, worst case, some intra-Row resilient solution where both EoR Switches are resiliently interconnected...but in this latter case the entire Row EoR concept breaks because nobody want a Row B Server being concurrently connected to both its Row B EoR Switch and also to the near Row C's EoR Switch...it's more correct to have a Row B (or C) Server being connected to a pair of EoR Switches into its row's end rack, virtualized...made resilient). Just speculations. Sorry for convoluted suggestions.

Ok. It seems like I'm right on the money for the initial stage of this
network. Quick physical layout for you....

Rack Rows (RR) A - H
Each contain 6 individual racks
Network termination is currently HomeRun to RR-D

It's in such a chaotic mess since it wasn't documented and it's interwoven with various video and audio cables in the floor. (Ugh.) We won't get into the aspect of how many of those cables are actually dead cables. Then of course we have many "un-documented, un-managed, and un-known switches" in our equipment room. 

To fix this I'm putting a pair of switches at the end of each RR(Redundancy). Then we're running new patch panels/cables overhead from the end of the RR to the top of each rack.  Then finally RR-D is getting the final pair of 40Gb Switches. Those switches will be connected to the SonicWall NSA 5650s (10Gb) and to every RR pair of switches (40Gb). 

That's the end goal...
So how do you get there from here with limited funds and lots of additional projects? (Domain Server replacements, VM-Ware implementation, servers consolidation, storage implementation, etc)

Fortunately, I'm pushing three heavy projects in front of this one...2008 Domain Server replacements, VM-Ware Implementation both required new servers and IP Topology re-design.

Then we started seeing failure in a cheap 10Gb Switch which is On-Air critical, which was my push to replace it with a good switch(RR-B). Then of course the new Dell Servers were all 10Gb based, and I needed a switch that could do 10Gb. Those were in (RR-C). We purchased two 8320s one for each rack with an eye looking forward to the end goal.

Which brings me to where I am right now.

Ideas and thoughts?

A quick follow up on this.... Since I always hate questions that don't get resolved in forums like this.

Two Sonicwalls 5650s in HA configuration... 

Both Sonicwalls  on Port 27 (10Gb) connected to an Aruba 8320 port 1/1/47 and 1/1/48

The initial thought was to LAG the two together; however, in a LAG configuration it requires LACP to be working. That isn't the case with the Sonicwalls in HA configuration. Sonicwalls in HA configuration literally have a port working on one switch and then when that switch fails the other one becomes active!

Here is what did work... 

(IPs of course have been changed)

Sonicwall IP port 27 configured with a static IP: 192.168.0.1/24 with HA setup.

On the Aruba 8320s... 

We create a VLAN specifically for the Sonicwall...

vlan 199

     name SONICWALL VLAN

Give the Sonicwall VLAN an IP Address on the same subnet as the VLAN.

interface vlan199

     ip address 192.168.0.2/24

Then we defined each of the interfaces to only access vlan 199

interface 1/1/47

     no shutdown

     no routing

     vlan trunk native 199

     vlan trunk allowed 199

interface 1/1/48

     no shutdown

     no routing

     vlan trunk native 199

     vlan trunk allowed 199

Finally... we set our default  route to point to the Sonicwall.

ip route 0.0.0.0/0  192.168.0.1

Voila... It's working in a Fail-Over mode...

Hi! the sentence:

---

@pietvw wrote: Give the Sonicwall VLAN an IP Address on the same subnet as the VLAN.

---

should be read as "Give the Aruba 8320 switch a VLAN - exactly the VLAN id 199 - with a SVI within the same net used on the Sonicwall"...isn't it?

Basically you defined a Route of Last Resort (0/0 via Next Hop Gateway) to the Sonicwall SVI IP Address using a dedicated "transit" VLAN (with regards to addressing, probably a /29 would be enough for the purpose).

A thing is not entirely clear to me is: on the Sonicwall HA side, is the SVI it was assigned to..."real" or "virtual"?

I mean: a SVI IP Address 1 on Sonicwall node 1, a SVI IP Address on Sonicwall node 2 and a common SVI IP Address "vitually" assigned to the entire HA cluster, this one exposed to peers.

We have Forcepoint HA (Active/Active) and each L3 interface on the Firewall Cluster requires three IP Addresses (2 NDI and a CVI, NDI on each FW node and CVI is the "vitual" one exposed to downstream peers)...and, to be honest, L3 can be configured on top of a LACP LAG on each FW node so...downstreaming to a single Aruba switch...a LACP LAG approach from each FW node would work (exactly as downstreaming to a VSX provided that VSX LAGs are used) <- here I'm not sure if/how the Active Forwarding part would kick in.

An interesting presentation with some scenarios is available here, I think at page 67 (would be great to see it enhanced with more Firewall HA scenarios against VSX).

Could you please look at Appendix B and F of VSX Best Practices:

https://support.hpe.com/hpsc/doc/public/display?docId=a00094242en_us

and let me know between these 2 Appendixes if there are cases not covered that you would like to see being added.

Hi Giles, don't know if you were referring to my reply...and I don't want to go OT or hijack this thread...in any case, thanks you for your precious time and deep knowledge...our potential VSX scenario (with just a single default VRF or  with multiple VRFs) is going to involve two Firewalls clustered in a Active/Active mode (in A/A mode OSPF is not supported on our Firewalls Cluster), the cluster's nodes are driven by a single routing policy (settings) where just three IP Addresses are necessary/used per logical interface (2 NDI, 1 CVI: this requirement is valid on internal facing ports...to LAN/DMZ...and also on external facing ports...to WAN)...so now I'm trying to figure out what scenario fits examples found on documents available (included the one you linked).

That would be Appendix E.