I’m playing around with the CRS106-1C-5S.
We some machines, we use VLAN on the same physical network interface as a untagged lan.
With the onboard configuration, even tagged VLAN traffic is transported. On our netgear switches we used before, tagged VLANs where blocked.
So I activated the VLAN filtering on the bridge. VLAN traffic is not transported anymore (fine), but when I configure a VLAN on the switch, it is also blocked.
My goal: block any tagged VLAN traffic except the configured one between SFP4 and SFP5 VLAN ID 1337), but allow any untagged traffic between SFP4, SFP5 and the combo port.
For your goal, you need to enable “Ingress Filtering” on every port you want (not just the bridge’s interface itself).
With that enabled, an ingressing frame is checked against its VID and if the port is member of this VID. If no tag is there, the PVID is checked against. If the port is not member of the VID, the frame is dropped.
Thanks for your answer. Then the netgear switch behaves not normal for 802.1Q?
Ok, to understand it right:
SFP4 and SFP5 are on the bridge, I enable the “ingres FIltering”, set the PVID to 1 and set FrameTypes: Admit all
Now, on SFP4 and SFP5 only a communication via VLAN1337 and without a VLAN tag should be possible, traffic with other VLAN-IDs should be blocked, correct?
A question: which switch model exactly are you using? There’s no such thing as CS108 … it might be CRS109 or RCS309 … and these two need to be configured in different way to get wirespeed switching … But in neither case it should be necessay to mix configuration in both /interface/bridge subtree and /interface/ethernet/switch subtree … even more, doing config in both places tends to lead to weird behaviour.
Just to make things straight: when an interface is not member of certain VLAN (in /interface/bridge/vlan), it doesn’t pass frames of that VLAN on egress. However, without ingress-filtering enabled it does accept frames of that VLAN on ingress and passes them to ports which are proper members of that VLAN. This enables frame injection - device connected to such port can inject frames into “alien” VLAN. Two-way communication is not possible (due to egress filtering). There are only edge cases when enabling ingress-fltering is not a good idea, one use case might be connecting a device broadcasting/multicasting UDP stream into certain VLAN … so swithc port has to accept frames for “alien” VLAN. Blocking traffic for same VLAN on egress might add to security of such device (no other device in same VLAN can connect to broadcast device). But there are other, more straight-forward than playing with asymmetric VLANs, ways of securing any device.
Setting ingress-filtering means that bridge will drop frames from non-allowed VLANs on ingress, meaning that this property is a security property.
Properly setting property frame-types (instead of “any”) is security feature as well, it helps to drop untagged frames on port which otherwise isn’t meant to accept them.
Just to make things straight: when an interface is not member of certain VLAN (in /interface/bridge/vlan), it doesn’t pass frames of that VLAN on egress. However, without ingress-filtering enabled it does accept frames of that VLAN on ingress and passes them to ports which are proper members of that VLAN. This enables frame injection - device connected to such port can inject frames into “alien” VLAN. Two-way communication is not possible (due to egress filtering). There are only edge cases when enabling ingress-fltering is not a good idea, one use case might be connecting a device broadcasting/multicasting UDP stream into certain VLAN … so swithc port has to accept frames for “alien” VLAN. Blocking traffic for same VLAN on egress might add to security of such device (no other device in same VLAN can connect to broadcast device). But there are other, more straight-forward than playing with asymmetric VLANs, ways of securing any device.
Setting ingress-filtering means that bridge will drop frames from non-allowed VLANs on ingress, meaning that this property is a security property.
Properly setting property frame-types (instead of “any”) is security feature as well, it helps to drop untagged frames on port which otherwise isn’t meant to accept them.
[/quote]
What I wan’t to achive:
on combo: the “normal” LAN
on SFP4: normal LAN (untagged traffic) and VLAN1337 tagged in and, out all other tagged traffic blocked.
on SFP5: normal LAN (untagged traffic) and VLAN1337 tagged in and out, all other tagged traffic blocked.
But I always get other VLANs transported too, Or I get locked out
Regards
Daniel
Done with the hardware switch chip (/interface ethernet switch)
The CRS1xx/2xx VLAN handling is very different to all the other models as the UI exposes much of the inner switch workings.
The bridge should be set to vlan-filtering=no, any ingress-filtering=, _frame-types=_and pvid= settings on the bridge and bridge ports should be left at they default values. The configuration should then be carried out under /interface ethernet switch.
Your original settings were correct, however the default is to permit unknown vlans either
/interface ethernet switch
set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=sfp4,sfp5
or
/interface ethernet switch
set forward-unknown-vlan=no
and to allow management traffic you also require
/interface ethernet switch vlan
add vlan-id=0 ports=switch1-cpu,combo1,sfp4,sfp5
It’s the window through which ROS (running on CPU) can communicate with (V)LANs handled by switch chip. On ROS side, that’s bridge interface in your current config.
On a typical switch you need to allow management VLAN on switch1-cpu port (or untagged if your management goes via untagged), on router all of VLANs should be let to pass this port.
