Switching

Hi all,

I have 2 x qfx5100-48s-6q.

Individually, i have configured its em0.0 port for management purpose and assigned an ip to each of the switch.

During the virtual-chass pre-provisioned setup,  i have also setup an vme.0 interface and assigned an ip to it.

switch1 em0.0 -> 192.168.1.1

switch2 em0.0 -> 192.168.1.2

switch1 vme.0 -> 192.168.1.3

After the virtual chassis setup has completed and up, i realized my vme.0 interface is still down.  

However, I can access the master switch via em0.0 - 192.168.1.1

q1) In a virtual chassis setup,  can we still access individual switches via its em0.0 interface IP ?

e.g.  192.168.1.1 will access switch1 em0.0

        192.168.1.2 will access switch2 em0.0

         192.168.1.3  will always access the master switch -- like a floating IP.

q2) Any idea why is my vme.0 interface down ?  Should we actually configure the em0.0 interface with an IP during the virtual-chassis setup ?

Regards,

Alan

.Hi there,

for the vme interface to come up you need to delete the configuration of the other management interfaces, the vme will be setup as a virtual management interface and you will be able to reach it through the management interface of any of the VC members so you will manage each VC with just one IP that can be reached from any VC member's management port. Once in the VC use:

 >request session member X

to move between the VC members

Try deleting the em interfaces so vme can come up.

Check this out:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB11044&cat=EX4200_1&actp=LIST 

Cheers!

Hi Carlos,

Thanks for your reply.

1) In a virtual-chassis, does accessing via em0.0 will always leads to the master ?   if yes, why would one prefer to use a vme interface then ?

2) Are we able to have the em0.0 interface/ip for individual switches and also have the vme.0 for the master switch ?

e.g. access individual switch -> use em0.0 IP, access master switch -> use vme.0 IP

3) Try using management instance set system management-instance,  true enough, em0 is on now in the mgmt_junos routing instance.   But how do I make vme.0  interface to be part of the mgmt_junos routing instance ?

Regards,

Alan

Hello Alan 

see inline:

1) In a virtual-chassis, does accessing via em0.0 will always leads to the master ?   if yes, why would one prefer to use a vme interface then ?

it does it always takes you to the master, the idea of the vme is that you use only one IP to manage the whole stack, so you basically can get to the vme's ip address from any of the physical management interfaces on each VC member always using the same IP.

2) Are we able to have the em0.0 interface/ip for individual switches and also have the vme.0 for the master switch ?

e.g. access individual switch -> use em0.0 IP, access master switch -> use vme.0 IP

you can but then you cannot use the vme, you would use the management interface of each member:

..."To access individual switches via their management interface (if required), their respective me0 interface can be directly configured with an IP address. 

For Example:

groups {
    member0 {
        interfaces me0 unit 0 family inet address <address0>
    }
member1 {
    interfaces me0 unit 0 family inet address <address1>
}
}

The above configuration is applicable only on the master and backup, on which me0.0 interfaces are present.

To directly use the Linecard's me0 interface, perform the following procedure:

1. The following special configuration is required to take it away from the management VLAN:
   

   virtual-chassis {
       member 2 {
           no-management-vlan;
       }
   member 3 {
       no-management-vlan;
   }
   }

2. Now, me0.<xxxxx> should be configured from the shell as follows: 
   

   root# ifconfig me0.0 local=10.10.10.1 netmask=255.255.255.0

3) Try using management instance set system management-instance,  true enough, em0 is on now in the mgmt_junos routing instance.   But how do I make vme.0  interface to be part of the mgmt_junos routing instance ?

For this I think you would need to use the method on point #2 and the vme will stay down if you use the individual management iterfaces 

source:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB25724&cat=EX6200&actp=LIST 

Cheers!

Carlos

Hi Carlos,

Thank you for your reply.

1) I am using 2 x qfx5100-48s-6q to setup the virtual chasiss,  there is no me interface.  Only em0.  Originally when i setup the switch individually,  each em0.0 is assigned its own IP.
switch1 em0.0 - 192.168.0.1/24
switch2 em0.0 - 192.168.0.2/24

switch1 vme.0 - 192.168.0.3/24

After the virtual chassis  is up,   I can access the em0.0 - 192.168.0.1,  but i cannot access 192.168.0.2.

I also cannot access 192.168.0.3 (because the vme interface is down).

2) Using the groups method dont seems to work for me.

set groups member0 interfaces em0 unit 0 family inet address 192.168.0.1/24
set groups member3 interfaces em0 unit 0 family inet address 192.168.0.2/24

After commiting, i still can't access 192.168.0.2.

=============================================

q1) So it seems to me

access via em0.0 ->  192.168.0.1 > always go to the master

access via vme.0 -> 192.168.0.3 -> always go to the master  (provided that i remove the em0 interface)

What the difference ?

q2) Any idea why the group method can't work  so i can access the switches individually ?

q3) Can i confirm that

- the EM and VME interface cannot work concurrently

- VME interafce cannot work with mgmt_junos management routing instance ?

Regards,

Alan

Hello Alan

see comments inline 

1) I am using 2 x qfx5100-48s-6q to setup the virtual chasiss,  there is no me interface.  Only em0.  Originally when i setup the switch individually,  each em0.0 is assigned its own IP.
switch1 em0.0 - 192.168.0.1/24
switch2 em0.0 - 192.168.0.2/24

switch1 vme.0 - 192.168.0.3/24

ok should be pretty much the same but the interface name is different

After the virtual chassis  is up,   I can access the em0.0 - 192.168.0.1,  but i cannot access 192.168.0.2.

I also cannot access 192.168.0.3 (because the vme interface is down).

2) Using the groups method dont seems to work for me.

set groups member0 interfaces em0 unit 0 family inet address 192.168.0.1/24
set groups member3 interfaces em0 unit 0 family inet address 192.168.0.2/24

After commiting, i still can't access 192.168.0.2.

=============================================

q1) So it seems to me

access via em0.0 ->  192.168.0.1 > always go to the master

access via vme.0 -> 192.168.0.3 -> always go to the master  (provided that i remove the em0 interface)

What the difference ?

the difference here is that the vme's ip address is reachable through any of the physical management interfaces so if you use the ip 192.168.0.1 to connect to the device example lets say you loose member 0, it crashed and died you can access the VC with 192.168.0.1 through the cable on member 1, What if you loose member 1 and member 0 is the only one up? you can access it with the same ip 192.168.0.1. through the cable on member 0.

Basically the advantage is that you can access the VC with the same IP address indepently from the physical interface you are using to reach it.

Hope that is clearer

q2) Any idea why the group method can't work  so i can access the switches individually ?

you need to apply the group with the apply-groups command 

{backup:0}[edit]<----------- member 0
root@SWITCH# show apply-groups 
## Last changed: 2019-03-22 14:35:23 PDT
apply-groups [ default member0 ];<------------member0 group

root@SWITCH run request session member 1  

{master:1}[edit]<------------member 1
root@SWITCH# show apply-groups 
## Last changed: 2019-03-22 14:34:29 PDT
apply-groups [ default member1 ];<-----------member1 group 

then you can see:

{master:1}[edit]  <---member1 
root@jtac-EX4300-48P-r037# run show interfaces terse | match inet 

me0.0                   up    up   inet     2.2.2.2             --> 0/0

{backup:0}<--- member0
root@jtac-EX4300-48P-r037> show interfaces terse | match inet 

me0.0                   up    up   inet     1.1.1.1             --> 0/0

q3) Can i confirm that

- the EM and VME interface cannot work concurrently- they cannot 

roo@switch#show interfaces terse | match me
me0.0                   up    up   inet     1.1.1.1             --> 0/0
vme.0                   up    down inet     10.85.155.55/25 

{master:1}[edit]
root@switch# delete interfaces me0

roo@switch#show interfaces terse | match me
vme.0                   up    up   inet     10.85.155.55/25 

- VME interafce cannot work with mgmt_junos management routing instance ?- as far as I know not yet. management instance was recently developed I guess it is possible this will change in the future

Hi Carlos,

Thank you for you reply.

Please disregard the VME interface and groups setup for a moment.

Can you let me know if it is normal to see the same IP for both the em0 interfaces across my 2 virtual chassis member ?

>> em0.0 up up inet 192.168.0.203/24

{master:3}
admin@csj1> show virtual-chassis status

Preprovisioned Virtual Chassis
Virtual Chassis ID: 649c.4deb.f522
Virtual Chassis Mode: Enabled
                                                Mstr           Mixed Route Neighbor List
Member ID  Status   Serial No    Model          prio  Role      Mode  Mode ID  Interface
0 (FPC 0)  Prsnt    VF3715220163 qfx5100-48s-6q 129   Backup       N  VC   3  vcp-255/0/53
3 (FPC 3)  Prsnt    TA3717210250 qfx5100-48s-6q 129   Master*      N  VC   0  vcp-255/0/53

{master:3}
admin@csj1> show interfaces em0 terse
Interface               Admin Link Proto    Local                 Remote
em0                     up    up
em0.0                   up    up   inet     192.168.0.203/24

{master:3}
admin@csj1> request session member 0

--- JUNOS 17.2R3.4 built 2018-11-16 04:23:49 UTC
warning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.
warning: Use of interactive commands should be limited to debugging and VC Port operations.
warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.
warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.
warning: Please logout and log into the VC-M to use CLI.
{backup:0}
admin@csj1> show interfaces em0 terse
Interface               Admin Link Proto    Local                 Remote
em0                     up    up
em0.0                   up    up   inet     192.168.0.203/24

{backup:0}

Regards,

Alan

Hi Alan.

It is if you have the commit synchronize statement at 

{master:1}[edit]
root@4300# show system 

commit synchronize;

so what happens here is that it synchronizes the configuration between the master and backup, in this case that would be expected.

This syncronization is mandatory for HA protocols like GRES, so if you have GRES the best option would be to use a vme.

Hi Carlos,

Thanks for sharing more insights with me.   Yes i am using GRES with commit syncronization.

q1) I always thought GRES must be turn on (pre-requisite) to use virtual-chassis.  Did i get it the other way round ?  It seems like GRES is to further compliment virtual-chassis and we can still have a virtual-chassis without GRES ?

q2) if i do not have commit-syncronization, does that means i can have technically 2 different configs for the master and backup routing engine ?  (e.g. individual em0 IP set at interface level) - is that allow ?

q3) i have ocassionally experience wierd behaviour such that connecitng to my em0 ends me up in the backup member. Could this (commit-syncronise) be the reason ?  (since i have 2 x em0 interface that is setup with the same IP)

q4) VME is not included in junos managment instance. So i guess my best chance is to use groups ?

Regards,

Alan

Still around Carlos ?

Hi Alan,

yep busy days 🙂 I am reviewing your questions now.

Hey Alan,

see inline:

q1) I always thought GRES must be turn on (pre-requisite) to use virtual-chassis.  Did i get it the other way round ?  It seems like GRES is to further compliment virtual-chassis and we can still have a virtual-chassis without GRES ?

you can still have a virtual chassis without GRES, it is just a high availability feature, it works quite well I personally believe Juniper does this quite well, GRES will synchronize your configuration, kernel and interfaces information so when there is a switchover the new master doesn't have to learn everything again, when paired with NSR and NSB it gives you the ability to switchover pretty much seamlessly,.

q2) if i do not have commit-syncronization, does that means i can have technically 2 different configs for the master and backup routing engine ?  (e.g. individual em0 IP set at interface level) - is that allow ?

that is correct but you have to bear in mind the backup might have a different configuration, maybe try this:

-disable GRES 

-disable commit sync

-do the groups config

-apply them to master and backup as necessary

-do protect apply-groups on both

-commit

-activate GRES 

-activate commit sync

-commit

-check if both members have their own em interface

q3) i have ocassionally experience wierd behaviour such that connecitng to my em0 ends me up in the backup member. Could this (commit-syncronise) be the reason ?  (since i have 2 x em0 interface that is setup with the same IP)

That is strange, unless there is a problem with the master it should always take you to the master, ideally I'd say if the method above doesnt work I would usually prefer to use the vme interface just to avoid the dup IP.

q4) VME is not included in junos managment instance. So i guess my best chance is to use groups ?

As it is right now it is one or the other, I would evaluate if disabling GRES(in case the workaround doesn't work) would give me benefits over using the management routing instance or viceversa. As I told you GRES I can say by personal experience is a nice feature and Juniper does it quite well. So try to balance what would benefit your network the most.

hope that helps Alan, have a good one.