Re: [j-nsp] EX4200 virtual chassis and PoE
Javier Valero wrote: > Hello Victor, > > I don't know if it's the case, but POE does not work on EX4200 with DC power > supplies. > Need to use AC power supplies instead. All my EX4200s are identical with two AC power supplies. Anyway, an EX4200 with DC power supplies would not probably display the kind of "show poe interface" I had posted. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis and PoE
Hello Victor, I don't know if it's the case, but POE does not work on EX4200 with DC power supplies. Need to use AC power supplies instead. Regards. -Mensaje original- De: juniper-nsp En nombre de Victor Sudakov Enviado el: miércoles, 27 de febrero de 2019 8:19 Para: juniper-nsp Asunto: Re: [j-nsp] EX4200 virtual chassis and PoE Doug McIntyre wrote: > On Wed, Feb 20, 2019 at 07:13:43PM +0700, Victor Sudakov wrote: > > Do I need to know anything special to configure PoE in a virtual > > chassis environment? For some reason PoE devices on ports ge-1/0/2 > > and ge-1/0/3 do not get power while the same device in port ge-0/0/2 > > does. All details below. > > Sounds like a bug. While I am not doing any PoE on any EX4200's, I > have a EX2200 stack with a POE version on the FPC 1 position. I've just tried another pair of identical EX4200s in a virtual-chassis, and PoE on the second FPC works fine. Seems like a hardware problem on the second chassis of the first pair. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis and PoE
Doug McIntyre wrote: > On Wed, Feb 20, 2019 at 07:13:43PM +0700, Victor Sudakov wrote: > > Do I need to know anything special to configure PoE in a virtual chassis > > environment? For some reason PoE devices on ports ge-1/0/2 and ge-1/0/3 do > > not get power while the same device in port ge-0/0/2 does. All details > > below. > > Sounds like a bug. While I am not doing any PoE on any EX4200's, I > have a EX2200 stack with a POE version on the FPC 1 position. I've just tried another pair of identical EX4200s in a virtual-chassis, and PoE on the second FPC works fine. Seems like a hardware problem on the second chassis of the first pair. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 virtual chassis and PoE
Dear Colleagues,
Do I need to know anything special to configure PoE in a virtual chassis
environment? For some reason PoE devices on ports ge-1/0/2 and ge-1/0/3 do
not get power while the same device in port ge-0/0/2 does. All details
below.
Virtual Chassis ID: X
Virtual Chassis Mode: Enabled
Mstr Mixed Neighbor List
Member ID Status Serial NoModel prio Role Mode ID Interface
0 (FPC 0) PrsntBM0213317717 ex4200-24t 200 Master* N 1 vcp-1
1 (FPC 1) PrsntBM0214400293 ex4200-24t 128 Backup N 0 vcp-1
Member ID for next new member: 2 (FPC 2)
> show poe controller
Controller Maximum Power GuardManagement StatusLldp
index power consumption bandPriority
0130.00W 3.13W 0W ClassAF_ENHANCEDisabled
1130.00W 0.00W 0W ClassAF_ENHANCEDisabled
> show poe interface
InterfaceAdmin OperMaxPriority Power Class
status status power consumption
ge-0/0/0DisabledDisabled 0.0W Low0.0W
not-applicable
ge-0/0/1DisabledDisabled 0.0W Low0.0W
not-applicable
ge-0/0/2Enabled ON 15.4W Low2.9W0
ge-0/0/3DisabledDisabled 0.0W Low0.0W
not-applicable
ge-0/0/4DisabledDisabled 0.0W Low0.0W
not-applicable
ge-0/0/5DisabledDisabled 0.0W Low0.0W
not-applicable
ge-0/0/6DisabledDisabled 0.0W Low0.0W
not-applicable
ge-0/0/7DisabledDisabled 0.0W Low0.0W
not-applicable
ge-1/0/0DisabledDisabled 0.0W Low0.0W
not-applicable
ge-1/0/1DisabledDisabled 0.0W Low0.0W
not-applicable
ge-1/0/2Enabled OFF 15.4W Low0.0W
not-applicable
ge-1/0/3Enabled OFF 15.4W Low0.0W
not-applicable
ge-1/0/4DisabledDisabled 0.0W Low0.0W
not-applicable
ge-1/0/5DisabledDisabled 0.0W Low0.0W
not-applicable
ge-1/0/6DisabledDisabled 0.0W Low0.0W
not-applicable
ge-1/0/7DisabledDisabled 0.0W Low0.0W
not-applicable
> show configuration poe
interface all {
disable;
}
interface ge-0/0/2;
interface ge-1/0/2;
interface ge-1/0/3;
{master:0}
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
--> so then in a 2node VC one node is Master one node is backup > If they split the master will go down but the backup should survive as it > is > still half of the original cluster > > So this means you should make the part you want to survive to be the > backup-RE and not the master-RE > > --- or did I miss something ?! > > My philosophy is that a default use case of a two nodes VC (and nearly only use case of a VC at all) should be some LAG-based redundancy, when two switches are racked next to each other, connected with two twinax cables and should never split. Of course, technically they can, but a lot of other bloody things, which are out of our control, can happen to them: software bug, misconfiguration, uncontrolled hardware failure like bite errors cased by an overheated SFP, drunk worker with an angle grinder etc. All the exotic cases like geographically distributed VCs etc are, in my opinion, an exercise for the folks who can't figure out what routing protocols are made for. So this should not be the default use case, and the default software behavior should not be adapted to such scenarios. Thus in a two-nodes VC, a *real* failure scenario is a switch failure. When split-detection is enabled, two-nodes VC will only survive in 50% of switch failure cases (if backup RE dies, VC dies, if master RE dies, VC survives). So in fact it's just no better than a signle non-redundant switch. It's worse, in fact, as the added complexity and false expectations are, in fact, more expensive currency than a controlled service outage. Cheers, Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Alexander Marhold wrote: > Therefore if you want to put one node out of a 2 node VC you need to put the > Master down not the backup > Sounds strange but this is according to the rules stated below Interesting twist :-) -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Tobias Heister wrote: > > > > Yes, no-split-detection did help. > > I would like to add to that. My point of view is that you do not > always disable split-detection in a two member VC. You can do so if > you know what that implies. > > The reasoning for the remaining node going into LC mode is that only > the portions of the VC having the majority of nodes stays up and > operational. In a two member VC if for whatever reason one of the > nodes looses connection to the other, we cannot have a majority so > both sides go down. Even if it is the only node remaining. > > But imagine an error scenario where the second node does not crash, > but for whatever reason both sides stay up, but the connection > between them gets lost. With split-detection configured, both sides > will go down and you have a controlled service outage. When no > split-detection is configured both sides remain up and you might > have interesting effects happening in your network with two switches > with the same configuration and same "identity" being up and > forwarding. I have seen that happening in DC scenarios doing stp to > other devices and it is not pretty! Thank you for the explanation. However, in my case I would rather risk an active/active configuration than have two unresponsive switches which can only be revived through manual intervention. This is mainly because: 1. The stacks are in remote locations, you have to ride an all-terrain vehicle to reach them for manual intervention, or sometimes even a helicopter. 2. The stack members are located together in one rack, so the most likely scenarios requiring failover will be a) one switch hardware failure or b) a failure of one of the UPSes or invertors. 3. An active/active situation can be easily mitigated remotely by shutting down a port on the uplink. > > So always check the implications of what the command are doing. If > in your case an active/active split scenario (for worst case) works > out better than a completely offline VC, that is perfectly fine. I > have seen lots of scenarios where it would not be the expected or > wanted behavior. But in my world a VC is no real redundancy method > it is just stacking-NG for additional ports under one MGMT so i > would have two VCs if i relay need redundancy in most setups. But > that is just me ;) I guess, in my case a completely offline VC is unacceptable. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Therefore if you want to put one node out of a 2 node VC you need to put the Master down not the backup Sounds strange but this is according to the rules stated below Regards alexander -Ursprüngliche Nachricht- Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von Alexander Marhold Gesendet: Donnerstag, 26. Juli 2018 09:52 An: 'Tobias Heister'; 'Victor Sudakov'; 'Pavel Lunin' Cc: 'juniper-nsp' Betreff: Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode Hi According to the documentation there should be the following behavior with split-detection enabled: In case of a complete split: If the Master-RE sees MORE THAN HALF of the devices it survives otherwise it disables that part of the cluster If the Backup-RE sees HALF of the devices the backup Re will survive and play the master --> so then in a 2node VC one node is Master one node is backup If they split the master will go down but the backup should survive as it is still half of the original cluster So this means you should make the part you want to survive to be the backup-RE and not the master-RE --- or did I miss something ?! Regards Alexander -Ursprüngliche Nachricht- Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von Tobias Heister Gesendet: Donnerstag, 26. Juli 2018 09:26 An: Victor Sudakov; Pavel Lunin Cc: juniper-nsp Betreff: Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode Hi, On 26.07.2018 09:06, Victor Sudakov wrote: >>> I don't like to explain what others say but I think yes. It's been known >>> behavior since always: in a two-member VC always disable split-detection. >>> You can google for other threads on this in this list. >>> >>> It's always been kind of poorly documented. Last time I checked the docs, >>> instead of just writing clearly that it must be disabled in two-members >>> mode, they "don't recommend" it with some kind of hand-waving explanation >>> that if you estimate that the backup RE failure probability is higher that >>> a split-brain condition blah-blah-blah... Just disable split-detection, >>> that's it :) >> >> Tomorrow we are planning a lab with and without split-detection. I >> hope this solves the issue for us, and if it does, I'm sure to make a >> note in my engineering journal. > > Yes, no-split-detection did help. I would like to add to that. My point of view is that you do not always disable split-detection in a two member VC. You can do so if you know what that implies. The reasoning for the remaining node going into LC mode is that only the portions of the VC having the majority of nodes stays up and operational. In a two member VC if for whatever reason one of the nodes looses connection to the other, we cannot have a majority so both sides go down. Even if it is the only node remaining. But imagine an error scenario where the second node does not crash, but for whatever reason both sides stay up, but the connection between them gets lost. With split-detection configured, both sides will go down and you have a controlled service outage. When no split-detection is configured both sides remain up and you might have interesting effects happening in your network with two switches with the same configuration and same "identity" being up and forwarding. I have seen that happening in DC scenarios doing stp to other devices and it is not pretty! So always check the implications of what the command are doing. If in your case an active/active split scenario (for worst case) works out better than a completely offline VC, that is perfectly fine. I have seen lots of scenarios where it would not be the expected or wanted behavior. But in my world a VC is no real redundancy method it is just stacking-NG for additional ports under one MGMT so i would have two VCs if i relay need redundancy in most setups. But that is just me ;) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Hi According to the documentation there should be the following behavior with split-detection enabled: In case of a complete split: If the Master-RE sees MORE THAN HALF of the devices it survives otherwise it disables that part of the cluster If the Backup-RE sees HALF of the devices the backup Re will survive and play the master --> so then in a 2node VC one node is Master one node is backup If they split the master will go down but the backup should survive as it is still half of the original cluster So this means you should make the part you want to survive to be the backup-RE and not the master-RE --- or did I miss something ?! Regards Alexander -Ursprüngliche Nachricht- Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von Tobias Heister Gesendet: Donnerstag, 26. Juli 2018 09:26 An: Victor Sudakov; Pavel Lunin Cc: juniper-nsp Betreff: Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode Hi, On 26.07.2018 09:06, Victor Sudakov wrote: >>> I don't like to explain what others say but I think yes. It's been known >>> behavior since always: in a two-member VC always disable split-detection. >>> You can google for other threads on this in this list. >>> >>> It's always been kind of poorly documented. Last time I checked the docs, >>> instead of just writing clearly that it must be disabled in two-members >>> mode, they "don't recommend" it with some kind of hand-waving explanation >>> that if you estimate that the backup RE failure probability is higher that >>> a split-brain condition blah-blah-blah... Just disable split-detection, >>> that's it :) >> >> Tomorrow we are planning a lab with and without split-detection. I >> hope this solves the issue for us, and if it does, I'm sure to make a >> note in my engineering journal. > > Yes, no-split-detection did help. I would like to add to that. My point of view is that you do not always disable split-detection in a two member VC. You can do so if you know what that implies. The reasoning for the remaining node going into LC mode is that only the portions of the VC having the majority of nodes stays up and operational. In a two member VC if for whatever reason one of the nodes looses connection to the other, we cannot have a majority so both sides go down. Even if it is the only node remaining. But imagine an error scenario where the second node does not crash, but for whatever reason both sides stay up, but the connection between them gets lost. With split-detection configured, both sides will go down and you have a controlled service outage. When no split-detection is configured both sides remain up and you might have interesting effects happening in your network with two switches with the same configuration and same "identity" being up and forwarding. I have seen that happening in DC scenarios doing stp to other devices and it is not pretty! So always check the implications of what the command are doing. If in your case an active/active split scenario (for worst case) works out better than a completely offline VC, that is perfectly fine. I have seen lots of scenarios where it would not be the expected or wanted behavior. But in my world a VC is no real redundancy method it is just stacking-NG for additional ports under one MGMT so i would have two VCs if i relay need redundancy in most setups. But that is just me ;) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Hi, On 26.07.2018 09:06, Victor Sudakov wrote: I don't like to explain what others say but I think yes. It's been known behavior since always: in a two-member VC always disable split-detection. You can google for other threads on this in this list. It's always been kind of poorly documented. Last time I checked the docs, instead of just writing clearly that it must be disabled in two-members mode, they "don't recommend" it with some kind of hand-waving explanation that if you estimate that the backup RE failure probability is higher that a split-brain condition blah-blah-blah... Just disable split-detection, that's it :) Tomorrow we are planning a lab with and without split-detection. I hope this solves the issue for us, and if it does, I'm sure to make a note in my engineering journal. Yes, no-split-detection did help. I would like to add to that. My point of view is that you do not always disable split-detection in a two member VC. You can do so if you know what that implies. The reasoning for the remaining node going into LC mode is that only the portions of the VC having the majority of nodes stays up and operational. In a two member VC if for whatever reason one of the nodes looses connection to the other, we cannot have a majority so both sides go down. Even if it is the only node remaining. But imagine an error scenario where the second node does not crash, but for whatever reason both sides stay up, but the connection between them gets lost. With split-detection configured, both sides will go down and you have a controlled service outage. When no split-detection is configured both sides remain up and you might have interesting effects happening in your network with two switches with the same configuration and same "identity" being up and forwarding. I have seen that happening in DC scenarios doing stp to other devices and it is not pretty! So always check the implications of what the command are doing. If in your case an active/active split scenario (for worst case) works out better than a completely offline VC, that is perfectly fine. I have seen lots of scenarios where it would not be the expected or wanted behavior. But in my world a VC is no real redundancy method it is just stacking-NG for additional ports under one MGMT so i would have two VCs if i relay need redundancy in most setups. But that is just me ;) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Victor Sudakov wrote: > Pavel Lunin wrote: > > > > in a virtual chassis you could add: > > > > > > > > set virtual-chassis no-split-detection > > > > > > > > This will ensure that if both VC ports go down, the master routing > > > engine carries on working. > > > > > > Are you referring to "Scenario B" in > > > https://kb.juniper.net/InfoCenter/index?page=content=KB13879 ? > > > or a different case? > > > > > > > > > I don't like to explain what others say but I think yes. It's been known > > behavior since always: in a two-member VC always disable split-detection. > > You can google for other threads on this in this list. > > > > It's always been kind of poorly documented. Last time I checked the docs, > > instead of just writing clearly that it must be disabled in two-members > > mode, they "don't recommend" it with some kind of hand-waving explanation > > that if you estimate that the backup RE failure probability is higher that > > a split-brain condition blah-blah-blah... Just disable split-detection, > > that's it :) > > Tomorrow we are planning a lab with and without split-detection. I > hope this solves the issue for us, and if it does, I'm sure to make a > note in my engineering journal. Yes, no-split-detection did help. Thank you Catalin and Pavel very much again. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Pavel Lunin wrote: > > > in a virtual chassis you could add: > > > > > > set virtual-chassis no-split-detection > > > > > > This will ensure that if both VC ports go down, the master routing > > engine carries on working. > > > > Are you referring to "Scenario B" in > > https://kb.juniper.net/InfoCenter/index?page=content=KB13879 ? > > or a different case? > > > > > I don't like to explain what others say but I think yes. It's been known > behavior since always: in a two-member VC always disable split-detection. > You can google for other threads on this in this list. > > It's always been kind of poorly documented. Last time I checked the docs, > instead of just writing clearly that it must be disabled in two-members > mode, they "don't recommend" it with some kind of hand-waving explanation > that if you estimate that the backup RE failure probability is higher that > a split-brain condition blah-blah-blah... Just disable split-detection, > that's it :) Tomorrow we are planning a lab with and without split-detection. I hope this solves the issue for us, and if it does, I'm sure to make a note in my engineering journal. Thank you Catalin and Pavel for your input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
> > in a virtual chassis you could add: > > > > set virtual-chassis no-split-detection > > > > This will ensure that if both VC ports go down, the master routing > engine carries on working. > > Are you referring to "Scenario B" in > https://kb.juniper.net/InfoCenter/index?page=content=KB13879 ? > or a different case? > I don't like to explain what others say but I think yes. It's been known behavior since always: in a two-member VC always disable split-detection. You can google for other threads on this in this list. It's always been kind of poorly documented. Last time I checked the docs, instead of just writing clearly that it must be disabled in two-members mode, they "don't recommend" it with some kind of hand-waving explanation that if you estimate that the backup RE failure probability is higher that a split-brain condition blah-blah-blah... Just disable split-detection, that's it :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Catalin Dominte wrote: > > > > > > I've encountered an odd problem with adding EX4200s (running 12.3R6.6) > > to Virtual Chassis with a nonprovisioned configuration file. [dd] > > > > Looks fine, doesn't it? However, if I later poweroff the Backup switch > > (BM0217040019), the current Master switch (BM0213317561) goes into linecard > > (sic!) > > mode! And I lose ssh access to it. I can undo the disaster only from the > > serial console. > > > If you only have 2 members Yes, I do. > in a virtual chassis you could add: > > set virtual-chassis no-split-detection > > This will ensure that if both VC ports go down, the master routing engine > carries on working. Are you referring to "Scenario B" in https://kb.juniper.net/InfoCenter/index?page=content=KB13879 ? or a different case? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
If you only have 2 members in a virtual chassis you could add: set virtual-chassis no-split-detection This will ensure that if both VC ports go down, the master routing engine carries on working. Catalin Dominte | Senior Network Consultant Nocsult Ltd | 11 Castle Hill | Maidenhead | Berkshire | SL6 4AA | Phone: +44 (0)1628 302 007 VAT registration number: GB 180957674 | Company registration number: 08886349 P Please consider the environment - Do you really need to print this email? THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the email and its attachments from all computers. On 25 Jul 2018, 08:27 +0100, Victor Sudakov , wrote: > Dear Colleagues, > > I've encountered an odd problem with adding EX4200s (running 12.3R6.6) > to Virtual Chassis with a nonprovisioned configuration file. > > According to documentation, I zeroize the second switch, power it off, > connect to the running switch and power it on. Some magic happens, and > voila: > > > show virtual-chassis > > Virtual Chassis ID: 915f.3bb3.ff60 > Virtual Chassis Mode: Enabled > Mstr Mixed Neighbor List > Member ID Status Serial No Model prio Role Mode ID Interface > 0 (FPC 0) Prsnt BM0213317561 ex4200-24t 128 Master* N 1 vcp-0 > 1 (FPC 1) Prsnt BM0217040019 ex4200-24t 128 Backup N 0 vcp-0 > > Member ID for next new member: 2 (FPC 2) > > Looks fine, doesn't it? However, if I later poweroff the Backup switch > (BM0217040019), the current Master switch (BM0213317561) goes into linecard > (sic!) > mode! And I lose ssh access to it. I can undo the disaster only from the > serial console. > > What am I doing wrong? Or if it's a bug, is there a workaround? > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > AS43859 > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Dear Colleagues, I've encountered an odd problem with adding EX4200s (running 12.3R6.6) to Virtual Chassis with a nonprovisioned configuration file. According to documentation, I zeroize the second switch, power it off, connect to the running switch and power it on. Some magic happens, and voila: > show virtual-chassis Virtual Chassis ID: 915f.3bb3.ff60 Virtual Chassis Mode: Enabled Mstr Mixed Neighbor List Member ID Status Serial NoModel prio Role Mode ID Interface 0 (FPC 0) PrsntBM0213317561 ex4200-24t 128 Master* N 1 vcp-0 1 (FPC 1) PrsntBM0217040019 ex4200-24t 128 Backup N 0 vcp-0 Member ID for next new member: 2 (FPC 2) Looks fine, doesn't it? However, if I later poweroff the Backup switch (BM0217040019), the current Master switch (BM0213317561) goes into linecard (sic!) mode! And I lose ssh access to it. I can undo the disaster only from the serial console. What am I doing wrong? Or if it's a bug, is there a workaround? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis
Doug McIntyre wrote: > On Mon, Nov 27, 2017 at 08:57:07AM +0700, Victor Sudakov wrote: > > We are planning to add backup switches in a Virtual Chassis > > configuration to our existing EX4200s. > ... > > If I have a standalone EX4200, should I power it off before plugging > > in the Virtual Chassis Cable for the first time, and connecting > > another (powered off) EX4200? > > > > The links above say only that the desired master should be powered on > > first, but nothing is said about the possibility of hot plug > > connection. > > I don't know about "should", but I've never had a problem moving VC cabling > around, unplugging, plugging. The cables aren't "smart" (AFAIK), so its not > like the box can detect if a VC cable gets attached, only if there is > something > on the other end. > > I would expect changing from standalone to virtual chassis would be a > service affecting change though, so be prepared to stop passing traffic if > this isn't done in a maint window. Encouraged by your reply, I hot-plugged the cable and another switch (in a lab environment) and all went well. The cable is indeed not smart, there was nothing in /var/log/messages when I attached the cable and the powered off switch. When I powered the second switch on, a new configuration was generated automagically (with new interfaces alongside the old ones) and the VC started working as a single unit. I was also pleasantly surprised by the fact that the RS232 management console follows the master chassis no matter which is the current master (so you don't have to disconnect and reconnect it). Don't know how they do it but I love Juniper! -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis
On Mon, Nov 27, 2017 at 08:57:07AM +0700, Victor Sudakov wrote: > We are planning to add backup switches in a Virtual Chassis > configuration to our existing EX4200s. ... > If I have a standalone EX4200, should I power it off before plugging > in the Virtual Chassis Cable for the first time, and connecting > another (powered off) EX4200? > > The links above say only that the desired master should be powered on > first, but nothing is said about the possibility of hot plug > connection. I don't know about "should", but I've never had a problem moving VC cabling around, unplugging, plugging. The cables aren't "smart" (AFAIK), so its not like the box can detect if a VC cable gets attached, only if there is something on the other end. I would expect changing from standalone to virtual chassis would be a service affecting change though, so be prepared to stop passing traffic if this isn't done in a maint window. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 virtual chassis
Dear Colleagues, We are planning to add backup switches in a Virtual Chassis configuration to our existing EX4200s. I have read https://www.juniper.net/documentation/en_US/junos/topics/concept/virtual-chassis-ex4200-components.html and https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/virtual-chassis-ex4200-cli.html so the configuration is more or less clear to me. There is one question left however. If I have a standalone EX4200, should I power it off before plugging in the Virtual Chassis Cable for the first time, and connecting another (powered off) EX4200? The links above say only that the desired master should be powered on first, but nothing is said about the possibility of hot plug connection. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 Virtual chassis
Hi Experts, If i have a single EX4200 switch and i want to add a new EX4200 switch to it using Virtual chassis capability. i want to let the old switch as a master and the new one as backup. i will keep new switch OFF. on the old switch : set member 0 mastership-priority 255 set member 1 mastership-priority 255 reload new switch. shall i need to reboot also the old switch ? did i forget something to create the Virtual Chassis ? *Kind regards,* *Rachid DHOU* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual chassis
It should work (tm), but generally I believe it is best practice to create
a VC on two unused switches but in your case if you have one in production
you may not have options. You could confirm with JTAC to get the best
official answer.
As mentioned in several other threads you should also disable split
detection if the VC has only two chassis.
http://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/no-split-detection-edit-virtual-chassis.html
virtual-chassis {
no-split-detection;
member 0 {
mastership-priority 255;
}
member 1 {
mastership-priority 255;
}
}
Aslo if you are making use of the out of band management juniper recommends
to make use of vme
http://kb.juniper.net/InfoCenter/index?page=contentid=KB11044
Regards,
Darius
On Tue, Nov 13, 2012 at 4:26 PM, Rachid DHOU rachid.d...@gmail.com wrote:
Hi Experts,
If i have a single EX4200 switch and i want to add a new EX4200 switch to
it using Virtual chassis capability.
i want to let the old switch as a master and the new one as backup.
i will keep new switch OFF.
on the old switch :
set member 0 mastership-priority 255
set member 1 mastership-priority 255
reload new switch.
shall i need to reboot also the old switch ?
did i forget something to create the Virtual Chassis ?
*Kind regards,*
*Rachid DHOU*
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual chassis
You can use the following too: set virtual-chassis preprovisioned set virtual-chassis no-split-detection set virtual-chassis member 0 role routing-engine set virtual-chassis member 0 serial-number [SERIAL-1] set virtual-chassis member 1 role routing-engine set virtual-chassis member 1 serial-number [SERIAL-2] set chassis redundancy graceful-switchover set ethernet-switching-options nonstop-bridging set routing-options nonstop-routing set system commit synchronize On Tue, Nov 13, 2012 at 1:26 PM, Rachid DHOU rachid.d...@gmail.com wrote: Hi Experts, If i have a single EX4200 switch and i want to add a new EX4200 switch to it using Virtual chassis capability. i want to let the old switch as a master and the new one as backup. i will keep new switch OFF. on the old switch : set member 0 mastership-priority 255 set member 1 mastership-priority 255 reload new switch. shall i need to reboot also the old switch ? did i forget something to create the Virtual Chassis ? *Kind regards,* *Rachid DHOU* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual chassis
Yeah this should work, put this config on the current switch, load the new switch on factory-default(if you have done any changes), connect the vc cables and boot up the new switch Regards Abdullah Baheer On Nov 13, 2012, at 7:39 PM, Giuliano Medalha giuli...@wztech.com.br wrote: You can use the following too: set virtual-chassis preprovisioned set virtual-chassis no-split-detection set virtual-chassis member 0 role routing-engine set virtual-chassis member 0 serial-number [SERIAL-1] set virtual-chassis member 1 role routing-engine set virtual-chassis member 1 serial-number [SERIAL-2] set chassis redundancy graceful-switchover set ethernet-switching-options nonstop-bridging set routing-options nonstop-routing set system commit synchronize On Tue, Nov 13, 2012 at 1:26 PM, Rachid DHOU rachid.d...@gmail.com wrote: Hi Experts, If i have a single EX4200 switch and i want to add a new EX4200 switch to it using Virtual chassis capability. i want to let the old switch as a master and the new one as backup. i will keep new switch OFF. on the old switch : set member 0 mastership-priority 255 set member 1 mastership-priority 255 reload new switch. shall i need to reboot also the old switch ? did i forget something to create the Virtual Chassis ? *Kind regards,* *Rachid DHOU* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual chassis ??
* Rachid DHOU We have two EX4200 switches, mainly used for L2 functionalities. We want to add two new EX4200 Switches and we want to connect them with the old switches. i have two possibilities : * Either, interconnect them and control everything with STP. * or use Virtual chassis. Please advise, what is the best way ? did you try Virtual chassis in EX ? Do you have other options ? We have several VCs from both EX4200s and EX4500s (no mixed VCs though), and disregarding some troubles with the former when the EX product line was brand spanking new several years ago, they've been rock solid and I wouldn't hesitate to recommend it over a traditional approach with STP. You'll get one management interface, and you can build a loop-free redundant network without STP wasting your bandwidth on blocked ports. The core switch in one of our data centres is a two-node EX4500 VC with LAGs to each downstream switch/device and upstream routers. The LAGs has at least one member from each physical node in the VC, so it's all fully redundant and I'm very happy with the setup. The largest downside with it is that upgrading JUNOS, you will have a 30-60 sec downtime on the LACP and OSPF adjacencies, due to the fact that a VC will not form if the member nodes have different JUNOS versions. So after first having upgraded the line-card node, when rebooting the routing-engine node, the upgraded line-card must start everything from scratch when assuming the routing-engine role. This is about to improve though, as I hear JUNOS 12.1 has gained support for NSSU. Haven't tried it myself though, so I don't know if it's mature enough to be trusted quite yet. (Interested in hearing about any experiences though.) BTW: Make sure to enable no-split-detection in your VC, or your two EX4200s will be mutually dependent and you'll have no HA. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 Virtual chassis ??
Dear experts, We have two EX4200 switches, mainly used for L2 functionalities. We want to add two new EX4200 Switches and we want to connect them with the old switches. i have two possibilities : * Either, interconnect them and control everything with STP. * or use Virtual chassis. Please advise, what is the best way ? did you try Virtual chassis in EX ? Do you have other options ? *Kind regards,* *Rachid DHOU* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual chassis ??
I'd strongly suggest using virtual chassis (as long as your somewhat current on your Junos version). Virtual Chassis is now a mature technology, and it's much easier to administer than the STP route, (faster, better, stronger) Patrick -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Rachid DHOU Sent: Wednesday, August 22, 2012 11:48 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX4200 Virtual chassis ?? Dear experts, We have two EX4200 switches, mainly used for L2 functionalities. We want to add two new EX4200 Switches and we want to connect them with the old switches. i have two possibilities : * Either, interconnect them and control everything with STP. * or use Virtual chassis. Please advise, what is the best way ? did you try Virtual chassis in EX ? Do you have other options ? *Kind regards,* *Rachid DHOU* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual chassis ??
I would also suggest virtual chassis option ... Here is the best practices guide for VC .. http://www.juniper.net/us/en/local/pdf/implementation-guides/8010018-en.pdf On Wed, Aug 22, 2012 at 11:18 PM, Rachid DHOU rachid.d...@gmail.com wrote: Dear experts, We have two EX4200 switches, mainly used for L2 functionalities. We want to add two new EX4200 Switches and we want to connect them with the old switches. i have two possibilities : * Either, interconnect them and control everything with STP. * or use Virtual chassis. Please advise, what is the best way ? did you try Virtual chassis in EX ? Do you have other options ? *Kind regards,* *Rachid DHOU* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
I don't believe an EX VC fiber port will work in James' provider-offered VPLS scenario for the reason that VPLS uses MAC learning to operation, and I believe the VC-ports on the EX assume a directly connected VC port from a neighboring EX. However, if the provider was offering him a pseudo wire service (Martini VPN, circuit cross connect), those might pass all the EX-EX frames. That said, I previously had a 7-member EX VC across a DWDM network that worked fine for about 18 months (later replaced with in-house VPLS). The longest EX-EX span was 50km (~3ms r/t). Each EX's fiber VCP port was plugged into a client port on our optical gear so the EX's were just using SR optics. It had its limitations, though: * This was on 10.1. No ISSU available, so couldn't set a high SLA * No SNMP polling was available then of the fiber VC ports. If you had issues with dirty fiber or weak signal, you'd have to find out via the CLI (which happened to us on a different, more local implementation over single mode). * Not being able to follow a route or a mac address-table to see which inter-city link was being used to reach a particular destination Members of the EX team were happy to hear about our setup (and that it worked); the MX team cringed. Paul Z On 6/24/12 10:23 PM, Sascha Luck li...@c4inet.net wrote: On Sun, Jun 24, 2012 at 09:47:22PM -0700, Doug Hanks wrote: The MX implementation of VCCP uses standard 802.1Q with a vlan-id of 4094. I'm sure the EX is the same as well. The maximum latency is 100ms. I don't know about the MX but this whitepaper: http://www.juniper.net/us/en/local/pdf/implementation-guides/8010045-en.pd f says that EX VC uses non-standard MAC framing. It's the only bit of documentation that mentiones that, though ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
On Mon, Jun 25, 2012 at 06:23:36AM +, Paul Zugnoni wrote: It had its limitations, though: * This was on 10.1. No ISSU available, so couldn't set a high SLA * No SNMP polling was available then of the fiber VC ports. If you had issues with dirty fiber or weak signal, you'd have to find out via the CLI (which happened to us on a different, more local implementation over single mode). * Not being able to follow a route or a mac address-table to see which inter-city link was being used to reach a particular destination You can use this command to see the route a frame takes: ex show virtual-chassis vc-path source-interface ge-a/b/c destination-interface ge-x/y/z ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
Awesome! Thanks Chuck On 6/25/12 9:13 AM, Chuck Anderson c...@wpi.edu wrote: On Mon, Jun 25, 2012 at 06:23:36AM +, Paul Zugnoni wrote: It had its limitations, though: * This was on 10.1. No ISSU available, so couldn't set a high SLA * No SNMP polling was available then of the fiber VC ports. If you had issues with dirty fiber or weak signal, you'd have to find out via the CLI (which happened to us on a different, more local implementation over single mode). * Not being able to follow a route or a mac address-table to see which inter-city link was being used to reach a particular destination You can use this command to see the route a frame takes: ex show virtual-chassis vc-path source-interface ge-a/b/c destination-interface ge-x/y/z ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
Hi All, I am curious with a EX4200 as to the requirements of the uplink ports when attempting to use VCT / VCCP. Juniper documentation says a 1000BaseTX SFP module is unable to be used however I have been told that this does in fact work and the documentation may not have caught up yet? I am also curious as to the requirements of the fibre uplink ports. If we are purchasing carrier services does it have to be a dark fibre link or are we able to use VCT over a Carrier VPLS 1G Ethernet service (LX/LH/SX)? We are hoping to VCT a number of chassis over a 30km distance. Any advice or field experience would be appreciated! I have searched the documentation but to no avail. James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
James, On Sun, Jun 24, 2012 at 08:43:22PM +1000, James Jimenez wrote: I am curious with a EX4200 as to the requirements of the uplink ports when attempting to use VCT / VCCP. Juniper documentation says a 1000BaseTX SFP module is unable to be used however I have been told that this does in fact work and the documentation may not have caught up yet? the information I have is that the extended VC links must be optical. . I am also curious as to the requirements of the fibre uplink ports. If we are purchasing carrier services does it have to be a dark fibre link or are we able to use VCT over a Carrier VPLS 1G Ethernet service (LX/LH/SX)? We are hoping to VCT a number of chassis over a 30km distance. AFAIK, VCCP uses non-standard Ethernet frames and there must not be any L2 (and up) devices in the VC link path as these devices would drop the VCCP frames. rgds, Sascha Luck ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
On 6/24/12 09:20 , Sascha Luck wrote: James, On Sun, Jun 24, 2012 at 08:43:22PM +1000, James Jimenez wrote: I am curious with a EX4200 as to the requirements of the uplink ports when attempting to use VCT / VCCP. Juniper documentation says a 1000BaseTX SFP module is unable to be used however I have been told that this does in fact work and the documentation may not have caught up yet? the information I have is that the extended VC links must be optical. . I am also curious as to the requirements of the fibre uplink ports. If we are purchasing carrier services does it have to be a dark fibre link or are we able to use VCT over a Carrier VPLS 1G Ethernet service (LX/LH/SX)? We are hoping to VCT a number of chassis over a 30km distance. extending the control-plane of an ethernet switch over tens of kilometers is a imho a seriously bad idea. AFAIK, VCCP uses non-standard Ethernet frames and there must not be any L2 (and up) devices in the VC link path as these devices would drop the VCCP frames. rgds, Sascha Luck ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
On Sun, Jun 24, 2012 at 10:37:22AM -0700, Joel jaeggli wrote: extending the control-plane of an ethernet switch over tens of kilometers is a imho a seriously bad idea. Why, actually? Latency issues? rgds, Sascha ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
On 6/24/12 11:11 AM, Sascha Luck wrote: On Sun, Jun 24, 2012 at 10:37:22AM -0700, Joel jaeggli wrote: extending the control-plane of an ethernet switch over tens of kilometers is a imho a seriously bad idea. Why, actually? Latency issues? Latency is a consideration given your control-plane is not distributed. What happens when it gets partitioned is a bigger issue. That is a problem when they're all in the same rack and there's a ring of stacking cables, it's a bigger problem at considerable remove. finally while your mtbf is about the same for 8 seperate switches vs 8 in a stack the impact on overall availability due to stack failure is much greater. rgds, Sascha ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
The MX implementation of VCCP uses standard 802.1Q with a vlan-id of 4094. I'm sure the EX is the same as well. The maximum latency is 100ms. Although I agree having a virtual chassis span a WAN isn't the best idea ever. Thank you, -- Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875 Sr. Systems Engineer Juniper Networks On 6/24/12 9:20 AM, Sascha Luck li...@c4inet.net wrote: James, On Sun, Jun 24, 2012 at 08:43:22PM +1000, James Jimenez wrote: I am curious with a EX4200 as to the requirements of the uplink ports when attempting to use VCT / VCCP. Juniper documentation says a 1000BaseTX SFP module is unable to be used however I have been told that this does in fact work and the documentation may not have caught up yet? the information I have is that the extended VC links must be optical. . I am also curious as to the requirements of the fibre uplink ports. If we are purchasing carrier services does it have to be a dark fibre link or are we able to use VCT over a Carrier VPLS 1G Ethernet service (LX/LH/SX)? We are hoping to VCT a number of chassis over a 30km distance. AFAIK, VCCP uses non-standard Ethernet frames and there must not be any L2 (and up) devices in the VC link path as these devices would drop the VCCP frames. rgds, Sascha Luck ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
On Sun, Jun 24, 2012 at 09:47:22PM -0700, Doug Hanks wrote: The MX implementation of VCCP uses standard 802.1Q with a vlan-id of 4094. I'm sure the EX is the same as well. The maximum latency is 100ms. I don't know about the MX but this whitepaper: http://www.juniper.net/us/en/local/pdf/implementation-guides/8010045-en.pdf says that EX VC uses non-standard MAC framing. It's the only bit of documentation that mentiones that, though ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP
On Sun, Jun 24, 2012 at 01:47:43PM -0700, joel jaeggli wrote: Latency is a consideration given your control-plane is not distributed. What happens when it gets partitioned is a bigger issue. That is a problem when they're all in the same rack and there's a ring of stacking cables, it's a bigger problem at considerable remove. Partitioning is a problem, but I'd likely provision the remote switches in the line card role. If the WAN links get interrupted, you'll lose the remote bit but you would have anyway. (I actually have a requirement for this setup, but at least it is in the same city...) finally while your mtbf is about the same for 8 seperate switches vs 8 in a stack the impact on overall availability due to stack failure is much greater. Only if the entire stack fails - this should not be the case in an EX VC setup - I've had single switches fail but the rest of the stack kept pushing traffic. rgds, Sascha ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 virtual-chassis and vme access
On Thu, Aug 05, 2010 at 03:47:55AM +0200, Malte von dem Hagen wrote: * That's an explanation based on the effects. I don't know for sure what happens under the hood. It must be a bit different - according to our SE, it's possible to have both configs. After setting up vme management through JUNOS, drop to a shell and assign an IP to the interface via ifconfig. I haven't tested it, but he claims it works. You can't save it, so it has to be done on each boot. Any changes to the me0 interface probably blow it away. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ex4200 virtual-chassis and vme access
hi all: i had access via vme interface for two chained ex4200. but the vme ip address is no longer working after i configured two ip addresses on interface of me0 under stanzas groups member0 and groups member1. right now i can access each member of this virtual-chassis separately but not via vme address. are those two methods mutually exclusive? thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 virtual-chassis and vme access
Yes, those are mutually exclusive. When the vme interface is used it functions as a Layer 3 VLAN interface and the various me0 interfaces are Layer 2 switch ports. The vme and all me0 ports are associated with the mgmt VLAN. I'd recommend removing the groups config and stick with the vme approach. You can always jump between the individual switch participating in the VC using the 'request session member' command. HTHs. Jared --- On Wed, 8/4/10, snort bsd snort...@yahoo.com.au wrote: From: snort bsd snort...@yahoo.com.au Subject: [j-nsp] ex4200 virtual-chassis and vme access To: juniper-nsp juniper-nsp@puck.nether.net Date: Wednesday, August 4, 2010, 3:27 PM hi all: i had access via vme interface for two chained ex4200. but the vme ip address is no longer working after i configured two ip addresses on interface of me0 under stanzas groups member0 and groups member1. right now i can access each member of this virtual-chassis separately but not via vme address. are those two methods mutually exclusive? thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ex4200 virtual-chassis and vme access
Hi, Am 04.08.10 23:27, schrieb snort bsd: i had access via vme interface for two chained ex4200. but the vme ip address is no longer working after i configured two ip addresses on interface of me0 under stanzas groups member0 and groups member1. right now i can access each member of this virtual-chassis separately but not via vme address. are those two methods mutually exclusive? yes, they are. If you want to access me0 separately from the vme, you have to use the no-management-vlan-keyword and configure separate ip addresses via shell and ifconfig. See the Complete Software Guide and search for the keyword. Technically*, vme puts all me0 into a kind of family ethernet-switching-mode, assigns an internal management VLAN and sets up a vlan interface family inet with the configured ip address. If you configure both vme and me0, inet mode and ethernet-switching mode collide. Regards, Malte * That's an explanation based on the effects. I don't know for sure what happens under the hood. -- Malte von dem Hagen Teamleitung Network Engineering Operation Abteilung Technik --- Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678 Geschäftsführer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ex4200 virtual chassis
Participants, My company is thinking of deploying a 10 switch ex4200 virtual chassis. If anyone has done testing on this product with regards to graceful routing failover and the like, could you please contact me off list? Also anyone who has a virtual chassis in a production environment would be extremely helpful. Thank you, Cord ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
