04-09-2019 11:22 PM
Solved! Go to Solution.
04-10-2019 07:23 AM
06-26-2020 07:32 PM
Lets say your ERS receives MAC X on the port to your generic switch, and you need that MAC to be scooped into VLAN 10.
When you authorize the MAC via RADIUS, you return these RADIUS attributes:
FA-VLAN-Create=1 # If the VLAN needs creating on the ERS
FA-VLAN-ISID=10:<I-SID>
The above is sufficient to place ingress traffic from that MAC into VLAN 10 (I-SID whatever)
The question now is how do you want to send egress traffic to that same MAC on the same port ? Tagged or Untagged ?
If you want it to go out untagged, you will include this RADIUS attribute as well:
Egress-VLANID=0x3200000a
Whereas if you want it to go out tagged:
Egress-VLANID=0x3100000a
But in this case the egress VLAN id better match the VLAN id you authorized the same MAC into; I don’t think it will work if you try and do VLAN translation..
The above attribute is defined in RFC4675; the vlan-id is the last 12 bits (hex A = 10 decimal).
Again, the above attribute is only applicable to MHMA mode (not MHSA).
06-10-2020 07:00 PM
Hello Ludovico, I hope you are well!
Can you clarify - does this mean that this can be used to attach any vendor’s downstream switch with multiple vlans for various services (printer, phone, pc, etc) ? My thought is to act on the mac address of the switch to send the vlans:ISID to the ERS, which I have working, but am not understanding how to tag the ERS port. Reading your response says to me that a printer mac in the printer vlan on the downstream switch will be put into the printer vlan on the ERS even in absence of the ERS port being tagged.
Topology
VSP --- ERS --- generic switch -- end point devices
“ In this mode you don't care how the packet arrives on the port (tagged/untagged) (and the PVID config of the ERS port is completely irrelevant) since the authenticated source MAC automatically determines the VLAN (which was assigned to that MAC); under the bonnet it is MAC-based-VLANs. “
PS120-4950-WC1-Stk3(config)#show vlan interface verbose 1/47
Filter Filter
Unit/ Untag. Unreg.
Port Frames Frames PVID VLAN VLAN Name PRI Tagging Port Name
----- ------ ------ ---- ---- ---------------- --- ------------- --------------
1/47 No Yes 92 32 WiredUsers 0 UntagAll Unit 1,Port 47
92 SwitchMgmt
96 NewVoIP
112 Printers
1001 OldVoIP
Thanks!
10-23-2019 08:54 AM
The MHSA mode is only intended for opening ports where a wireless AP is connected, and hence, yes, it is required to open the port for all MACs associated to the AP thereafter (or as in this thread it was desired to open an ERS NAC port behind which a 2nd ERS switch is connected).
But MHSA is not the mode to use on ports where you have end-stations, or else it defeats the purpose of NAC.
For end-stations directly connected to ERS ports (PCs, phones, etc..) you don't enable MHSA on the port, and so the ERS port will work in MHMA Multi-VLAN mode.
In this mode you don't care how the packet arrives on the port (tagged/untagged) (and the PVID config of the ERS port is completely irrelevant) since the authenticated source MAC automatically determines the VLAN (which was assigned to that MAC); under the bonnet it is MAC-based-VLANs.
You might still care about untagging frames for a certain VLAN when sending packets out of the ERS port, in this case you need to also send the RFC4675 attribute in addition to the FA-VLAN-ISID (the FA-VLAN-PVID attribute will be ignored in this mode)
As for the FA-Client-Trust RADIUS attribute, this is again mostly intended for ERS ports where we connect an FA Client device which has a need to do FA signalling to request additional VLAN:ISID bindings beyond the initial VLAN it got put on by NAC/RADIUS. These devices are Extreme Wireless APs or the Defender for IOT (which get their final config from a controller), or possibly some other device running Open vSwitch (OVS). All of these devices would require the MHSA mode (not MHMA!) as they will bridge additional MACs into the same ERS port.
10-22-2019 06:20 AM
Coming back to Ludo’s statement:
For ERS enable globally:
eapol multihost auto-non-eap-mhsa-enable
And at port level:
eapol multihost auto-non-eap-mhsa-enable mhsa-no-limit
These commands will open the port to the ERS4900 behind, that means also unwanted devices will get access to the network, once one authenticated client on that port is authenticated successfully.
I guess that is not what a network administrator want and that cannot be the solution to get this automatic VLAN:I-SID assignment running?
Is there any other way to get this running?
Thanks - Matthias