cancel
Showing results for 
Search instead for 
Did you mean: 

VOSS: housekeeping and UX requirements

VOSS: housekeeping and UX requirements

Volker_Kull
Contributor

For VOSS we have some ideas out of the usage in the field:

  • L3 interface enable/disable function (we are using preconfiguration before L3 migration from legacy core/distribution networks to campus fabric)
  • ERSPAN like EXOS to support more than VSP physical interfaces (ERSPAN remote receiver)
  • using automatic ECMP in parallel fabric NNI links (currently there has been a MLT before configuring NNI)
  • using ranges in configurations (f.e. port configurations, currently supported only at MLT)

more in our pipe…

br

Volker

9 REPLIES 9

AlexN
Extreme Employee

Volker,

that discussion has two objectives: 

  1. Understand, to a very detail, your request/idea, beyond any doubt, so that if we take it to PLMs as Feature Request we can be very specific. Blanket requests don’t work there
  2. For the same reason, if products already have similar feature/capability, or decent workaround to achieve same goal, we point it out here and try to understand whether it’s going to work or not for your case

Now let me “decrypt” my comments:

  1. Enable/disable L3 interface - it’s nice to have, sure, and also feasible technically, that’s why I said “it makes sense”, although you can make migrations today without it, using alternative methods (that was my remark about “convenience feature” - there are alternatives so you can perform migrations without it), for example: 
    1. Make a script to add/change as much L3 interfaces as you want, and batch-execute is at cutover date/time
    2. Architect migration in such a way, that you can do partial/staged migration, where you don’t need to migrate all 100’s DefGW IPs in one go, but do it VLAN by VLAN,  so there is no rush with IP changes/updates
  2. (here is where I don’t understand you really. We are talking about VOSS, right ? Why EXOS is suddenly mentioned?) Please see https://extremeportal.force.com/ExtrArticleDetail?n=000034218&q=Fabric%20RSPAN . You asked for ability to monitor/mirror traffic on any VOSS network port  remotely, i.e. deliver mirrored data to any location within the network, correct ? Fabric RSPAN does exactly that. You can build regular mirror session, and then direct mirrored traffic to ISID (instead of physical port), and such ISID can be “received” on any other VOSS port within the network, thus allowing you remote port mirror capabilities. So I repeat my question: what do you think needs to be improved in current Fabric RSPAN implementation ?
  3. It’s possible to implement XMC Workflow today, that will detect parallel ISIS links and update configuration to bundle them as a LAG.  Answering to your question about “why do you need Extreme branded switch”: If you are aware about any other vendor that can script/build workflows for auto-LAG ISIS link on their switches - please let me know.  At the same time, such feature may potentially be implemented in VOSS code, however there are customers who intentionally want parallel links to be Active-Standby, so such Auto-LAG feature, if implemented, should be optional
  4. As I said, blanket requests do not work here due to undefined scope of work in that case. I recognise your intention might have been to allow ranges in different parts of configuration, however we need to know where exactly, and if there are indeed multiple parts - order of priority for you

Hope that helps. 

In order to make conversations here more focused - let’s give individual message thread to every ask/idea going forward

Alex

Best regards/Un saludo
Alex

Volker_Kull
Contributor

Ok,

 

I´m not really understand your cryptic comments.

RSPAN is here in EXOS, in VSP is only a part of it.

You can script everything, but why do I need an Extreme branded switch?

It´s not only about port ranges. It´s about ranges wherever needed.

 

Volker

 

AlexN
Extreme Employee
  1. OK, makes sense as a convenience feature
  2. Fabric RSPAN is already here. What do we miss there ? 
  3. Can be scripted even today, can potentially be implemented in the code, however not everybody would want NNI links to be automatically LAGed
  4. Port range - please provide specific examples. Port ranges are already allowed pretty much everywhere 
Best regards/Un saludo
Alex

Volker_Kull
Contributor

Hi ALex,

 

here the uses cases:

  • enable/disable VLAN interfaces
    • during migration projects from legacy network designs to fabric design you have to migrate the routing after interconnecting the L2 areas. Having tens of interfaces you need to pre-provision the routing interfaces in the fabric for having limited interruption during migration (disable legacy and enable fabric). The same procedure to migrate some IP-Interfaces from fabric VLANs to ISFW. Every other Extreme gear (and competitors) support this but not VSP.
  • ERSPAN
    • we need the same functions like EXOS to support remote troubleshooting without access of a physical switchport
  • NNI-Link redundancy
    • In discussion with PLM
  • Range configuration
    • is there but ONLY in MLT configurations

Volker

AlexN
Extreme Employee

Hi Volker,

 

first, let’s agree to put only one ask per request, that will simplify tracking and transition between Hub and internal systems.

  1. please always provide use case/scenario description. Let’s focus on user experience you’d like to have, rather than jump directly to conclusion/solution. For instance, you ask for L3 int enable/disable function, but why ?! If it’s about VLAN IP interface - it does not come up until you put at least one active member in this VLAN, so you are free to pre-configure it all the way you want. Or you mean CLIPs ? Or something else ?  That’s why it’s important to provide use case
  2. ERSPAN - same thing. Why do you need it ? Are fabric Extend tunnels/interfaces not enough ?
  3. There is always only one link between any two given Fabric nodes, it’s fundamental. If you want more than one physical link between two nodes - they have to be joined into one logical entity, so that fundamental law of single adjacency between two nodes is observed. Now, what you are asking for is MLT auto-detection/auto-configuration, right ?
  4. This is supported today. Int gig Eth 1/1-1/3 for instance. Or please be specific in where is it missing. But from general perspective, for mass deployment operations we recommend to use either templates (XMC) or scripting if you want to have total control   
Best regards/Un saludo
Alex
GTM-P2G8KFN