Re: [j-nsp] SRX Is 12.3X48 already mature?
Hi Christian, Exactly, ISSU aborts just after checking conformity of the configuration with the targeted OS version. JTAC was unable to give us an rational explanation about this. Best regards. 2016-01-26 8:38 GMT+01:00 Christian Beyerlein < christian.beyerlein+juniper-...@net-m.de>: > Thx Youssef for your info, > > I have checked your mentioned PR (its PR1121888), and we should be safe > here as we use IC-LSYS with only one lt interface in the other LSYS. > > You say "ISSU wouldn't go through", this means it aborts before actually > performing the upgrade? Safety net working? > > BR > Christian > > > On 25.01.2016 18:35, Youssef Bengelloun-Zahr wrote: > >> Hi, >> >> Just upgraded an SRX5600 HA cluster from 12.1X46-D20 to 12.3X48-20 >> without any problem... so far (3 weeks ;-). >> >> Only issue we encountered was with ISSU not accepting too much lt >> interfaces between multiple L-SYSs, there is a listed PR in junos >> 12.3X48 release notes. >> >> No matter what we tried (deleting some / all of the lt interfaces), >> ISSU wouldn't go through and quit everytime. JTAC recommenced we do that >> the old fashion way, we ended UP rebooting the cluster :-/ >> >> In the end, all seems to be working for now. We'll definitly give >> ISSU a try next time we upgrade. >> >> HTH. >> >> Y. >> >> >> >> Le 25 janv. 2016 à 17:19, Christian Beyerlein < >>> christian.beyerlein+juniper-...@net-m.de> a écrit : >>> >>> Hi! >>> >>> Does anyone already use 12.3X48 on datacenter SRX (SRX3600 HA)? >>> >>> We are currently on 12.1X44 and would like to skip 12.1X46 and 12.1X47, >>> but 12.3X48 is not yet "JTAC recommended". >>> >>> Any stability issues observed? Will ISSU work from 12.1X44? >>> >>> We use only basic features, FW/NAT and ALG for RTSP/SUNRPC, no IDP or >>> sth like that. >>> >>> BR >>> Christian >>> -- >>> Christian Beyerlein >>> Senior System Engineer >>> >>> net mobile AG >>> Fritz-Vomfelde-Str. 26-30 >>> DE 40547 Düsseldorf >>> >>> Tel. +49 (0) 211 97020-950 >>> >>> Registergericht: Amtsgericht Düsseldorf, HRB 48022 >>> Vorstand:Edgar Schnorpfeil (Vorsitzender), >>> Simone Wittstruck, >>> Imran Khan >>> >>> Vorsitzender des >>> Aufsichtsrates: Hiroyuki Sato >>> ___ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> >> > -- > Christian Beyerlein > Senior System Engineer > > net mobile AG > Fritz-Vomfelde-Str. 26-30 > DE 40547 Düsseldorf > > Tel. +49 (0) 211 97020-950 > > Registergericht: Amtsgericht Düsseldorf, HRB 48022 > Vorstand:Edgar Schnorpfeil (Vorsitzender), > Simone Wittstruck, > Imran Khan > > Vorsitzender des > Aufsichtsrates: Hiroyuki Sato > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Youssef BENGELLOUN-ZAHR ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Is 12.3X48 already mature?
Thx Youssef for your info, I have checked your mentioned PR (its PR1121888), and we should be safe here as we use IC-LSYS with only one lt interface in the other LSYS. You say "ISSU wouldn't go through", this means it aborts before actually performing the upgrade? Safety net working? BR Christian On 25.01.2016 18:35, Youssef Bengelloun-Zahr wrote: Hi, Just upgraded an SRX5600 HA cluster from 12.1X46-D20 to 12.3X48-20 without any problem... so far (3 weeks ;-). Only issue we encountered was with ISSU not accepting too much lt interfaces between multiple L-SYSs, there is a listed PR in junos 12.3X48 release notes. No matter what we tried (deleting some / all of the lt interfaces), ISSU wouldn't go through and quit everytime. JTAC recommenced we do that the old fashion way, we ended UP rebooting the cluster :-/ In the end, all seems to be working for now. We'll definitly give ISSU a try next time we upgrade. HTH. Y. Le 25 janv. 2016 à 17:19, Christian Beyerlein a écrit : Hi! Does anyone already use 12.3X48 on datacenter SRX (SRX3600 HA)? We are currently on 12.1X44 and would like to skip 12.1X46 and 12.1X47, but 12.3X48 is not yet "JTAC recommended". Any stability issues observed? Will ISSU work from 12.1X44? We use only basic features, FW/NAT and ALG for RTSP/SUNRPC, no IDP or sth like that. BR Christian -- Christian Beyerlein Senior System Engineer net mobile AG Fritz-Vomfelde-Str. 26-30 DE 40547 Düsseldorf Tel. +49 (0) 211 97020-950 Registergericht: Amtsgericht Düsseldorf, HRB 48022 Vorstand:Edgar Schnorpfeil (Vorsitzender), Simone Wittstruck, Imran Khan Vorsitzender des Aufsichtsrates: Hiroyuki Sato ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Christian Beyerlein Senior System Engineer net mobile AG Fritz-Vomfelde-Str. 26-30 DE 40547 Düsseldorf Tel. +49 (0) 211 97020-950 Registergericht: Amtsgericht Düsseldorf, HRB 48022 Vorstand:Edgar Schnorpfeil (Vorsitzender), Simone Wittstruck, Imran Khan Vorsitzender des Aufsichtsrates: Hiroyuki Sato ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX960 Power Options
I recommend 4 x 208V. The MX960 uses "power zones" in a 2+2 arrangement where half of the chassis is powered by 2 PEMs, and the other half of the chassis is powered by the other 2 PEMs. Make sure the 1st PEM for each zone is powered by the A feed, and the 2nd PEM for each zone is powered by the B feed. For dual-input PEMs, you should put both inputs of a single PEM on the same branch circuit, either A or B. I would use two PDUs to break out the two 208V/30AMP outlets to multiple C19's (plus any C13's you need), and then use C19/C20 cords. Each branch circuit PDU will have 4 C19/C20 cords connected (2 PEMs x 2 inputs per PEM). Alternatively you could use L6-20 PDU outlets/cords. On Mon, Jan 25, 2016 at 09:25:02PM -0600, Colton Conor wrote: > What are the options for powering a MX960 using AC power? The datacenter > provider is offering us power in the following options: > > 120V/20AMP A/B Power > 120V/30AMP A/B Power > 208V/30AMP A/B Power > > We are leaning towards using a MX960 with 4 AC power supplies and limited > cards installed. More than likely we will order the 208V/30AMP A/B Power > from the datacenter, but want to know if this will be enough? What does > Juniper recommend? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX960 Power Options
What are the options for powering a MX960 using AC power? The datacenter provider is offering us power in the following options: 120V/20AMP A/B Power 120V/30AMP A/B Power 208V/30AMP A/B Power We are leaning towards using a MX960 with 4 AC power supplies and limited cards installed. More than likely we will order the 208V/30AMP A/B Power from the datacenter, but want to know if this will be enough? What does Juniper recommend? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX: mixin family bridge and family inet
❦ 25 janvier 2016 13:33 -0500, Chuck Anderson :
> There are two ways to do bridge-domains and vlan trunks on MX. The
> old way uses separate units for each VLAN. The new way uses a single
> unit 0 with all vlans in a family bridge. Try doing it the "old" way,
> pre-"family bridge interface-mode trunk". I don't think you can mix
> the two ways.
>
> interfaces
> xe-2/0/2 {
> flexible-vlan-tagging;
> encapsulation flexible-ethernet-services;
> unit 100 {
> vlan-id 100;
> family inet {
> unnumbered-address lo0.1;
> }
> }
> unit 200 {
> encapsulation vlan-bridge;
> vlan-id 200;
> }
> unit 300 {
> encapsulation vlan-bridge;
> vlan-id 300;
> }
> }
> }
> bridge-domains {
> vlan-200 {
> domain-type bridge;
> vlan-id 200;
> routing-interface irb.2;
> interface xe-2/0/2.200;
> }
> vlan-300 {
> domain-type bridge;
> vlan-id 300;
> interface xe-2/0/2.300;
> }
> }
Hi Chuck!
Thanks for your help. When I tried this way previously, it seems that I
did miss the "encapsulation vlan-bridge" part. Adding it makes it work
as expected. I find it more flexible this way.
--
Let the machine do the dirty work.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX: mixin family bridge and family inet
On Mon, Jan 25, 2016 at 05:45:25PM +0100, Vincent Bernat wrote:
> ❦ 25 janvier 2016 11:03 -0500, "Tim St. Pierre"
> :
>
> > I'm pretty sure you have to add the interfaces to the bridge domains:
> >
> > vlan-200 {
> > domain-type bridge;
> > vlan-id 200;
> > routing-interface irb.2;
> > ++ interface xe-0/0/2.0;
> > }
> >
> > We use a similar setup on MX, and it works well.
>
> I had some difficulties with this setup. Initially, I think I did like
> you suggest, but it wasn't working as expected. Unfortunately, I don't
> remember the details. Maybe there was another problem. However, even
> without putting the interface in the bridge domain, the bridge part
> works fine (and as you can see in my other mail, the subinterface part
> works too).
>
> Thanks for your help!
There are two ways to do bridge-domains and vlan trunks on MX. The
old way uses separate units for each VLAN. The new way uses a single
unit 0 with all vlans in a family bridge. Try doing it the "old" way,
pre-"family bridge interface-mode trunk". I don't think you can mix
the two ways.
interfaces
xe-2/0/2 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 100 {
vlan-id 100;
family inet {
unnumbered-address lo0.1;
}
}
unit 200 {
encapsulation vlan-bridge;
vlan-id 200;
}
unit 300 {
encapsulation vlan-bridge;
vlan-id 300;
}
}
}
bridge-domains {
vlan-200 {
domain-type bridge;
vlan-id 200;
routing-interface irb.2;
interface xe-2/0/2.200;
}
vlan-300 {
domain-type bridge;
vlan-id 300;
interface xe-2/0/2.300;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Is 12.3X48 already mature?
Hi, Just upgraded an SRX5600 HA cluster from 12.1X46-D20 to 12.3X48-20 without any problem... so far (3 weeks ;-). Only issue we encountered was with ISSU not accepting too much lt interfaces between multiple L-SYSs, there is a listed PR in junos 12.3X48 release notes. No matter what we tried (deleting some / all of the lt interfaces), ISSU wouldn't go through and quit everytime. JTAC recommenced we do that the old fashion way, we ended UP rebooting the cluster :-/ In the end, all seems to be working for now. We'll definitly give ISSU a try next time we upgrade. HTH. Y. > Le 25 janv. 2016 à 17:19, Christian Beyerlein > a écrit : > > Hi! > > Does anyone already use 12.3X48 on datacenter SRX (SRX3600 HA)? > > We are currently on 12.1X44 and would like to skip 12.1X46 and 12.1X47, but > 12.3X48 is not yet "JTAC recommended". > > Any stability issues observed? Will ISSU work from 12.1X44? > > We use only basic features, FW/NAT and ALG for RTSP/SUNRPC, no IDP or sth > like that. > > BR > Christian > -- > Christian Beyerlein > Senior System Engineer > > net mobile AG > Fritz-Vomfelde-Str. 26-30 > DE 40547 Düsseldorf > > Tel. +49 (0) 211 97020-950 > > Registergericht: Amtsgericht Düsseldorf, HRB 48022 > Vorstand:Edgar Schnorpfeil (Vorsitzender), > Simone Wittstruck, > Imran Khan > > Vorsitzender des > Aufsichtsrates: Hiroyuki Sato > ___ > 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] MX: mixin family bridge and family inet
❦ 25 janvier 2016 11:03 -0500, "Tim St. Pierre" :
> I'm pretty sure you have to add the interfaces to the bridge domains:
>
> vlan-200 {
> domain-type bridge;
> vlan-id 200;
> routing-interface irb.2;
> ++ interface xe-0/0/2.0;
> }
>
> We use a similar setup on MX, and it works well.
I had some difficulties with this setup. Initially, I think I did like
you suggest, but it wasn't working as expected. Unfortunately, I don't
remember the details. Maybe there was another problem. However, even
without putting the interface in the bridge domain, the bridge part
works fine (and as you can see in my other mail, the subinterface part
works too).
Thanks for your help!
--
He draweth out the thread of his verbosity finer than the staple of his
argument.
-- William Shakespeare, "Love's Labour's Lost"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX Is 12.3X48 already mature?
Hi! Does anyone already use 12.3X48 on datacenter SRX (SRX3600 HA)? We are currently on 12.1X44 and would like to skip 12.1X46 and 12.1X47, but 12.3X48 is not yet "JTAC recommended". Any stability issues observed? Will ISSU work from 12.1X44? We use only basic features, FW/NAT and ALG for RTSP/SUNRPC, no IDP or sth like that. BR Christian -- Christian Beyerlein Senior System Engineer net mobile AG Fritz-Vomfelde-Str. 26-30 DE 40547 Düsseldorf Tel. +49 (0) 211 97020-950 Registergericht: Amtsgericht Düsseldorf, HRB 48022 Vorstand:Edgar Schnorpfeil (Vorsitzender), Simone Wittstruck, Imran Khan Vorsitzender des Aufsichtsrates: Hiroyuki Sato ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX: mixin family bridge and family inet
I'm pretty sure you have to add the interfaces to the bridge domains:
vlan-200 {
domain-type bridge;
vlan-id 200;
routing-interface irb.2;
++ interface xe-0/0/2.0;
}
We use a similar setup on MX, and it works well.
On 2016-01-25 10:34 AM, Vincent Bernat wrote:
Hey!
Currently, I am using an IRB interface on a MX104:
For example, on xe-2/0/2, I have:
#v+
vlan-tagging;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 200 300 ];
}
}
#v-
I have this bridge domain:
#v+
vlan-200 {
domain-type bridge;
vlan-id 200;
routing-interface irb.2;
}
#v-
And irb.2:
#v+
family inet {
address 172.22.254.225/28;
}
#v-
Now, I would like to be able to also use L3 subinterfaces on
xe-2/0/2. So, I added "flexible-vlan-tagging" (but I think this is
useless) and "encapsulation flexible-ethernet-services"
#v+
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge; /* Also tried without */
family bridge {
interface-mode trunk;
vlan-id-list [ 200 300 ];
}
}
unit 100 {
vlan-id 100;
family inet {
unnumbered-address lo0.1;
}
}
#v-
On xe-2/0/2.100, "monitor traffic interface xe-2/0/2.100" see no packets
(even while pinging) and the counters for this interface are staying to
0. I suppose everything is swallowed by the "family bridge". I can't use
an irb.X interface as it is not possible to use an unnumbered-address in
this case.
Googling a bit, I have been unable to see an example mixing a "family
bridge" with a subinterface. To my understanding,
"flexible-ethernet-services" should allow me to do that.
Any idea?
Thanks!
--
Tim St. Pierre
System Operator
Communicate Freely
www.communicatefreely.net
289-225-1220 x5101
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX: mixin family bridge and family inet
❦ 25 janvier 2016 16:34 +0100, Vincent Bernat :
> Now, I would like to be able to also use L3 subinterfaces on
> xe-2/0/2. So, I added "flexible-vlan-tagging" (but I think this is
> useless) and "encapsulation flexible-ethernet-services"
>
> #v+
> flexible-vlan-tagging;
> encapsulation flexible-ethernet-services;
> unit 0 {
> encapsulation vlan-bridge; /* Also tried without */
> family bridge {
> interface-mode trunk;
> vlan-id-list [ 200 300 ];
> }
> }
> unit 100 {
> vlan-id 100;
> family inet {
> unnumbered-address lo0.1;
> }
> }
> #v-
>
> On xe-2/0/2.100, "monitor traffic interface xe-2/0/2.100" see no packets
> (even while pinging) and the counters for this interface are staying to
> 0. I suppose everything is swallowed by the "family bridge". I can't use
> an irb.X interface as it is not possible to use an unnumbered-address in
> this case.
>
> Googling a bit, I have been unable to see an example mixing a "family
> bridge" with a subinterface. To my understanding,
> "flexible-ethernet-services" should allow me to do that.
Meantime, I have found the following example:
http://juniper-nsp.puck.nether.narkive.com/GCLqeuIa/j-nsp-juniper-mx-960-using-the-same-ge-port-as-l2-and-l3
So, it matches my configuration. Therefore, I have fiddled a bit around
to find what's wrong. I am using this kind of static route
#v+
static {
route X.X.255.247/32 {
qualified-next-hop xe-2/0/2.100 { /* BFD stuff */ };
qualified-next-hop xe-2/0/3.100 { /* BFD stuff */ };
no-readvertise;
}
}
#v-
If I remove either one of the qualified-next-hop, everything starts
working as expected. As soon as there are two qualified-next-hop, no
packets is transmitted on either interface.
Maybe I should ask JTAC for that? JunOS 13.3R8.7.
--
Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX: mixin family bridge and family inet
Hey!
Currently, I am using an IRB interface on a MX104:
For example, on xe-2/0/2, I have:
#v+
vlan-tagging;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 200 300 ];
}
}
#v-
I have this bridge domain:
#v+
vlan-200 {
domain-type bridge;
vlan-id 200;
routing-interface irb.2;
}
#v-
And irb.2:
#v+
family inet {
address 172.22.254.225/28;
}
#v-
Now, I would like to be able to also use L3 subinterfaces on
xe-2/0/2. So, I added "flexible-vlan-tagging" (but I think this is
useless) and "encapsulation flexible-ethernet-services"
#v+
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge; /* Also tried without */
family bridge {
interface-mode trunk;
vlan-id-list [ 200 300 ];
}
}
unit 100 {
vlan-id 100;
family inet {
unnumbered-address lo0.1;
}
}
#v-
On xe-2/0/2.100, "monitor traffic interface xe-2/0/2.100" see no packets
(even while pinging) and the counters for this interface are staying to
0. I suppose everything is swallowed by the "family bridge". I can't use
an irb.X interface as it is not possible to use an unnumbered-address in
this case.
Googling a bit, I have been unable to see an example mixing a "family
bridge" with a subinterface. To my understanding,
"flexible-ethernet-services" should allow me to do that.
Any idea?
Thanks!
--
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] HA Cluster Loopback Interface during failover
I have two SRX3600 connected as A-P HA cluster, and there is a loopback interface used for VPN termination and assigned to redundancy-group-1.Its working in the primary firewall, but when I failover to the second firewall and then failover again to the first firewall, the loopback interface stops responding to ping requests from internet and the VPN tunnels were down (although it was pingable from the peer gateway router).I got it working again after I powered-off the second firewall!! Is this a configuration related issue or maybe a software bug? RegardsMahmoud ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Bandwidth aware using BGP on ISP transit
Hello, I am working on it. This may be my next patent :-) Thx Alex On 25/01/2016 09:02, Nathan Ward wrote: Hi, It sounds like you’re quite positive that it works - perhaps you can provide some examples of when it’s worked in practice? -- Nathan Ward ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Bandwidth aware using BGP on ISP transit
Hello, Please see below inline marked with [AA]. Thx Alex On 25/01/2016 07:08, Nathan Ward wrote: Hi, On 25/01/2016, at 19:48, Alexander Arseniev wrote: On 24/01/2016 23:01, Nathan Ward wrote: This sort of works, except there’s a strong chance that the attacker only gets advertised poisoned paths, and you’d drop all traffic. Do You mean attacker's ASN is non-existent? Or attacker's src IP is from RFC 1918/6598 space? Or attacker's src.IP are spoofed? No. BGP typically[1] advertises only one route (and AS path) per prefix. Consider an attacker with two peers/transit providers. If both of those transit providers have selected a poisoned path (i.e. one with the attackers AS in the path) as the best path, then the attacker’s AS won’t accept any routes to your network. Tim mentioned that he has 10 transit providers, so there’s a good chance that 9 paths that he poisons will be selected over the 1 that he doesn’t, and then he’ll see no traffic from the attacker, especially if the link in question doesn’t already traffic from the remote AS - which one assumes is true, or this whole solution wouldn’t be needed. [AA]. Sorry, I don't get it. The Tim's prefixes announced out of attacked link does not change, the Tim's prefixes announced out of all OTHER link will have a longer AS_PATH. Why attacker's neighboring ASN select the new announce with longer AS_PATH over existing one? I expect that ALL ASNs on the way to attacker's source ASN will retain the old announce as best path. Yes, this will affect traffic from these ASNs along with attack traffic. But it also helps if attacker ASN has a 0/0 route pointing to the neighboring ASN which happened to be on the old best path to Tim's ASN. Thx Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
