Re: [j-nsp] RE-S-X6-64G & ISSU?
Depending on your arrangement with Juniper the price for a backup RE is negligible compared to the rest of the chassis (we got them for free several times). There's really no reason to leave a blank RE slot considering you have redundant SCBs. Luis On Tue, Nov 22, 2016 at 2:19 PM, Michael Hare wrote: > Agree with Mark, if you count loss of redundancy as a high priority issue > find the funds to purchase dual RE even on dual chassis designs. > > We made this engineering mistake; initially saved money with a single RE > design with dual PE MX104s. We've had some NAND corruption RE failures that > are undetectable until the fan gets hit. The MX104 recovery process requires > physical access (would love to be proven wrong). Some of these chassis are > distant and/or not convenient to access physically. We are walking back and > installing dual RE everywhere. > > -Michael > >> -Original Message- >> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of >> Mark Tinka >> Sent: Tuesday, November 22, 2016 12:00 AM >> To: Aaron ; 'Sebastian Becker' >> Cc: juniper-nsp@puck.nether.net; 'Clarke Morledge' >> Subject: Re: [j-nsp] RE-S-X6-64G & ISSU? >> >> >> >> On 14/Nov/16 17:04, Aaron wrote: >> >> > Have y'all ever thought through the benefits of having dual RE in one >> > chassis compared to 2 chassis with 1 RE in each ? >> > >> > Like if I'm thinking about getting a MX480 with dual RE... what about >> > instead, getting dual MX240 with 1 RE in each ? ...and possibly Virtual >> > Chassis'ing the dual MX240's as one virtual router >> > >> > Chassis diversity seems nice...then whatever would connect in that >> > location, >> > can be redundantly connected to both MX240's. >> >> Firstly, unless you're tight for space, I'd not spend money on an MX240. >> MX480 should be the bare minimum. Line cards are hungry for space. >> >> We used to run single control planes in core switches, and have 2 core >> switches per PoP. This was because those switches only handled Ethernet >> traffic, no IP/MPLS. >> >> I'd be hesitant to run any kind of routing device on a single control >> plane unless it was designed as such. Then again, control planes are not >> that much more expensive in current-generation core switches, so we are >> now kitting them fully out from that perspective as well. >> >> Mark. >> ___ >> 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] RE-S-X6-64G & ISSU?
Agree with Mark, if you count loss of redundancy as a high priority issue find the funds to purchase dual RE even on dual chassis designs. We made this engineering mistake; initially saved money with a single RE design with dual PE MX104s. We've had some NAND corruption RE failures that are undetectable until the fan gets hit. The MX104 recovery process requires physical access (would love to be proven wrong). Some of these chassis are distant and/or not convenient to access physically. We are walking back and installing dual RE everywhere. -Michael > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Mark Tinka > Sent: Tuesday, November 22, 2016 12:00 AM > To: Aaron ; 'Sebastian Becker' > Cc: juniper-nsp@puck.nether.net; 'Clarke Morledge' > Subject: Re: [j-nsp] RE-S-X6-64G & ISSU? > > > > On 14/Nov/16 17:04, Aaron wrote: > > > Have y'all ever thought through the benefits of having dual RE in one > > chassis compared to 2 chassis with 1 RE in each ? > > > > Like if I'm thinking about getting a MX480 with dual RE... what about > > instead, getting dual MX240 with 1 RE in each ? ...and possibly Virtual > > Chassis'ing the dual MX240's as one virtual router > > > > Chassis diversity seems nice...then whatever would connect in that location, > > can be redundantly connected to both MX240's. > > Firstly, unless you're tight for space, I'd not spend money on an MX240. > MX480 should be the bare minimum. Line cards are hungry for space. > > We used to run single control planes in core switches, and have 2 core > switches per PoP. This was because those switches only handled Ethernet > traffic, no IP/MPLS. > > I'd be hesitant to run any kind of routing device on a single control > plane unless it was designed as such. Then again, control planes are not > that much more expensive in current-generation core switches, so we are > now kitting them fully out from that perspective as well. > > Mark. > ___ > 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] EVPN -VXLAN in production
Yes I have two small pods setup using VXLAN/EVPN with IP Fabric. ( eBGP underlay/iBGP overlay ) D40 is the place to be on code and seems to have fixed most of the problems I had. Seems to work well now. Can get me off list for more details. On 22/11/2016, 15:02, "juniper-nsp on behalf of Amos Rosenboim" wrote: Hi Everybody, We are working on a new DC design for a relatively large deployment (start at 20 racks and grow to about 60). We are considering EVPN-VXLAN for extending L2 between rows (we failed convincing the server guys that they don’t need this). We are wondering if anyone has any experience with this technology in production yet ? Specifically with QFX5100 and with QFX10002. Thanks Amos ___ 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] firewall filter terminating action
Hi,
Yes, any non-terminating action - log, syslog, police, sample, count, etc -
has an implicit accept at the end.
On Tue, Nov 22, 2016 at 10:35 AM, Chen Jiang wrote:
> Hi! Experts
>
> Sorry for disturbing, I have a question but couldn't find the answer, could
> you pls shed some light on this?
>
> From the documents we know that Juniper firewall filter has 3 termination
> actions: accept, discard, and reject.
>
> but when we configured mirror and sample action, if we didn't include a
> "next-term", then the packets will not go through next term and just be
> forwarded, it seems there is a implicit "accept" after sample and mirror
> action. Is this expected behaviour?
>
> Below is our test example, the packets will not hit the policer in term
> "test-download" if we don't include a "next-term" in term "port-mirror"
> lab@r1#show firewall family inet
> filter csnet-filter-in {
> term port-mirror {
> then {
> sample;
> port-mirror-instance port-mirror-base-instance;
> }
> }
> term test-download {
> from {
> destination-address {
> 119.254.116.88/30;
> }
> }
> then {
> policer 1m;
> accept;
> }
> }
> term 3 {
> then {
> discard;
> }
> }
> }
> }
>
>
> --
> BR!
>
>
>
>James Chen
> ___
> 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] Questions about EX4550 switches
On 16/Nov/16 16:42, Valentini, Lucio wrote: > The 12.3R12 is recommended also for EX2200 and EX4200; always follow > Juniper´s recommendations! The table of recommended versions is available on > the website juniper.net > Ref.: > https://kb.juniper.net/InfoCenter/index?page=content&id=KB21476&actp=search Run Junos 12.3 on the EX4550. Junos 13.2 is weird - it's like as though it tries to turn the switch into part of their QFabric fabric. I tried it once, things were just weird. > > Juniper are a bit slow in responding on EX issues, but this forum has been > helpful to me so far. Good luck. The only thing I'd say to look out for this switch is the abysmally small buffers. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE-S-X6-64G & ISSU?
On 14/Nov/16 17:04, Aaron wrote: > Have y'all ever thought through the benefits of having dual RE in one > chassis compared to 2 chassis with 1 RE in each ? > > Like if I'm thinking about getting a MX480 with dual RE... what about > instead, getting dual MX240 with 1 RE in each ? ...and possibly Virtual > Chassis'ing the dual MX240's as one virtual router > > Chassis diversity seems nice...then whatever would connect in that location, > can be redundantly connected to both MX240's. Firstly, unless you're tight for space, I'd not spend money on an MX240. MX480 should be the bare minimum. Line cards are hungry for space. We used to run single control planes in core switches, and have 2 core switches per PoP. This was because those switches only handled Ethernet traffic, no IP/MPLS. I'd be hesitant to run any kind of routing device on a single control plane unless it was designed as such. Then again, control planes are not that much more expensive in current-generation core switches, so we are now kitting them fully out from that perspective as well. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] firewall filter terminating action
Hi! Experts
Sorry for disturbing, I have a question but couldn't find the answer, could
you pls shed some light on this?
>From the documents we know that Juniper firewall filter has 3 termination
actions: accept, discard, and reject.
but when we configured mirror and sample action, if we didn't include a
"next-term", then the packets will not go through next term and just be
forwarded, it seems there is a implicit "accept" after sample and mirror
action. Is this expected behaviour?
Below is our test example, the packets will not hit the policer in term
"test-download" if we don't include a "next-term" in term "port-mirror"
lab@r1#show firewall family inet
filter csnet-filter-in {
term port-mirror {
then {
sample;
port-mirror-instance port-mirror-base-instance;
}
}
term test-download {
from {
destination-address {
119.254.116.88/30;
}
}
then {
policer 1m;
accept;
}
}
term 3 {
then {
discard;
}
}
}
}
--
BR!
James Chen
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Questions about EX4550 switches
On 16/Nov/16 17:12, Doug McIntyre wrote: > > BUT, I know on this platform (EX4550), that certain interface cards require > newer code in the 13.2 series of code releases. So, make sure you check > out the requirements of all the modules installed in the switch. I know > the 40GB expansion module requires 13.2X of some version. I don't run > any expansion modules, and I run 12.3 releases on mine. We've been running expansion and VC modules on the EX4550 on 12.3. No issues. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] how to disconnect/kill tcp session from juniper router
I have an unauthorized telnet session attached to my router but it does not
show up under "show system users" and they have not successfully logged so
it doesn't seem that I can do the "request system logout.." thing
I do however so unsuccessful login attempts in syslog
How do I kill/disconnect this tcp session ?
me@j1> show system connections | grep ".23 "
tcp4 0 0 109.109.109.109.23
181.181.181.181.55436 ESTABLISHED
tcp4 0 0 *.23 *.*
LISTEN
tcp4 0 0 *.6023*.*
LISTEN
tcp4 0 0 *.6023*.*
LISTEN
udp4 0 0 128.0.0.1.123 *.*
udp4 0 0 *.123 *.*
udp4 0 0 *.6123*.*
udp4 0 0 *.6123*.*
{master:0}
me@j1> show system processes | grep "PID|telnet"
PID TT STAT TIME COMMAND
70193 ?? Is 0:00.00 telnetd
{master:0}
me@j1> start shell
% ps -awwux | grep telnet
root 70193 0.0 0.1 2128 1396 ?? Is1:34PM 0:00.00 telnetd
remote 70971 0.0 0.0 480 296 p5 R+3:19PM 0:00.00 grep telnet
%
- Aaron
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EVPN -VXLAN in production
Hi Everybody, We are working on a new DC design for a relatively large deployment (start at 20 racks and grow to about 60). We are considering EVPN-VXLAN for extending L2 between rows (we failed convincing the server guys that they don’t need this). We are wondering if anyone has any experience with this technology in production yet ? Specifically with QFX5100 and with QFX10002. Thanks Amos ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs
Check out Observium. I don't know about this specific MIB, but it correctly detects vlan memberships for me. On Dec 9, 2015 14:32, "Chuck Anderson" wrote: > Has anyone tried to use or implement polling of the Q-BRIDGE-MIB on > any Juniper products, using either commercial or open source NMS > software or custom in-house software? What has been your experience > of the Juniper support of those SNMP products to correctly report > Port/VLAN memberships and VLAN/MAC FDB information? > > Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a > working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB > (jnxExVlan). Because Q-BRIDGE-MIB refers only to internal VLAN > indexes, you need to use both MIBs to get Port/VLAN mappings including > the 802.1Q VLAN tag ID (jnxExVlanTag). This means custom software, or > an NMS vendor willing to implement the Juniper Enterprise MIBs. > > All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is > broken (doesn't follow RFC 4363 standard PortList definition, instead > storing port indexes as ASCII-encoded, comma separated values), > apparently for a very long time. So again, you need custom software > or an NMS vendor willing to implement the broken Juniper version of > Q-BRIDGE-MIB (along with detecting which implementation is needed on > any particular device). This hasn't been a problem for us and in fact > went unnoticed, because we never cared to poll VLAN information from > our MX routers, only EX switches. > > But now EX-series (and QFX-series) 13.x and newer with ELS have > dropped the Enterprise JUNIPER-VLAN-MIB (a good thing to not require > Enterprise MIBs to get the VLAN tag ID) and have adopted the broken > Q-BRIDGE-MIB that all the other Junos platforms have been using (a > very bad thing). I'm pushing to have Juniper fix this, but their > concern is that it may break SNMP software that has been assuming the > broken Q-BRIDGE-MIB implementation for all these years. > ___ > 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] EVPN -VXLAN in production
Hi Everybody, We are working on a new DC design for a relatively large deployment (start at 20 racks and grow to about 60). We are considering EVPN-VXLAN for extending L2 between rows (we failed convincing the server guys that they don’t need this). We are wondering if anyone has any experience with this technology in production yet ? Specifically with QFX5100 and with QFX10002. Thanks Amos ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Questions about EX4550 switches
On Tue, Nov 22, 2016 at 08:22:04AM +0200, Mark Tinka wrote: > On 16/Nov/16 17:12, Doug McIntyre wrote: > > BUT, I know on this platform (EX4550), that certain interface cards require > > newer code in the 13.2 series of code releases. So, make sure you check > > out the requirements of all the modules installed in the switch. I know > > the 40GB expansion module requires 13.2X of some version. I don't run > > any expansion modules, and I run 12.3 releases on mine. > > We've been running expansion and VC modules on the EX4550 on 12.3. No > issues. Juniper's docs say that the EX4550-EM-2QSFP dual 10G expansion module wasn't supported until JunOS 13.2X50-D10. https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/ex4550-hardware-overview.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
