Wired Intelligent Edge

last person joined: 8 hours ago 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

1930: more than one VLAN IDs for one Interface at same Switch

This thread has been viewed 73 times
  • 1.  1930: more than one VLAN IDs for one Interface at same Switch

    Posted 18 days ago

    Hello Guys,

    I switched from Netgear to Aruba equipment and had now a configuration issue with my new Aruba 1930 24 Port Switch.

    I need 2 Interfaces (e.g. Interface 23 and 24 in VLAN9) for my KNX Routers that must be isolated from the rest of the Interfaces from the switch.  (VLAN1)

    But I want to control the KNX Network and have access to the whole Interfaces with my "Homeassistant" (Interface 22) so this Interface must be able to access both VLANs (VLAN1 and VLAN9) at the same time.

    At the Aruba-Community I found a hint to "download, change and upload"  the Switch-Configuration (1930 - Allow all VLANs on a port?)

    But it seems not work because only one VLAN in the Configuration File is imported. I use Software Version 1.0.5.0_139.

    e.g. this not work:

    interface 22

     description "Homeassistant"

     switchport general allowed vlan add 1 untagged

     switchport general allowed vlan add 9 untagged

     switchport general pvid 1


    Can somebody help me to configure my new switch?

    Thank you



    ------------------------------
    Rudolf Manzenreiter
    ------------------------------


  • 2.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 18 days ago
    Hi Rudolf, not an expert about Aruba Instant On 1930 (there is a dedicated portal about Aruba Instant On devices here and the dedicated Community Forum is here) but - generally speaking - a physical/logical port can't be concurrently member of TWO untagged VLAN IDs (in other words you can't set a port as "untagged" member of two VLAN IDs as you did above for VLAN 1 and VLAN 9).

    A port can be an untagged member of a particular VLAN ID (called the PVID Port VLAN ID = the Native VLAN ID) and - concurrently - it can also be a tagged member of various other VLAN IDs or it can be only a tagged member of one or more VLAN IDs being (at the same time) left "orphaned" of the untagged VLAN.

    In any case a port carrying multiple VLAN IDs (untagged + one/various tagged or just various tagged) is often recognized as operating in "trunk" mode other than "access" mode (trunk in the Cisco jargon, not in the HP jargon of trunk = links aggregation).

    ------------------------------
    Davide Poletto
    ------------------------------



  • 3.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 13 days ago

    Hello Davide,

    Thank you for explanation about the different VLAN conventions, but unfortunately I didn't found a solution for me with a TRUNK to access both VLANs at one Interface with my 1930-Switch.

    I tried several TRUNK configurations, but I can't create a TRUNK with 2 "untagged" VLAN-members that can be taken for one interface for my homeassistant. (Homeserver)

    Following didn't work:

    interface 22

     description homeassistant

     channel-group 1 mode on

     switchport general allowed vlan add 9 untagged

     switchport general pvid 9

     …

    interface TRK1

     description "HA"

     switchport general pvid 1

     

    Do you perhaps know somebody who can help me with the configuration-lines for interface 22 and the TRUNK1.

     
    Thank you



    ------------------------------
    Rudolf Manzenreiter
    ------------------------------



  • 4.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 13 days ago
    Hello Rudolf, you wrote:

    "I tried several TRUNK configurations, but I can't create a TRUNK with 2 "untagged" VLAN-members that can be taken for one interface for my homeassistant"

    That's is expected: an interface CAN'T (concurrently) be untagged member of two different VLAN IDs, or it is untagged member of VLAN ID X or it is untagged member of VLAN ID Y, not both. In my previous reply I wrote exactly that.

    And if you think about it is easy to understand why it can't: being "untagged on a VLAN ID" means that a particular port ACCEPTS incoming packets carrying no VLAN tag and that that particular port will strip (remove) the internal VLAN ID tagging (which is always present INSIDE the Switch to correctly manage the packets' flow) before outputting the packets from that particular port OUTSIDE the Switch when those packets come from that VLAN ID (the Native VLAN ID = Port VLAN ID = PVID).

    In other words, OUTSIDE of the Switch ingressing/egressing packtes coming from the Untagged VLAN ID of the port (if any) are travelling WITHOUT a VLAN ID tag, they are indeed called "untagged" (but, remember, internally the Switch those packets travel tagged on that VLAN ID): given that you can easily understand that a port can't be untagged member of two VLAN IDs (that's the golden rule).

    With that regard a port can instead be a tagged member of various VLAN IDs because packets are accepted (incoming from external the Switch) and sent (outgoing from the Switch) always with a VLAN Tag and that tag is exactly the one that the Switch will continue to use internally to differentiate all possibile various traffic flows (part of internal VLAN 1 (default untagged), 2, 3, ..., n, ..., 4092, 4093, 4094).

    So, in spite of that, a port can be:

    1. only untagged member of a VLAN ID (not necessarily VLAN 1 Default)
    2. only tagged member of a VLAN ID (also VLAN 1 can be used)
    3. only tagged member of various VLAN IDs
    4. an untagged member of a VLAN ID + tagged member of just another different VLAN ID
    5. an untagged member of a VLAN ID + tagged member of various other different VLAN IDs

    A port CAN'T be an untagged member of more than one VLAN ID.

    Given all the above you have basically ports that are operating as Access Ports (generally matching case 1 or 2) and ports that operating as Trunk Ports (carrying more VLAN IDs, generally matching case 3, 4 or 5).

    How the Aruba Instant On 1930 deals with the above is probably described on its configuration guide (or on the GUI).

    ------------------------------
    Davide Poletto
    ------------------------------



  • 5.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 13 days ago
      |   view attached

    Hello Davide,

    thank you for your detailed explanation why it is not possible to access more than one untagged VLANs at one interface. Yes, all this stood in the documentation I read about ARUBA.

    But I am also a technician and the words "not possible" are not the right answer for me.

    For a simple VLAN-configuration it must be possible to solve it!

     

    Now my temporary solution is that my 12 year old sun borrows me his Christmas-Gift Smart managed 8-Port Switch (about 30 Euro) from an other brand and he configured the Port-VLAN with a lot of untagged VLAN-Members on a single interface as I requested and didn't need more than 2 minutes for it. (See picture)  This cheap switch doesn't think about what is to do with different VLAN IDs with untagged packages, it delivers to all Interfaces that are member of the VLAN, a little overhead but all are satisfied.

     

    The 1930 Switch is also for "small business", I think the VLAN-scale should also be a little bit flexible than an Enterprise-Switch that each package can only delivered to a "known" VLAN.

     

    My question is, what can I tell my son when – in comparison my expensive -  new 1930 ARUBA-Switch will work so that I can return him his switch?


    Thank you



    ------------------------------
    Rudolf Manzenreiter
    ------------------------------



  • 6.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 12 days ago
    I have not seen such a configuration before, and it looks really messy to me. Are you using the same IP address space in both VLANs? I'm not really aware of other devices supporting this, never seen it at least and it goes against most of the networking knowledge available.

    As an alternative, to make this more standard, I would add the second VLAN as tagged to your Home Assistant device (probably running Linux), your gateway can remain untagged and you have a real point-to-point between those devices. If it is about blocking traffic between devices in the same VLAN/IP Subnet, you could consider port ACLs, which I don't know for sure if the 1930 supports that, but the InstantON community may provide you with an answer.

    To answer your question, I'm pretty sure the 1930 will not support multiple untagged VLANs on a single port. It does support tagged VLANs, and by moving your configuration to that, you will not run into the same issue in the future.

    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------



  • 7.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 5 days ago
    Hello,

    As I read the Netgear configuration, all ports are native/untagged/PVID in VLAN 1, and the "membership" is like "allowed" on AOS-CX, tagged, on AOS, or "permitted" in Cisco IOS.  

    So port 1 would be untagged VLAN 1, tagged VLAN 1,2.

    Tagging is part of IEEE 802.1Q (https://en.wikipedia.org/wiki/IEEE_802.1Q) and is not optional if you want your switch to be compliant with IEEE.

    "Hybrid" ports (described in a subsequent post) use 802.1p QOS tags to allow you to have untagged data and voice traffic, with the switch using the QOS to categorize and place in a VLAN, as one of my old 3Com associates explained to me.  It is VERY non-standard, and 3Com used it to facilitate their VCX Voice over IP solution.  Most other voice solutions (Cisco, ShoreTel ,etc.) support tagging in their phone endpoints, to enable the use of a data port on the phone for a workstation, whilst placing traffic in separate VLANs.

    Kind Regards,

    ------------------------------
    Timothy Leadbetter
    ACMP, ACSP, ACCA
    CWNA, CWDP
    ECSE-Design
    Not a current HPE/Aruba Employee
    ------------------------------



  • 8.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 12 days ago
    Hello Rudolf,

    "But I am also a technician and the words "not possible" are not the right answer for me."

    Dear friend, sometimes reality must be accepted as is (especially if, considering this particular case, the device's capabilities are strictly dependent on things - like internal device engineering - you can't freely manipulate to accomodate your custom requirements -> if it's not supported it just works as designed).

    I initially omitted that there is probably - in the broad HPE word - a very seldom supported "non-standard" feature (and - even more - if supported it was/is really seldom used) that will permit a switch to set a port as member of multiple untagged VLAN IDs. This mode of operation is also known as "Hybrid", so along with classical "Access" and "Trunk" modes there is this third mode called "Hybrid": pay attention...not all HP/HPE/HPE Aruba Switch series (and there are many of them, current and legacy) support this VLAN mode of operation, rather...switch supporting "Hybrid" can be counted on the fingers of retired carpenter.

    AFAIK I don't believe the Aruba Instant On 1930 supports it (Probably Netgear supports it without using the term "Hybrid") and this is the first reason I initially omitted this bit of information, the second reason is that I still don't understand why you're forced to go with the "multiple untagged VLANs on a port" approach - and Hybrid ports can be set as untagged in one or more VLANs so that would maybe solve your issue - if, in 99.9% of the cases, you can easily live well without that...going Hybrid is somewhat "stupid" -> "Access" and "Trunk" modes of operation cover 99.5% of the common scenarios and are "standard" modes of operation, good for interoperability.

    Read about it here.

    I believe the "Hybrid" mode of operation is supported on just some Comware OS based HP/HPE Switch series (as example, such as the HPE OfficeConnect 1920 IIRC), for sure it is supported neither by the legacy/current ArubaOS-Switch OS based switch series nor by the current ArubaOS-CX OS based switch series...don't expect anything better on Aruba Instant On 1930.

    Technically speaking I don't believe the lack of this feature will devalue the richness (joke) of the 1930...

    ------------------------------
    Davide Poletto
    ------------------------------



  • 9.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 12 days ago
    Hi Rudolf
    FYI, on the Netgear, it is also using dot1Q, so while not explicitly indicating Tagged or Untagged, at least one of the VLAN's associated with Port 1 and with Port 8 is Tagged. It is impossible to have 2 untagged VLANs on the same port.

    ------------------------------
    George Ferns
    Solution Architect
    Ingram Micro
    Auckland NZ
    ------------------------------



  • 10.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 11 days ago
    I think that, to some extent, we stressed the concept up to the limit...if the Aruba Instant On 1930 doesn't support ports operating in "Hybrid mode" (AKA a port that can be an untagged member of more VLANs) and if the OP can't/don't want to re-think its requirements (as example, by following suggestions provided) the only way to overcome this issue is to change the Switch currently used in favor of one supporting the "Hybrid mode" of operation. Isn't it?

    Edit: regarding the Netgear screenshot - at least from the GUI portion shown - and now that I read it carefully...it's not clear to me how the VLAN membership of a particular port can be assessed without having some doubts (example: port 1 seems to concurrently be a member of VLAN 1 and VLAN 2...but how to understand its membership from the tagged/untagged standpoint? it could be tagged on VLAN 1 and untagged on VLAN 2 or vice-versa...or being tagged on both VLANs without being untagged member of any VLAN). Am I missing anything?

    ------------------------------
    Davide Poletto
    ------------------------------



  • 11.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 10 days ago
      |   view attached

    Hello Davide,

    Sorry for writing so late but I want to describe the Switch-Config from my son: the screenshot is complete, nothing else is visible, you can see the Management VLAN1 is mapped to Interface 1-5 that is neglectable at this stage.

    The VLAN2 used Interface 1 as Uplink and at Interface8 the Raspberry is connected with running Software Homeassistant. The "tagged" or "untagged" option is not visible, but I think it must be "untagged" because Homeassistant can't deal direct with "tagged" Packages.

    The interesting thing is that the configuration of VLAN3 with 6-8, the Interface8 is accessible from VLAN2 and VLAN3.  The configuration works and looks safe, there is no traffic between Interface1 and 6-7 (KNX-Routers)

    The Switch-documentation describes "Assign Ports to Multiple Port-Based VLANs" at page 30 and 31:

    https://www.downloads.netgear.com/files/GDC/GS105EV2/WebManagedSwitches_UM_EN.pdf

    I can look about the configuration also for dot1Q in advanced mode as at page 32 and following described, but my goal is to use ARUBA not the switch of my son.

    I also want to post my configuration of my previous Hardware-"died" 24 Port-Switch (see attachement) to document, that with this Smart Managed Switch GS324TP S350 it was also possible to Link one "Port" (all untagged!) to more than one VLANs with positive result!

    The magic words here are: vlan participation include X to participate "more" VLANs  to the specific "Port" as the default VLAN. You can see nothing has a "tagged"-configuration.  Sorry, but this "untagged Interface" regulation for only one VLAN doesn't exist for other brands.



    ------------------------------
    Rudolf Manzenreiter
    ------------------------------



  • 12.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 10 days ago
    Hi Rudolf, this is running hot:

    "Sorry, but this "untagged Interface" regulation for only one VLAN doesn't exist for other brands."

    Please do us a favor and qualify those "other brands".

    If I look at Cisco (well, you know what Cisco represents for networking) I find that the untagged rule [*] as you've called it (a logical/physical interface can be untagged member of only one VLAN) seems instead to exist exactly as it exists on Switches made by HP, HPE, H3C, Huawei, 3Com, HPE Aruba, etc.

    As I wrote you above, only some network operating systems (HPE Comware is an example -> Aruba Instant On 1930 is NOT based on that) let - through the seldom seen "Hybrid mode of operation of a port" feature - an interface to be an untagged member of more than one VLAN Id.

    I'm not an expert about Netgear but I found that various Netgear manageable switch series behave differently (not consistently I would say) with regard to VLAN tagging configurations (maybe via GUI, CLI necessarily needs to be more consistent)...by the way...exactly in the guide you linked, at page 37, there is this sentence under the "Specify a Port PVID for an 802.1Q-Based VLAN" paragraph: "You can assign only one PVID to a port." since PVID is also the untagged VLAN Id a (Access/Trunk) port can member of...that very sentence could be read as "You can assign only one Untagged VLAN Id to a port.". So the rule you claim to not exist, it does exist. Am I wrong?

    [*] Note that Cisco based jargon (adopted also on HPE Comware and Aruba ArubaOS-CX operating systems based switch series) differentiate between Access and Trunk instead of focusing on untagged and tagged (or a mix of them). Aruba ArubaOS-Switch operating system based switch series call Access as untagged and Trunk as tagged with all the patterns I listed above...add to that, also, a port can eventually be an Access port by having the only one VLAN tagged instead of untagged, clearly that is useful only if the Client is VLAN-aware/-capable.

    ------------------------------
    Davide Poletto
    ------------------------------



  • 13.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 6 days ago

    Hi Davide,

    Sorry it was not my intention to "downgrade"  any brand.  I want to solve my security trouble.

    My first goal is to use less equipment because this costs a lot of energy during the year and the durability I have learned is also not the best. My network-equipment is now a Fritzbox, Raspberry, 2 KNX-Routers and an ARUBA-1930 Switch.

    What possibilities do I have to secure the KNX-Routers in my intranet? (Without KNXsecure, that's not supported by the Routers and homeassistant)

    Maybe a new way might be an other Subnet for the KNX-Routers, Enabling option "routing" (of the ARUBA-Switch) and option "Port-Security". Is this sufficient enough? Is this save about e.g. SmartTVs, PCs, Tablets etc. that are searching around the Intranet for all "things" but we don't know what they are doing with this information. And e.g. what are about Multicast-traffic, …?

    Eventually you have a better concept without VLANs, then we open a new Topic?

    Thank you



    ------------------------------
    Rudolf Manzenreiter
    ------------------------------



  • 14.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 6 days ago
    Hi Rudolf,

    I went back to the very beginning and re-read your first post: apart of the whole discussion born around the concept of untagged/tagged port (I believe it's now solved)...if your primary intent was/is to segment (thus using VLANs) and segregate (thus applying ACLs to VLANs) local IP segments subjected to IP routing to create secure internal networks (that's because - from what I've understood - you're requiring some sort of inter-VLAN routing to access, example, your KNX IP Routers - de-facto they are "gateways" between the IP and the KNX bus worlds - from a management Host representing your KNX Home Assistant, probably deployed on a Raspberry Pi, while protecting them from undesired access attempts)...then...if my above assumptions are correct...a reasonable and simple network topology would be the one that just have three physical main actors so your energy bill (and thermal footprint) will be as small as possible (a Firewall as gateway to external world, a suitable Switch capable of basic L3 features to create your internal logical networks, various hosts as per your current requirements: KNX routers are hosts, KNX home assistant is an host, etc.) and they would need these mutual relationships:

    1. A Gateway to external networks (AKA to Internet, to whatever is not locally directly connected to your "internal" L3 Switch) - that's the duty of your FritzBox Firewall - acting as bastion protecting your network border from/to the external world. The FritzBox just need - with static routes - how to reach your internal segments (and, clearly, it needs to address permissions to those segments to let them reach the outside word, if necessary).
    2. A IPv4 Router (it could easily be a Switch if it supports IPv4 Routing and ACLs)
    3. Segment VLANs (quantity as required) deployed on your Switch, each VLAN will have its IP Interface (thus being being target of IP routing)
    4. A Transit VLAN between your Switch and your Gateway (FritzBox) specifically used to route traffic from/to external networks and your Layer 3 Switch (your hosts will speak to your Switch and your Switch will route to external targets via the Transit VLAN to the Firewall and vice-versa, a way to not exposing your internal non-Transit segments directly to the Firewall).
    5. ACLs (quantity as needed) to protect/isolate your most vulnerable segments (example those where your KNX IP Routers are going to be placed) and to permit some sort of internal communication between the KNX Home Assistant (Raspberry Pi) and KNX IP Routers while blocking other unnecessary/unwanted traffic (ACLs can be clearly complex to configure but you can start with basic matrix and then grow in complexity).
    6. Access ports (untagged on VLANs you want/need) where to place KNX IP Routers, Hosts, etc.
    7. Trunk port (tagged on Transit VLAN) only used between your Aruba Instant On 1930 Switch and the FritzBox Firewall (the LAN interface of your Firewall will need to be tagged with this Transit VLAN id).
    8. Transit VLAN should use a tiny segment (/30 or /31 if possible) because it's just used to setup a point-to-point connection between L3 Switch and the Next Hop Gateway to reach the external networks.

    Is is a reasonable approach? Mind you that any L3/ACL capable switch could be part of such scenario.

    Personally I don't see any issue in planning a similar approach (without any doubt, it's not the only one...it's just one possible approach).

    Probably it would be a better choice for you to start discussing what approach fits better in another dedicated thread.

    ------------------------------
    Davide Poletto
    ------------------------------



  • 15.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 5 days ago
    Hello,

    As background, I've built some very large networks, and currently work in Network Engineering for very large networks.  I've written and presented webinars in a past (long-term) role to help system administrators understand basics of networking.

    Davide is presenting a clear explanation of the options.  I'd like to elaborate a little.

    One challenge is determining the layer at which each entity operates, particularly when learning networking or having worked with smaller networks.  Home networks are usually, by definition, smaller networks.  Mine has seven subnets and a like number of VLANs, but it serves as a lab platform.

    VLANs operate at layer 2, as has been discussed.  A port can be configured to accept traffic with VLAN tags, or traffic with no tag.  If, for example, a port is configured on a switch to accept untagged traffic (untagged/native/PVID) in VLAN 7, all traffic arriving without a dot1q tag will be placed in VLAN 7.  Less intuitively, all traffic arriving at that port with a dot1q tag for VLAN 7 will be discarded - it fails to meet the "untagged" criteria.

    Further, if that port is configured to allow traffic in VLANs 10, 11, 13, and 100 (for example), any frames with a dot1q tag for those VLANs will be accepted, and any with other tags will be discarded.  So far, so good.  VLANs are a layer 2 construct, allowing you to secure a port on your switch.

    IP addresses have a network portion and a host portion.  The network portion is used for routing with a routing protocol, or layer-3-switching on a switch with that capability.  Some switches have both the ability to perform layer 3 switching between VLANs configured with a L3 interface, and to run a routing protocol such as RIP or OSPF.  This is Layer 3, and though the VLAN is configured with an interface, it's best not to conflate L2 VLANs with L3 subnets (though we do it all the time - it's necessary to keep the concepts clear).

    Where you can get into trouble is when you do one of two things:

    -     Place multiple IP subnets on a single VLAN (common where only L2 switches are in use, such as the HPE/Aruba 2530 or 6100)
    -     Split a VLAN across multiple IP subnets

    Use of a single VLAN for multiple IP subnets creates two issues.  First, the number of frames that must be flooded out all ports to learn the CAM (Content Addressable Memory, or MAC address) table increases, impacting performance.  Second, if you're using a small, lower cost switch such as the HPE/Aruba 2930-8G, you will need a "router on a stick" to handle internal routing, as the VLAN interface is used for layer 3 switching between subnets in the absence of a router.

    The bigger problem is when multiple VLANs are used to carry a single subnet.  Thankfully this isn't common and is a little difficult to set up.  But what it can do is create a situation where traffic within a single subnet cannot see a target because the layer 2 configuration (VLANs), cause the traffic from one node to another to be blocked due to frame discarding.  This would happen if, for instance, my PC had a static address in 192.168.1.0/24 and connected to a port untagged in VLAN 10, and my printer had a static address in 192.168.1.0/24 but connected to a port untagged in VLAN 20.  The layer 2 traffic can't pass.

    Back to the original thread, and Davide's recommendations.

    In my home network (which is unreasonably large for a home), I have a pair of 2930F-8G layer 3 switches, an Aruba S3500, a 2540-8G-PoE+, a couple of Aruba 7005 controllers (which also perform switching and routing), a Cisco ASA 5505, and a VMware host with a number of guest utility servers.

    I perform internal (between trusted subnets) L3 switching by creating VLAN interfaces for these subnets.  Lets call them 10, 11, and 12, and give them IP addresses of 172.16.10.0/24, 172.16.11.0/24, and 10.1.0.0/16.  With IP routing enabled on my 2930 core switch, these subnets are L3 switched without needing a router, using the 2930's L3 switching engine.

    I have an untrusted VLAN for IoT devices - let's call it 107 since that looks a little like IOT.  It has no L3 interface defined on the core switch (or anywhere else in the inside/trusted network) and has to be routed at a different location.  This is a "router on a stick," which is, in my case, the ASA firewall.  I could also do this with a router, including the 7005 controller, and ACLs.  But I want to segregate using a firewall, so I can have more robust rules and tracking.

    Since this has gone on a bit, I'm going to summarize:

    VLANs are layer 2, and provide high-level traffic segmentation at the switch port level.

    IP subnets are layer 3, and provide the ability to move around a network using routing and imposing controls through ACLS; firewalls are based on ACLs, but are "stateful."

    Traffic into/out of switch ports must be in allowed VLANs - IP address is irrelevant here.

    To move between VLANs, you can use untagged ports, facing each other, in different VLANs (get ready for PVID mismatch log warnings), or can create a L3 (subnet) interface that is coincident with each VLAN.

    Each switch port can have a single "native" or untagged/PVID VLAN and, optionally, multiple tagged/allowed VLANS.  Note:  consumer switches often have a single VLAN, denominated VLAN 1.

    In the words of Albert Einstein, a thing should be made as simple as possible, but no simpler.  IP subnets allow you to isolate less trusted devices (such as smart TVs, other smart appliances, or - ironically - alarm systems and smart locks) from devices with financial or other personal information.  VLAN interfaces are a common way to implement these but, if the interfaces exist on a single switch such as the 2930 with IP routing enabled, you need to write ACLs to prevent cross-talk.

    A basic firewall is a good thing, and the FritzBox sounds like it will do the trick.

    I don't want to get into subinterfaces - it's late in the evening where I am, and it's an involved discussion.  Suffice it to say that, on my firewall, I have a physical interface fa0 which carries multiple subnets - 4 of them.  So my primary interface carries the main VLAN (native, since it's a Cisco firewall).  It also has fa0.1, fa0.2, and fa0.3, which carry the other three "tagged" VLANs.  This is common for routers or firewalls, as well as more powerful switches such as the Aruba 6300 and above.

    Your FritzBox may allow subinterfaces, or may require you to dedicate one physical interface to each subnet, with the interface having an IP address.

    I hope this adds more light than smoke, though it's late enough that I doubt that.  Best of success to you

    ------------------------------
    Timothy Leadbetter
    ACMP, ACSP, ACCA
    CWNA, CWDP
    ECSE-Design
    Not a current HPE/Aruba Employee
    ------------------------------



  • 16.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 5 days ago
    Thanks for sharing. While very uncommon to have multiple VLANs untagged on a port, I see that it works in the original poster scenario. If the switch follows the logic that packets are sent/flooded to all ports that have (at least) that have any of the VLANs linked to the source ports assigned, while having the same IP subnet, you can enforce that the IoT gateway can only communicate to the homeassistant, and the homeassitant can also communicate to the rest of the world. This will absolutely not scale, and it goes against all the best practices, but in this corner case it may work.

    In my home network, I also have multiple subnets (and corresponding VLANs), and use a stateful firewall to route between those subnets. I have separate subnets for IoT devices that only communicate locally (so traffic to internet is blocked), and other subnets for devices that are cloud-based and only can communicate to the internet (internal traffic is blocked), and where I want, I can make exceptions to that rule. This, for me, makes it much more flexible, and also troubleshooting is easier as you have the firewall to capture traffic and see what goes through and what is blocked.

    This may also be the reason that the feature is available on consumer products, and not on (small) business equipment.

    I don't know the 1930 good enough to tell if you can do IP-routing and port or VLAN access-lists, but with those features, you can get to the same results.

    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------



  • 17.  RE: 1930: more than one VLAN IDs for one Interface at same Switch

    Posted 5 days ago
    Well...I was curious enough to land on the Aruba Instant On web portal to look for any reference about IP Routing, VLANs and ACLs features in relationship with the Aruba Instant On 1930 Switch series and, at first sight, I was captured by this disappointing statement (reported also into the Datasheed): "...Ensuring high performance and eliminating traffic bottlenecks across the network, this smart-managed Layer 2+ Ethernet switch series is ready to deploy in 8-, 24-, and 48-ports for non-PoE and Class 4 PoE (i.e., PoE+) models." (here) which leads me to believe that this switch series is not the right choice if you need basic Layer 3 features...but then, drilling a little bit deeper, on the Aruba Instant On 1930 Switch Series Management and Configuration Guide (June 2020) I read something very contradicting, Layer 3 features are indeed supported despite the "Layer 2+" reference in the above statement and Datasheet (assuming that with the innocent wording "Layer 2+" Aruba means exactly "no-Layer 3" features and not a misleading "Layer 3 light" features support, L2+ can't be a L3- and vice-versa...L2+ is L2 plus something and L3 Light means L3 minus advanced L3 features not really necessary in the type of product you're selling) at the point that IP Routing, VLANs and ACLs support is granted. So far so good.

    ------------------------------
    Davide Poletto
    ------------------------------