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]

Hello Mig,

Yes, I guess for many/most customers, VLAN automation is worth the delay.
My use case is a medical devices factory, where a longer than expected interruption will cause a chain reaction and escalate very quickly.

Thanks for the reminder about the 8.4.2.0 DHCP issue, upgrade is planned already for the next maintenance window, i.e. next week.

OK, I missed the automatic LAG creation in EXOS 31.x.
I think I'll still stay on 30.7 for now (actually upgrading from 22.7 as part of the network upgrade) until 31.x gets more widely spread.

I'm only using FA between X450G2 stacks and VSP7400's, not sure if provisionning I-SIDs over RADIUS would work here, but I don't feel like making the network infrastructure (vs. user devices) rely on a RADIUS server.
Already using ExtremeControl NAC on X450G2 with netlogin on all ports, but you I think you have more of an ERS scenario in your mind, don't you?