XMC 8.5.6.17 and Aruba 2920

[Giuseppe_Montan]

Good Morning, is possible use XMC as NAC to control Aruba switches ?

Thanks
Giuseppe

[Ryan_Yacobucci]

Hello,

Regarding Error.docx: You appear to be trying to enable authentication or control the device through the "Policy" screen. This will not work as the Aruba switch is a 3rd party device. The referenced errors are because the SNMP OIDs and API call do not exist on the Aruba switch. 

If anything I would consider it a bug that you can add the device into a policy domain at all. I would have guessed XMC would not allow it based on it being an unsupported switch.

The issue where "NAC is not reachable" but is reachable with ping: Is this an error message that is thrown for a specific service, like RADIUS, on the Aruba?

If ping is reachable, what is the Aruba switch trying to do that causes the error the NAC is not reachable error? RADIUS? SNMP?

Because this is a 3rd party platform a lot of the automation that is available in XMC will not be available for use. 

This is what you can expect to be able to do: 

DEVICES:

• Monitor the device/Perform basic historical statistic collection as long as the switch supports MIB2. 
• Backup/Archive the device, but I do not know if we have a native script built to backup the switch. There is one for HP, but you'd have to view it to see if it would work on the Aruba.

POLICY:

• Control --> Policy: Nothing in this tab should work. You shouldn't even be able to assign the device a policy domain to attempt to manage the device at all.

ACCESS CONTROL:

•  You should add the switch into the "Switches" tab to make it an authorized RADIUS client, but NAC will not be able to dynamically configure RADIUS. Set the "Auth. Access Type" to "Manual" when you add a switch.  
• A predefined RADIUS attributes scheme for Aruba doesn't exist. If using RFC 3580 there is a canned configuration. You may need to build a custom attributes scheme based on what the Aruba switch needs for attributes. 
• If using RFC 3576/5176 a sysObjectId mapping or override needs to be set per switch to identify how reauthentication should occur.

Thanks
-Ryan

[Giuseppe_Montan]

Thanks for the reply. at the moment I was able to authenticate a cctv and an access point via macaddress via RFC3580. What if I need to pass a tagged vlan to the switch? Is it possible in your opinion?
It would be useful if you want to connect a phone.

Thanks
Giuseppe

[Ryan_Yacobucci]

Hello,

RFC 3580 is for use with untagged egress. There is no way to indicate a tagged egress using RFC 3580 from my experience. 

You'll need to see if the switch can support RFC 4675

https://datatracker.ietf.org/doc/html/rfc4675

Most Extreme gear has a "policy" concept where we can use filter-id to invoke a policy that is configured to tag/untag accordingly, we do have VSP or ERS that supports RFC 3675. 

Thanks
-Ryan

[Giuseppe_Montan]

Hello

Hello,
The tests continue.
I created a rule on NAC under Switch --> Radius Attributes to send
Tunnel-Private-Group-Id=%VLAN_ID% --> Vlan Id 2
Tunnel-Type=13
Tunnel-Medium-Type=6
Egress-VLANID=%CUSTOM1% --> Aruba wants hex format ( 0x310002 )

The radius sends it as per attached file but the switch responds with this error :
 error. MAC 001AE8548248 port 1 VLAN-Id 0 or unknown.

Giuseppe

[Piotr_Szolkowsk]

Hi,

As it was mentioned before RFC 3580 does not support assignments of tagged VLANs to authenticated client/device. In case of Aruba switch you can use RFC 4675. The attribute Egress-VLANID needs a proper value: 

• first 8 bits specify "tagging": 0x31 for tagged VLAN or 0x32 for untagged VLAN
• 12 bits are always 0x000
• 12 bits defined your VLAN

all values above are in HEX

e.g. to get VLAN 17 tagged you need - 0x31000011 (means 0x31 - tagged, 0x000 padding, 0x11 - VLAN 17 converted from decimal to HEX)

Now the trick is that you have to send it to switch as decimal value so 0x31000011 have to be converted back to decimal which is 822083601 😉

so your attribute should look like: Egress-VLANID=822083601

Good luck 

Piotr