Ethernet Switching
Highlighted
Ethernet Switching

Virtual chassis management

‎12-21-2018 01:32 PM

Hi everyone,

Please consider the following example


Consider following example:

Below we have three Switches in Virtual chassis, each SW has me port connected to different subnet.

 

Case1:

SW1(Master)---me---199.199.199.1/24---Network
SW2(Back up)---me---200.200.200.1/24---|
SW3( line card)--me--198.198.198.1/24--|


1) if we do ssh using 198.198.198.1 which is ip on SW3's ME, will SW3 dirtect that to master SW1? or SW3 will allow SSH to itself?

 

Case2:

SW1(Master)---me---199.199.199.1/24---Network
SW2(Back up)---me---199.199.199.2/24---|
SW3( line card)--me--199.199.199.3/24--|

1) If we do SSH 199.199.199.3, will SW3 direct it to SW1 ( master)?

 

Thanks and have a nice weekend!!

 

 

2 REPLIES 2
Highlighted
Ethernet Switching

Re: Virtual chassis management

‎04-05-2019 07:53 AM

Good day,

 

First of all, I'd like to say that is unsupported configuration and default behaviur can be various in different Junos version.

The best way to have VME interface for network connectivity and console access for emergency access.

 

FYI:

case1: If you have correct routing or you try to connect to switch from same network (198.198.198.0/24) you will be able to connect to switch and redirect to Master-RE via internal VC infrustructure. Same behaviur as for console connection.

 

case2: You will be able to connect to switch and you will be redirected to Master-RE via internal infrastructure.

 

Use "show virtual-chassis login" for understanding 😉

Highlighted
Ethernet Switching

Re: Virtual chassis management

‎04-06-2019 06:08 AM

The way to think about these dedicated mgmt ports is that they will not permit transit traffic.  And they are by default in the master base routing instance using the inet.0 route table. 

 

Some platforms of more recent versions of Junos allow the moving of the mgmt port to routing instances so they can have an independent route table.

 

So most of the connectivity issues with dedicated ports revolve around asymmetrical routing.  The return packet route for connections coming in or from the dedicated port go out a different device port.  And since the mgmt interface does not allow transit traffic the connections fail.

 

One solution is to make sure the dedicated mgmt port is alone in either the base inet.0 or a separate routing instance.

 

another solution is to use NAT for traffic into the mgmt port subnets so that the source ip address of traffic destined for the mgmt port is changed to be in the same subnet.  Thus the replies always go back out the dedicated port.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Feedback