Hi
Ex4300 is fine with license and as I said one of the two carriers is
working.
As far as I understood the carrier with problems is providing q-in-q
tunneling but I still have to get a confirmation on that.
@Chuck, wan macsec or macsec is not an ieee standard? Juniper doesn't have
any different
On Thu, Jul 26, 2018 at 05:24:53PM -0500, Doug McIntyre wrote:
> On Thu, Jul 26, 2018 at 05:35:42PM -0400, Chuck Anderson wrote:
> > Ask your Juniper rep for a feature that Cisco calls "WAN MACsec".
>
> Juniper calls it MACsec.
"WAN MACsec" is a slightly modified version that Cisco made in order
On Thu, Jul 26, 2018 at 05:35:42PM -0400, Chuck Anderson wrote:
> Ask your Juniper rep for a feature that Cisco calls "WAN MACsec".
Juniper calls it MACsec.
The OP probably needs to make sure the firmware is correct for his platform.
Ask your Juniper rep for a feature that Cisco calls "WAN MACsec".
On Thu, Jul 26, 2018 at 11:01:37PM +0200, james list wrote:
> Dear experts,
> I have a virtual chassis of ex4300 connected to another vc of ex4300 with 2
> x 1 Gbs links provided by two carriers.
>
> Lacp aggregation is up with
Hi,
does anybody use SRX550 or SRX550HM as BGP router with full IPv4/IPv6
routing table?
SRX550 is older model with 2GB RAM, running Junos 12.1, SRX550HM is
current model with 4GB RAM and 8GB CF card, running Junos15.1.
The datasheet
Dear experts,
I have a virtual chassis of ex4300 connected to another vc of ex4300 with 2
x 1 Gbs links provided by two carriers.
Lacp aggregation is up with just one carrier1 link encrypted with macsec,
unfortunately carrier2 is not going to find the problem and macsec packet
are not
--> 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
>
> ---
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
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
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
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
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.
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
13 matches
Mail list logo
