cancel
Showing results for 
Search instead for 
Did you mean: 

Managment network across VOSS, BOSS, and EXOS switchs in a Fabric deployment?

Managment network across VOSS, BOSS, and EXOS switchs in a Fabric deployment?

David_Nelson
New Contributor II

Can anyone advise me on setting up a management network for a small campus network with VSP 7200’s as the core, ERS 5900’s (base license) as BEB’s and EXOS switches at the edge. In this deployment there are no BCB’s so I am not worried about avoiding IP on the core. I have been scrubbing through the docs, but I am not finding much to address management across various switches. On the ERS’s I have a C-VLAN set as the management vlan, that gives me management access for the ERS’s and the EXOS switches across the fabric, but I can’t seem to figure out how to get management access to the VSP’s from this management vlan?

I have played around with IP Shortcuts, and can ping the CLIP IP from one VSP to another, but can’t figure out how to reach the CLIP from my management network.

 

Thank you!

1 ACCEPTED SOLUTION

Ludovico_Steven
Extreme Employee

The CLIPs are going to be different IP subnets, so if your mgmt station is in the C-VLAN you will need to give each VSP an IP on that same C-VLAN and have routes to them to reach the CLIPs. Or you can forget about the CLIPs and just manage the VSPs from the IP you give them on that C-VLAN. If this is a small network that is fine.

In large fabrics with many VSPs it is usually preferred to manage the VSPs from the CLIPs (which are advertised via ISIS) rather than stretching a L2 CVLAN across the whole network.

View solution in original post

9 REPLIES 9

ExtremeNorth
New Contributor III

I see that VOSS 8.2.0 is released and there is now a Segmented Management Interface which says “the Management plane (management protocols) is separated from the Control Plane (routing plane) from a process and data-path perspective”.  There are three interface options that can now be used:

• Out-of-Band (OOB) management IP address (IPv4 and/or IPv6)
• In-band Loopback/circuitless IP (CLIP) management IP address (IPv4 and/or IPv6)
• In-band management VLAN IP address (IPv4 and/or IPv6)

I started configuring switches to use a CLIP address in the GRT for management, but now there is an option to use a CLIP address in any VRF including the GRT.  I distribute routes from the GRT to a Management VRF so I could share the management routing table within a L3VSN.

So the question is:

Should I leave the CLIP in the GRT or move it to a VRF?  How would this affect IP shortcuts?

Terrel.

PeterK
Contributor II

The Problem I see, the OOB Port on VOSS ist not completely separated as the name offers.

In XOS it is separated.  

AFAIK is, OOB (mgmtethernet VRF) and GRT can access device host / cpu.

But between cpu and asic, it seems that there is no choice to check something, like source-vrf. But I think there should be a VOSS enhancement later this year, but I don’t know if this really solve this issue.

 

In one of my firt voss-migrations I run into following issues:

  • You can’t have IPs out of same range on OOB-Interface and on L3-Interface in GRT
  • If you access OOB from a source IP-Net which is also defined, but not connected in GRT, this is also not possible

ExtremeNorth
New Contributor III

Thanks for the response Paul, in general I preferred to use the OOB interface, but I noticed the same issues with the NMS getting confused on which interface to use.  As I update the VSP’s in the Core I will be moving to use the In-Band loopback address (since I need these for IP-Shortcuts and L3VSNs) but have a separate OOB network if I have to modify SPB parameters which requires ISIS to be disabled.

Terrel Hobbs, Yellowknife, NT

EXTR_Paul
Extreme Employee

@ExtremeNorth

 

That is a good question.  I ran into this issue early on in my career with the ERS8600.  The Org I worked for had around 20+ ERS8600 and we managed them with their Out-of-Band (OoB) interfaces. And we managed the edge access NORTEL switches with their In-Band (IB) interface.  And at the time having a mixture caused issues and confusion for the us and our tools.  To NORTEL’s credit they did make enhancements to their NMS product to account for networks where there is a mixture of OoB and IB managed devices. 

 

IMHO the concepts around Out-of-Band (OoB) and In-Band (IB) management is to keep them 100% separate.  Have your core NMS solutions managing your in-band network.  Then have another system to manage your OoB network.  The last thing you want is an issue in your Production in-band network knocking out your OoB network. Or, vice versa.  Now you have two dead networks. 

Keep your IB and OoB networks air-gapped. 

GTM-P2G8KFN