Fabric Attach pros/cons

[Anonymous]

Hi all,

I'm halfway through my first Fabric Connect deployment, and looking for in the field experience with Fabric Attach.
At this network's core are two server rooms, with a VSP 7400 and a 5520-24t running VOSS in each one, then we have X450G2 stacks for distribution, along with a few old B5 stacks.
Software versions are VOSS 8.4.2.0 and EXOS 30.7.2.1.

So, Fabric Attach.
Automatically pulling VLANs from the edge switches sounded great initially.

That is, until I realized that:
- FA is dog slow, VLANs get mapped about 1 min after you link comes up, with default LLDP timings
- FA requires full trust in your edge switches, as any I-SID/VLAN in your core is "attachable", and apparently can't be protected from it
- FA cannot handle multiple paths, but relies on LACP for redundancy, so I still need to set this up on both core and edge
- and I still have to deal with port-based VLANs on VOSS anyway, for B5 stacks, servers, routers, etc

Lowering the LLDP transmit interval from 30s to 10s only made FA barely usable, mapping VLANs still takes from 15s to 20s.
I consider using a smaller LLDP interval to be unreasonable, as it's a global value for all ports in the EXOS stack, I and don't want this to affect other devices in any way.
Didn't find any KB article dealing with this issue.
I guess the problem is LLDP advertisements are sent in sync globally to all ports, and we end-up waiting for the next scheduled dispatch, and that's what makes it so painfully slow, but really FA on the edge should trigger a "gratuitous" LLDP advertisement when the link comes up and be done with it.
So long for the Fabric Connect super fast convergence time...

Then, the lack of any core-side control over which VLAN/I-SID can be mapped really annoys me.
We do use FA authentication (no one should use unauth'ed FA in its current state IMO), but that's not enough.
I don't want the edge switches to be able to extend the server or infrastructure VLANs, it just doesn't feel safe.
I can see the value in only provisioning edge VLANs in only one place, but I want to be able to selectively enable VLANs/I-SIDs for FA on the core/server side.

And ultimately, I don't feel that I'm really gaining that much from FA in return.
I still have to configure core to edge ports for MLT/LACP (maybe even switch to trunk mode manually, I don't remember).
I still need to map I-SIDs to actual VLANs on the 7400s in order to provide IP subnets gateways, routing and so on (so I end-up with a double I-SID to VLAN mapping).

Did I miss something here?
Does FA bring any other benefit?
Is there a well hidden trick to make VLAN mappings happen faster?
Is there a way to whitelist I-SIDs for FA? (and prevent any other I-SID from being ever mapped)
Does FA really only make sense in a "real" larger Fabric Connect network?
Am I wrong in considering dropping it in favor of static VLANs?

Thanks,

Nicolas

[Anonymous]

More testing with the FA/LLDP VLAN provionning delay on EXOS.
I did not see any noticeable difference in FA provisionning time between EXOS 22.7.3.5, 30.7.2.1 and 31.5.1.6.
It was not as bad as I said before: about 36-37 seconds, with the default LLDP transmit interval, in my environment (I may have hit another issue when I consistenly got a 1 min delay initially).
But that's still way too slow if you ask me.

I also tried explicitly configuring the management I-SID/VLAN on the port/MLT in VOSS (fa management i-sid <isid> c-vid <vlanid>).
I guess this feature is really aiming at provisionning native FA devices (cams, APs, ..), and I don't have any, but it was still worth a try.
(Also EXOS has a similar command, "configure fabric attach management vlan", which seems to only makes sense in standalone proxy mode.)
As could be expected, this configuration does make the said management VLAN come up almost instantly, as VOSS will map it without waiting for LLDP advertisements to be sent back and forth, but this does not affect the provisionning delay for the other VLANs.

So, I'll be sticking with EXOS 30.7 with static VLANs for now.
Thanks all for your help.

[Roger_Lapuh]

Nicolas
we are aware that in some scenarios we are relying on LLDP timers to signal service bindings. We will be addressing that by sending triggered updates (LLDP). Stay tuned, we hope to have this addressed by 1H 2022. There will be SW updates required on VOSS and EXOS.

Roger

[Evert]

Hi Roger,

Any news on the triggered LLDP updates? I couldn't find mention of this in release notes of VOSS 8.6 or 8.7.

We ran into an issue with devices for which the FA takes too long, the device has given up trying to reach its gateway before traffic is passed on the uplink of the exos switch (the FA vlan assingment is pending).

Thank you in advance!
Evert.

[Roger_Lapuh]

Hi Evert
yes Release 8.8 will support this from the VSP perspective. GA end of August. Roger