- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- Aruba & ProVision-based
- >
- VSF + LLDP MAD
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-10-2016 01:08 PM
тАО04-10-2016 01:08 PM
VSF + LLDP MAD
We have linked two Procurve 5406 switches (v3 modules, FW 16) with VSF, created the stack and everything is working as intended.
I now want to create the LLDP-MAD link to prevent a split situation but I'm not exactly sure how to do it.
I know I need an assist device to be linked (trunked) to both members and a simple command which shows the stack the IP address and the community string of the assist device.
HP-VSF-Switch(config)# vsf lldp-mad ipv4 10.0.0.1 v2c public
The question is, do I need to use a dedicated switch as an asset device? The VSF stack is linked with 13 switches with trunks, so using a second trunk in one of those (for the MAD link) could possibly lead to a loop?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-14-2016 07:45 AM - edited тАО04-14-2016 07:46 AM
тАО04-14-2016 07:45 AM - edited тАО04-14-2016 07:46 AM
Re: VSF + LLDP MAD
Interesting question. Personally I don't know even if I think it could be a best practice to use a separate ad-hoc switch for this task since MAD "assist" device (apart other requirements specified on Paragraph 19.19.6, see below) and VSF devices pair must be all on a common IPv4 Subnet.
If so, it would also be interesting to know if - actually (latest Firmware) - a little HPE 1920 series switch (Comware 5) could act as MAD "assist" device.
Also will be interesting to know the relationship between LACP-MAD and LLDP-MAD since both techniques play a role (and are cited) when a VSF stack is deployed.
As reference to VSF and LACP+MAD and LLDP+MAD see Paragraphs 13 (LACP-MAD) and 19.19 (LLDP-MAD) of "HPE ArubaOS Switch Management and Configuration Guide for K/KA/KB.16.01" (March 2016).
I'm not an HPE Employee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-11-2016 05:50 AM - edited тАО06-22-2016 12:25 AM
тАО06-11-2016 05:50 AM - edited тАО06-22-2016 12:25 AM
Re: VSF + LLDP MAD
parnassus wrote: If so, it would also be interesting to know if - actually (latest Firmware) - a little HPE 1920 series switch (Comware 5) could act as MAD "assist" device.
After digging a little bit I found that it looks like the HPE OfficeConnect 1920 Switch series doesn't support MAD passhthrough...
Edit: finally found an interesting Configuration Guide recently published about VSF. Details here.
On page 19 there is a nice "VSF HA topology with LLDP-MAD" configuration example (an Aruba 2920 is used as MAD).
Two statements I didn't understood very well when reading the paragraph "Best practices and configuration notes" on Page 23, it's written:
- For High Availability applications, it is recommended to trunk ports across VSF members on different modules (so the guide suggests to terminate each incoming Trunk - here I mean BAGG - within the same unit - no matter if it is Commander or Standby - but do so using ports located on different unit's modules <- this is to prevent disruption on module fault).
- VSF is not compatible with Distributed Trunking and Meshing (so the guide states that an incoming Trunk - again here I mean BAGG - can't be splitted between two units, so between Commander and Standby).
Does this really mean that an access Switch connected to the VSF through a BAGG (made of two or more aggregated ports) must terminate all its BAGG members' links on one and only one VSF member without the chance of distributing/sharing BAGG's member links to both VSF members?
The only permitted scenario is when a BAGG terminates inside the same VSF member (eventually on different Modules, as suggested).
I'm not an HPE Employee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-02-2019 07:58 AM
тАО05-02-2019 07:58 AM
Re: VSF + LLDP MAD
There is actually a configuration guide.
Vertical Switching Framework VSF:
https://community.arubanetworks.com/aruba/attachments/aruba/lms/14/1/ArubaOS%20VSF%20Configuration%20Guide.pdf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-07-2019 01:56 PM
тАО05-07-2019 01:56 PM
Re: VSF + LLDP MAD
Yes, the URL you posted links directly to the old VSF Guide I wrote about. The reference Thread was removed even if the link to the PDF still exists.
VSF is explained very well now with an entire chapter inside each ArubaOS-Switch Management and Configuration Guide related to Aruba 5400R zl2 and Aruba 2930F switch series (since ArubaOS-Switch 16.02 up to latest 16.08).
I'm not an HPE Employee