Hi guys,
I have an EX4200-48T VC with 4 members. The vme.0 is already configured and working. Now I need another management interface and I was thinking If i could configure another vme interface (e.g vme.10) on the VC and use one of the free MGT port on the switch.
vme.0 is connected to ge interface on switch A
vme.10 will be connected to ge interface on switch B
Will it work? If yes, does Juniper recommend doing this i.e having multiple management interfaces?
Thanks
NO
you can have only one vme it is available over any me. interface and you get directly connected to the RE, independent of input switch.
regards
alexander
as they are different VCs you have to create the vlans on each VC
AND you need to enable that vlans on the trunk interfaces between the VCs as per default a trunk dow not carry vlans automatically
( trunks can auto set the vlans with MVRP protocol)
regards
alexander
Hi everybody,
I noticed when when i do commit on master switch in Virtual-chassis, commit is also performed on all members switches without requring "commit synchronise" or set system commit synchronise command
Do we know when this behavior was first introduced in Junos ?
Thanks and have a nice weekend!!
Hi,
please find the article
https://kb.juniper.net/InfoCenter/index?page=content&id=KB12879
it contains Master and Backup, no just member linecards
I'd like to be informed if a member of a VC goes away (EX4300 or 4600). I was looking a while back and remember finding an SNMP trap that was related, but am having trouble finding the information again. If someone can someone point me to SNMP trap docs, or if there are syslogs invovled when a member is lost it would be helpful.
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 I agree with the last reply,
vme you can only have one, you could configure 2 me0 interfaces one for the master and one for the backup as explained here:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB25724
vme stands for virtual management ethernet, it is basically a virtual interface that you can reach through any of the members of a VC. I personally think this is more efficient than configuring different IPs for the different members once on the master you ca use:
>request session member <member id>
to move between the different members of the VC.
Hi B2
I can confirm there is a syslog this is on a 4300VC I cold rebooted member 1:
Mar 22 14:59:35 CHASSISD_VCHASSIS_MEMBER_UPDATE_NOTICE: Membership update: Member 1->1, Mode Master->Master, 1M -1B, Master Unchanged, Members Changed Mar 22 14:59:35 CH_DEVRT_CHANGE: Member 1->1, Mode M->M, 1M -1B, GID 0, Master Unchanged, Members Changed Mar 22 14:59:35 CHASSISD_VCHASSIS_MEMBER_LIST_NOTICE: Members: 1M Mar 22 14:59:35 CHASSISD_VCHASSIS_MEMBER_OP_NOTICE: Member change: vc delete of member 0 Mar 22 14:59:35 mvlan_member_change_delete: member id 0 (my member id 1, my role 1) Mar 22 14:59:35 mvlan_handle_iflm: Rcvd ifl msg, op 3, ifl_index 4, if_name bme0.32769, member_role 1 flags 0x0 Mar 22 15:03:09 CHASSISD_VCHASSIS_MEMBER_UPDATE_NOTICE: Membership update: Member 1->1, Mode Master->Master, 1M 0B, Master Unchanged, Members Changed Mar 22 15:03:09 CH_DEVRT_CHANGE: Member 1->1, Mode M->M, 1M 0B, GID 0, Master Unchanged, Members Changed Mar 22 15:03:09 CHASSISD_VCHASSIS_MEMBER_LIST_NOTICE: Members: 0B 1M Mar 22 15:03:09 CHASSISD_VCHASSIS_MEMBER_OP_NOTICE: Member change: vc add of member 0
as for the traps maybe this can help you:
I do not trully understand the impact of the "protocols rstp interface ge-x/x/x edge" statement.
J-TechLibrary mentions:
For Rapid Spanning Tree Protocol (RSTP), VLAN Spanning Tree Protocol (VSTP), or Multiple Spanning Tree Protocol (MSTP), configure interfaces as edge ports or edge interfaces. Edge ports do not expect to receive BPDUs. If a BPDU is received, the port becomes a nonedge port and the Edge interfaces immediately transition to a forwarding state.
Okay thats clear, but this is also the case with interfaces that are not configured with the interface ge-x/x/x edge statement.
That same TechLibrary article https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/edge-edit-protocols-stp.html) (Ethernet Switching Feature Guide) states:
NOTE
Although the edge configuration statement appears in the [edit protocols stp interface (all | interface-name)] or [edit protocols rstp force-version stp interface (all | interface-name)] hierarchy on the switch, this statement has no effect on the switch operation if you configure it.
What is the meaning of: "no effect"... Does the "protocols rstp interface ge-x/x/x edge" statement have no effect/impact at all? So what is the function of this statement?
Configuring a port as edge allows it to enter the forwarding state immediately, and bypass the listening and learning states.
The tech note is indicating that stp and rstp operating in forced stp mode do not support the edge feature.
Thank you for your response,
You are telling me that edge is a rstp feature, not supported with stp.
OK, but I still don't get it:
Listening is a stp state, not a rstp state. Furthermore, in rstp, point-to-point (= full duplex) links, transition to forwardig state without waiting for the forward delay timer to expire as with stp. This is standard rstp behaivior so the "edge" command doesn't seem to make sense. Thats my point.
Hi Jean,
Answered inline.
Thank you for your response,
You are telling me that edge is a rstp feature, not supported with stp.
OK, but I still don't get it:
Listening is a stp state, not a rstp state. Furthermore, in rstp, point-to-point (= full duplex) links, transition to forwardig state without waiting for the forward delay timer to expire as with stp. This is standard rstp behaivior so the "edge" command doesn't seem to make sense. Thats my point.
[Ans] You're right - when a port (point-to-point and full-duplex) just has RSTP enabled, and it doesn't receive any BPDU on it then it transitions to forwarding stable immediately (RSTP default behavior). And this behavior is the same if this port was manually configured as an edge port i.e. "set protocols rstp interface <> edge". The difference in port behavior is when the port does receive a BPDU.
A normal port with RSTP enabled would start participating in spanning-tree (send out BPDUs, elect RSTP state etc.). Whereas a manually defined edge port gives us control with as to what action we want the port to take if it receives a BPDU, using CLI "set protocols rstp bpdu-block-on-edge". Also lets us decide on the port recovery after it's blocked by a BPDU received:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB24166&cat=EX_Series&actp=LIST (non-ELS only)
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/spanning-tree-bpdu-protection.html (includes ELS and non-ELS config examples of how to recovery blocked edge ports)
Regarding the previous note and your question on it, I agree with the above explanation - the knob doesn't take any effect on the switch if you had STP enabled one way or other.
NOTE
Although the edge configuration statement appears in the [edit protocols stp interface (all | interface-name)] or [edit protocols rstp force-version stp interface (all | interface-name)] hierarchy on the switch, this statement has no effect on the switch operation if you configure it.
And your question:
"What is the meaning of: "no effect"... Does the "protocols rstp interface ge-x/x/x edge" statement have no effect/impact at all? So what is the function of this statement?"
The NOTE doesn't say "protocols rstp interface ge-x/x/x edge", it says "set prototocls rstp force-version interface ..." 
, although I see your point and hope I've answered it above.
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .
Miryaz,
Thank you for your response,
You are stating that: “The difference in port behavior is when the port does receive a BPDU. A normal port with RSTP enabled would start participating in spanning-tree (send out BPDUs, elect RSTP state etc.). Whereas a manually defined edge port gives us control with as to what action we want the port to take if it receives a BPDU, using CLI "set protocols rstp bpdu-block-on-edge". Also lets us decide on the port recovery after it's blocked by a BPDU received”
What you actually describe is BPDU protection, and indeed you have to configure BPDU protection in conjunction with set protocols rstp interface xx-x/x/x edge.
As earlier mentioned: “this statement has no effect on the switch operation if you configure it” . So, in fact, "set protocols rstp interface xx-x/x/x edge" is only labeling the fysical interface so it can be used in conjunction with configuring BPDU protection?
Do I now understand is well?
Hi experts,
I‘m looking for a sample config for RoCE/RDMA on QFX.
Peer is Win2016 with Hyper-V.
There are bunches of config in the wild for other vendors boxes (C,HP,Dell...) , but almost nothing for Junos...
Example:
https://jtpedersen.com/2017/06/rocerdmadcb-what-is-it-and-how-to-configure-it/
Any input very welcome.
Thanks,
Stefan
I was asked what I think about the proposal to link one EX series switch with 6x 1 Gbps CAT6 copper interfaces in a 802.1ad link aggregation Group to another existing EX access switch Virtual Chassis from the same model. The reason is saving time and money. They want to connect 8 PC’s but there are only 6x CAT6 cables to the existing EX series Virtual Chassis Access switches in the Satellite Equipment Room available.
The existing LAN has a spine leaf topology, just about as displayed in the sketch, but with the absence of the core layer switches and with a lot of layer 2 vlans. The (orange) Distribution switches are coupled together with 2x 10Gbps fibre LAG interfaces to form a Virtual Chassis.
The distribution switches have a rstp bridge priority of 4k, the (blue) access switches have a bridge priority of 16k (rstp enabled on all interfaces). So the new ex-3400 switch must have a bridge priority of, let’s say, 32k. There is no BPDU, loop or root protection. Storm control is enabled on all the switches.
What do you think about this proposal?
With regards,
Jean
I was asked what I think about the proposal to link one EX series switch with 6x 1 Gbps CAT6 copper interfaces in a 802.1ad link aggregation group to another existing EX access switch Virtual Chassis from the same model. The reason is saving time and money. They want to connect 8 PC’s but there are only 6x CAT6 cables to the existing EX series Virtual Chassis Access switches in the Satellite Equipment Room available.
The existing LAN has the rather common spine leaf topology, just about as displayed in the sketch below, but with the absence of the core layer switches and with a lot of layer 2 vlans. The (orange) Distribution switches are coupled together with 2x fibre LAG interfaces to form a Virtual Chassis.
The distribution switches have the lowest rstp bridge priority, the (blue) access switches have a higher bridge priority (rstp enabled on all interfaces). The new ex series switch shall be configured with the highest bridge priority of all. There is no BPDU-, loop-, or root protection. Storm control is enabled on all the switches.
What do you think about this proposal?
With regards,
Jean
Okay, now its clear to me.
It's like the Cisco portfast command.
Thank you.
With regards,
Jean
