Onboarding EXOS Switch - FA Assingment gets rejected

[Niko_P]

Hi all,

I’ve got some trouble with onboarding EXOS Switches to my network.

I got a VOSS/Fabric Engine as Core with auto-sense enabled on most ports.

The EXOS switch is factory default and connected to one of the auto-sense ports of the VOSS.

The VOSS Switch has a minimal config.

If I connect the EXOS to the VOSS, the switches try to do FA, Onboarding VLAN 4048 I-SID 15999999.

But the FA assignment gets rejected by the VOSS switch.

I get the following messages on VOSS:

5420M-48W-4YE-FabricEngine CP1 - 0x00374583 - 00000000 GlobalRouter FA INFO Fabric Attach Element Discovered on interface 1/32 Element type clientSwitch (8) Id d8:02:c0:37:d8:00:10:00:00:21

5420M-48W-4YE-FabricEngine CP1 - 0x00374592 - 00000000 GlobalRouter FA WARNING Fabric-Attach-ISID assignment 4048:15999999 was rejected on port 1/32 because the I-SID's associated VLAN is private and the private-vlan setting on the port is not set to isolated/promiscuous.

5420M-48W-4YE-FabricEngine CP1 - 0x0037458f - 00000000 GlobalRouter FA INFO Fabric Attach Assignment rejected: interface 1/32 i-sid 15999999 cvid 4048 rejected due to application error (status 9)

No log messages in the EXOS log, but show fabric attach assignment shows it’s rejected.

It is strange that the VOSS logs said that FA is rejected because of private VLAN settings, I can’t change these settings with auto-sense enabled. The private VLAN setting for vlan 4048 are also the default settings.

It get’s even stranger, if I leave it as it is (in rejected state) and wait for some hours or days, the FA assignment will eventually work on and the EXOS get’s an DHCP IP in the onboarding VLAN 4048. (without any changes)

My VOSS switch is an 5420 running 9.3.4.0
My EXOS switch is an 5320 running 33.5.2.118

But I also encountered this with other models and software.

Has anyone else observed this behaviour? 

Regards
Niko

[Brent_Addis]

I had this same issue last week. FA with that firmware doesn't do auth well (It's fixed with 33.7 fyi but I wasn't about to upgrade 120 switches myself)  so we did a bit of a workaround to onboard switches and allow upgrades to commence. It uses auto MLT FYI and assumes a vLACP between cores.

I am not sure if you are using site engine?

Here's my example config, on both switches. I have around 30 buildings across a campus and each has it's own management range so I'm putting a per mlt management i-sid. I onboard my switches into this range, which is a shortcut to put FA proxy devices such as AP's into this range. I then move my switches into another range using site engine xos onboard scripts but you can either leave or change yourself if no site engine (vlans / IP's changed before anyone mentions PII):

SLPP config:
slpp enable
slpp vid 108

mlt 102 enable
mlt 102 member 1/2
mlt 102 encapsulation dot1q

interface mlt 102
smlt
fa
fa enable
no fa message-authentication
fa management i-sid 10200108 c-vid 108
exit

I then have my ports configured as below, because auto-sense won't work here.

interface GigabitEthernet 1/2
default-vlan-id 0
no auto-negotiate
name "My-MLT-Name"
no shutdown
slpp packet-rx
slpp packet-rx-threshold 50 <- CORE-01 (500 on CORE-02)
nodealias enable
no spanning-tree mstp force-port-state enable
sflow sampling-rate 8192
sflow collector 1
exit

I'm using L3 vlans on my switches so YMMV here. Omit what is obvious you don't need. we also use VRRP instead of anycast (This is happening next year)

vlan create 108 name "MGMTVLAN" type port-mstprstp 0
vlan i-sid 108 10200108
slpp vid 108

interface Vlan 108
vrf your-vrf
ip address 10.30.108.250 255.255.255.0
ip dhcp-relay
ip vrrp version 3
ip vrrp address 108 10.30.108.1
ip vrrp 108 backup-master enable
ip vrrp 108 priority 110
ip vrrp 108 enable
exit

router vrf your-vrf
ip dhcp-relay fwd-path 10.30.108.250 10.30.8.90
ip dhcp-relay fwd-path 10.30.108.250 10.30.8.90 enable
ip dhcp-relay fwd-path 10.30.108.250 10.30.8.90 mode bootp_dhcp

CORE-02 (10.30.108.251, VRRP priority 120): the same block with .251 for the interface address and the three relay lines, and ip vrrp 108 priority 120.

Notes:

• Static SMLT: the MLT has a single member port and no LACP.
• Fabric Attach: it is enabled with message authentication off. The management I-SID is 10200108 with C-VID 108, already on the 1020 format.
• SLPP: receive is on, with CORE-01 at 50 and CORE-02 at 500, as intended.
• No STP: spanning tree is off on the port, so SLPP is the only loop detection here.
• No VLANs listed: none are configured on the MLT. The edge switch asks for them dynamically.

[Niko_P]

Hi Brent, 
thank you for sharing your insights and configuration! 

Yes, I'm using the SiteEngine.
I will test it with the later firmware (33.7) but I also don't want update 100 switches manually. 
(In that case I would change them to voss right away)

Maybe we can adapt your workaround. 

Regards
Niko

[henry45cavil]

Hello,

That’s definitely strange, especially since the FA assignment eventually works without any configuration changes. It sounds like there could be an issue with how the VOSS switch handles the private VLAN settings during the initial Fabric Attach onboarding process. I’d check whether this is related to a firmware compatibility issue or a delay in the FA policy being applied. Since you’ve seen the same behaviour across different models and software versions, comparing the FA configuration and logs on both switches during the initial rejection and eventual success might help narrow down the cause.

Best Regards

[Brent_Addis]

That XOS firmware is pretty average when it connects to an auto sense port and assumes there's some form of authentication with no back down. I had this same problem last week, how do you setup auth on switches before they're plugged in to onboard en masse? Good luck. My workaround is the other comment 😉