Hello Werner
@WernerReiche wrote: I have a HP Aruba switch already configured with several vlans - 192.168.14/24, 192.168.15/24, 192.168.16/24. Now I would like to connect a separate network to this switch.
First of all: who is responsible for IP routing on your network? in other terms...who lets an host on a VLAN X to speak with another host on a VLAN Y? is the Aruba switch (which model?)?
I'm not an HPE Employee
@WernerReiche wrote: I take it from your comment that cross VLAN communications is not as an acceptable practice as I have been told.
Hi Werner, absolutely not.
I didn't mean that with my question about who is responsible for IP Routing.
Generally IP Routing enabled on a Switch (clearly a Layer 3 Switch) means fast inter-VLAN routing performances. Add to that proper ACLs in order to strictly manage inter-VLANs communications and you're exactly following a usual best practice (better than leaving the router role to a Firewall....with all limitations such a choice has, in primis being a SPoF and providing uplink interfaces throughput bottlenecks not present on a switch backplane).
My question was asked instead to understand an approximate network topology (question: where is the core router for the network?).
So...you said you have a Switch...but from the configuration you attached I see few DT-LACP Port Trunks so - immediately - a second question pops up well before trying to argument other answers: are you really sure you're dealing with just one switch instead of a pair?
See here what I mean:
trunk 1 trk1 dt-lacp
trunk 2 trk2 dt-lacp
trunk 3 trk3 dt-lacp
trunk 4 trk4 dt-lacp
trunk 5 trk5 dt-lacp
trunk 6 trk6 dt-lacp
trunk 7 trk7 dt-lacp
trunk 8 trk8 dt-lacp
trunk 9 trk9 dt-lacp
trunk 10 trk10 dt-lacp
trunk 11 trk11 dt-lacp
trunk 12 trk12 dt-lacp
Above there are twelve DT-LACP Trunks (port aggregations): DT-LACP means Distributed Trunking LACP Trunk...so not a normal LACP Trunk, not a normal port aggregation...it means that there is ANOTHER switch in the picture...where is the SW2?
By the way the fact that this swith is (or was) part of a pair is clearly evident looking at the few running configuration lines (I rearranged their order to make that more evident):
interface 47
name "SW1.47/SW2.47 - Interswitch Trunk"
exit
interface 48
name "SW1.48/SW2.48 - Interswitch Trunk"
exit
trunk 47-48 trk100 trunk
switch-interconnect trk100
interface 46
name "SW1.46/SW2.46 - Peer Keepalive"
exit
vlan 1050
name "PEER_KEEPALIVE"
ip address 192.168.3.1 255.255.255.0
exit
distributed-trunking peer-keepalive vlan 1050
distributed-trunking peer-keepalive destination 192.168.3.2
Interface 47 and 48 are aggregated in a static trunk logical interface (trunk 100) used as the ISC Inter-Switch Connection link (also known as Switch-Interconnect) between SW1 and SW2 Switches. Interface 46 instead is used as the necessary Peer Keepalive link between the two switches and it should be configured ad untagged member of a dedicated VLAN id 1050 and it is also configured to speak with its SW2 peer Switch contacing its peer interface at 192.168.3.2 (from 192.168.3.1).
The strange thing is that port 46 was configured to be untagged member of VLAN id 1001 "AHMS_PUBLIC" instead. of being untagged member of just dedicated VLAN id 1050...and I believe this was (is) an error.
Then the things go nice...IP Routing is enabled and there are few static routes, that's fine...but...since there are signs of Distributed Trunking there are also signs of VRRP (Virtual Routing)...and indeed you can found them here:
router vrrp
virtual-ip-ping
exit
vlan 1001
name "AMHS_PUBLIC"
untagged 13-22,27-34,45-46,Trk1-Trk4
tagged Trk100
ip address 192.168.14.1 255.255.255.0
vrrp vrid 101
virtual-ip-address 192.168.14.1
priority 255
enable
exit
exit
vlan 1005
name "AIM_PUBLIC"
untagged Trk5-Trk8
tagged Trk100
ip address 192.168.15.1 255.255.255.0
vrrp vrid 105
virtual-ip-address 192.168.15.1
priority 255
enable
exit
exit
vlan 1006
name "AIM_CLUSTER"
untagged Trk9-Trk12
tagged Trk100
ip address 192.168.16.1 255.255.255.0
vrrp vrid 106
virtual-ip-address 192.168.16.1
priority 255
enable
exit
exit
So...what are you trying exactly to achieve? are you trying to repropouse a switch previously used (and so the posted running configuration is only partially good for the new role...) or is this just half of the whole picture?
I suspect - I say with totally positive and genuine intents - you aren't fully aware (I mean...it's not your fault!) of what the configuration you posted means...actually.
I'm not an HPE Employee
Just an addition...
@WernerReiche wrote: My previously noted "networks guy" set this up. I did the original setup for this 8 years ago and didn't use any VLANs - he's looked after it since then. The guy is/was pretty smart - but liked doing things in excessively complicated ways because it was "proper".
well...I didn't know the story and the evolution of your network setup...so I don't know if - initially - you designed your network with the Distributed Trunking and VRRP approach in mind...I don't believe so...because you wrote you didn't use any VLAN (apart the default VLAN, I add)...but I can't be sure about that.
Apart from that I find the sentence about doing things in excessicely complicated ways...funny...indeed the guy could have planned to stack (Backplane Stacking) the two JL076A switches together to let them form a single logical entity...avoinding DT and, more important, avoiding VRRP (...there always many ways to skin a cat (sometime you have to pay a little bit more - backplane stacking deployment requires to purchase two Stacking Modules and at least one Stacking Cable - but the design outcoming is that doing so the system will become simple to maintain and shows benefits...example you would have saved six - 3+3 - 10GBase-T ports on the frontplane, just as example).
I'm not an HPE Employee
Hi Werner, your purpose and your scenario are now clear.
Since:
- the remote VLAN ids don't exist (yet) on the Aruba 3810M DT pair
- your network designs are focused on deploying isolated networks (would be insecure to simply stretch an existing Layer 2 VLAN to a new network switch...better to route)
- you have just one single physical interface (On SW1) for interconnecting the remote Network (this for some STP features intended to protect a STP Topology when you interconnect two networks)
Why not to follow an approach that will treat your two networks (the one represented by the DT Switches pair and the other represented by the external workstations you want to be connected) as two separate entities leaving them isolated as much as possible (STP) but routed each others (Transit VLAN + Static Routing)?
Eventually you can then create proper ACLs (on both sides or just on one side) if reciprocal routing between both networks looks too insecure for you (remember that such approach will requires to create specific static routes to let each end to understand how to reach the far one...and that is already a form of "obfuscation"...clearly ACLs will enforce another level of security).
Something like:
- VLAN ids will left behind the DT Switches pair and their routing will continue to be done on that core
- You will add a NEW VLAN id - let's say VLAN id 2255 - used as transit network (/29 should suffice, 6 IP addressable hosts: 192.168.255.0/29) using a two IP Address(es) on DT Switches pair - let's say 192.168.255.1 on SVI VLAN 2255 on SW1, 192.168.255.2 on SVI VLAN 2255 on SW2 and 192.168.255.1 again as the the Virtual-IP (VRRP) for the new VRID 2255
- Someone will add a corresponding NEW VLAN id as above (VLAN id 2255 in my example) used as transit network assigning one of remaining three free IP Addresses, let's say the 192.168.255.4, on its SVI.
- tag (or untag) the ports involved on the interconnection between your Network and the remote one to be member of that VLAN 2255.
- Add static routes (one for each remote network to be reached by the local peers) on DT Switch pair to say that remote subnets 192.168.21/24 to 192.168.42/24, 192.168.52/24, 192.168.55/24 and 192.168.66/24 can be reached through the 192.168.255.4.
- Add static routes (one for each local network to be reached by the remote peers) remote Switch to say that your local subnets 192.168.14/24, 192.168.15/24, 192.168.16/24 can be reached through the 192.168.255.1 (which corresponds to your Virtual IP).
- Protect interfaces involved from exchanging STP...since both networks should be kept in separated STP domains and each core should be STP Root of its network topology.
- In absence of proper ACLs any host on DT Switch pair being member of a routed subnet should be able to connect to any other host of routed remote networks and vice-versa.
If too complex (but it's not)...use a Firewall to protect both networks each others.
I'm not an HPE Employee