Agreed, 12.3R12 is the way to go currently. I had upgraded a few of our sites to 15.1R5.5 (latest) and all day every day while that code was present,there were chassisd log messages. The VC would lose connection (not sure why) and Space would shoot us a DOWN notification. Few minutes later, chassis would once again recover. Rinse and repeat.
Downgraded one site this past friday back to 12.3R12.4 and nothing in logs, silent, works flawlessly. 15.1 is a POS right now. That's my .02.
Hello,
we have EX4550 standalone running 12.3, juniper is recommanded 15.1
is it possible to upgrade directly from 12.3 to 15.1 ? or we need intermediaire version.
Note that from juniper upgrade policies, we can upgrade directy from EEOL version to next two EEOL releases.
As my understanding we can upgrade from Junos 12.3 (that is EEOL release) to 14.1 (that is the next two EEOL release), even from 14.1 we need to go through 14.2 before reach 15.1
Do someone had been done already this upgrade, what is the exact path to follow.
Thanks for you support.
you can upgrade directly.
and pl do the validdate option > request system software add /var/tmp/<<image>> validate no-copy reboot
Hi M Suresh Reddy;
Thanks for you reply, did you already do this upgrade from 12.3 to 15.1 ?
Based on juniper upgrade policy it seems to be not advice to do this.
Can you confirm me if you did this or you know others did this.
thanks again for your support
Hi Sambill,
JTAC is recommendation to go sequence as you mentioned but you can do directly beofore valid verification commond during upgradation process.
Make sure do it in downtime window.
Hello;
Thanks for your reply.
Still continue to gather information before we planned it.
I will give you feedback once this is done.
Best regards,
Hi,
I agree that this isnt the idea situation, but im sure that it will also be a "real world" problem to be covered off.
I have set the ESI to be the same on all my links facing the L2 VLAN. Yet when I enable the vlan on my CE-to-CE back link I am getting a loop. I have storm control set very aggressively so its shutting down the port. But seems strange that the DF node isnt detecting that the source VTEP isnt matched against the ESI in the type 4 route.
going to open a JTAC case.
I have several questions in regards to setting the root bridge priority properly. We have a our corp HQ office that is running a ex4200VC at the core. We have 15 addition IDF switches in our building. My topology for each IDF is 2GB LACP fiber LAG's connecting all IDF switches from all floors in all buildings back to our core switch. All switches are Juniper either EX2200 or EX4200. No routers or firewalls between any of them. i noticed when looking at our switches that when i ran the command below on the core my root ID was not for the core switch.
root@MDF1-SW1-EB1F> show spanning-tree bridge
STP bridge parameters
Context ID : 0
Enabled protocol : RSTP
Root ID : 28672.b8:e9:37:04:5a:84
Root cost : 210000
Root port : ae5.0
Hello time : 2 seconds
Maximum age : 6 seconds
Forward delay : 4 seconds
Message age : 2
Number of topology changes : 10645
Time since last topology change : 592 seconds
Topology change initiator : ae5.0
Topology change last recvd. from : 84:18:88:a8:cb:83
Local parameters
Bridge ID : 32768.5c:5e:ab:66:a2:01
Extended system ID : 0
Internal instance ID : 0
upon further investigating it was determined that a sonos boost wireless extender on our network is acting as the root bridge. We have the sonos speakers and boost on our network for different design studios. currently i have about 20 speakers total spread throughout three buildngs. That number is going to grow some more here. We were having a slow speed issue in one area of our LAN. after months of troubleshooting, testing computers, network, network cabling, speakers, printing, phones, switches, it was deteremined that we had some significan signal loss with our 1gb fiber trunks. in that area we had 4 sonos speakers, but removed them during the troubleshooting phase. one thing we noticed when they were connecting using the ethernet wire was that you could only connect 2 speakers. if you tried to connect three it would cause the music to be glitchy and not work.
So i am trying to setup all of my switches to play nice with the sonos and vice versa to make the network work properly.
Since i have RSTP enabled based on the output above would i navigate to
#edit protocols rstp
[edit protocols rstp]#set bridge-priority 0
or would i do it a the STP protocol?
Juniper KB article
bridge-priority (Spanning Trees)
Syntax
bridge-priority priority;
Hierarchy Level
[edit protocols mstp],
[edit protocols mstp msti msti-id],
[edit protocols rstp],
[edit protocols stp],
[edit protocols vstp vlan vlan-id]
Release Information
Statement introduced in Junos OS Release 9.0 for EX Series switches.
Statement updated in Junos OS Release 9.4 for EX Series switches to add VSTP support.
Description
Configure the bridge priority. The bridge priority determines which bridge is elected as the root bridge. If two bridges have the same path cost to the root bridge, the bridge priority determines which bridge becomes the designated bridge for a LAN segment.
Default
32,768
Options
priority—Bridge priority. It can be set only in increments of 4096.
Range: 0 through 61,440
Default: 32,768
Required Privilege Level
routing—To view this statement in the configuration.
routing-control—To add this statement to the configuration.
so right now i have permanently disabled on 4 sonos play 1 speakers the wifi interface for each. I only want to use the wired connection. i came across this on the Sonos website in regards to STP and BPDU being discarded. How can make sure bpdu are being passed to allow the wired speakers to work properly without creating any sort of loops or network issues?
SONOS ZonePlayers use 802.1D Spanning Tree (STP) for loop prevention between wired ZonePlayers and the wireless SonosNet Mesh Network. The Spanning Tree running on ZonePlayers is compliant with IEEE 802.1D and can inter-operate with other IEEE 802.1D and IEEE 802.1w compliant devices. Note: IEEE 802.1w is an updated version of the Spanning Tree protocol called Rapid Spanning Tree. The two types of STP protocols are compatible and 802.1w should revert to inter-operate with 802.1D devices (such as Sonos). Therefore, 802.1w Ethernet switches will work with Sonos ZonePlayers.
SONOS ZonePlayers CAN be connected to Ethernet switches that do NOT support Spanning Tree as long as the Ethernet switches do not interfere with the STP BPDU packets transmitted between ZonePlayers. This is typically never the case and these switches pass the BPDU packets like any other packet.
If the Ethernet switches that Sonos ZonePlayers are wired to DOES support Spanning Tree, the Spanning Tree on those switches must be configured properly. Ethernet switches that support Spanning Tree typically have their STP settings disabled. This also typically means that these switches will block/discard the BPDUs coming from the ZonePlayers. When the ZonePlayers are not able to see BPDUs, they cannot detect there is a shared transmission medium between the Zones and this will typically result in loops in the network. The solution to allow the use of these switches with Sonos is to enable and configure the Spanning Tree on the Ethernet switches. The configuration settings on each switch are different and the appropriate documentation for those products should be consulted. Note: Some switches have a setting that is called Pass BPDUs or equivalent. This setting when present allows the BPDUs between the ZonePlayers to pass freely through the switch without actually enabling STP on the the switch. Typically, setting this function also works, but again please review the switches product documentation.
A good guideline for Ethernet switches is if the switch says it supports Spanning Tree, either 802.1D or 802.1w, then its configuration settings and user documentation should be examined before wiring multiple ZonePlayers to the switch. If the switch does not state it supports Spanning Tree, 802.1D, or 802.1w, it will probably work fine with Sonos.
SONOS ZonePlayers do NOT require a connection to the same Ethernet switch. Different ZonePlayers can be connected to different Ethernet switches which are in turn connected to each other. The only requirement is that Sonos ZonePlayers must be able to actively participate in 802.1D Spanning Tree and not have BPDU transmission blocked between them. There is no Sonos limitation that prevents wiring multiple ZonePlayers to multiple Ethernet switches.
IEEE 802.1D has a recommended bridge span limitation of 7 bridges. This means that the total number of connected bridges from one end of the network to the other should not exceed 7 bridges. This typically only comes into play when daisy chaining Sonos ZonePlayers together by wiring one ZonePlayer to the next. In this case, the guidelines is when daisy chaining ZonePlayers, do not exceed 7 ZonePlayers wired together. If wiring multiple ZonePlayer to a single Ethernet switch, typically the number of spans will only be 3 or 4 (I.e. much less than 7). Except in the daisy-chain configuration, this limit of 7 bridges/7 ZonePlayers, is rarely ever hit.
A number of comments have used the term router and switch interchangeably in regards to this topic. Sonos ZonePlayers in the same HouseHold MUST be connected to the same routed network. A Spanning Tree cannot span two or more routed networks. In addition all Sonos ZonePlayers and Controllers must be on the same routed IP network in order to properly communicate and function. Typically, two or more routed networks are not seen in the household environment except by accident (Example. A carrier provides a new router in a network that already had a router and the original router was not removed).
Hopefully this information has clarified a number of items and not added additional confusion.
Regards, Todd
here is the protocol config on my core switch. Believe the interface listed 0/0/15 was put there during testing on something else i wasn't apart of.
root@MDF1-SW1-EB1F# show protocols
igmp {
interface all;
}
pim {
dense-groups {
239.0.0.0/8;
}
interface all {
mode dense;
}
}
igmp-snooping {
vlan all {
interface ae9.0 {
multicast-router-interface;
}
interface ae5.0 {
multicast-router-interface;
}
interface ae7.0 {
multicast-router-interface;
}
interface ae8.0 {
multicast-router-interface;
}
interface ae3.0 {
multicast-router-interface;
}
interface ae6.0 {
multicast-router-interface;
}
interface ae2.0 {
multicast-router-interface;
}
interface ge-2/0/0.0 {
multicast-router-interface;
}
}
}
rstp {
interface ge-0/0/15.0 {
disable;
edge;
}
}
lldp {
interface all;
}
lldp-med {
interface all;
}
{master:0}[edit]
Hi all,
I have been doing some studying for Juniper exams and decided to check out the vQFX vm . I have set it up on KVM, as opposed to virtuabox. I understand it is not a supported configuration but for the last week it has been helpful for labbing up exercises. I have written a post here vQFX10k on KVM if anyone has some spare KVM cpu cycles and memory and wants to give it a bash.
Philip
hi gents,
did anyone try configuring a virtual chassis qfx5100 devices for sflow towards a junos space log collector?
heres my sampling rate .. any thoughts?
set protocols sflow polling-interval 20
set protocols sflow sample-rate ingress 2048
set protocols sflow sample-rate egress 2048
set protocols sflow collector 1.1.1.1 udp-port 5000
set protocols sflow collector 2.2.2.2 udp-port 5000
my junos space doesnt collect such sflows. im thinkin about some settings on the junos space.
thanks
Hi,
As im understanding the JSpace Log Collector is just for SRX only.
Thanks
Hi Folks,
The SFlow global configuration CLI would look something like this and the show commands to verify the same are below. I would suggest to direct the traffic to a unix box and take a tcpdump to isolate the behavior.
protocols {
sflow {
agent-id <ip-address>;
source-ip <ip-address>;
collector {
ip-address <ip address>;
udp-port <port number>;
} [4];
interfaces <interface-name> {
polling-interval <number>;
sample-rate {
egress <rate>;
ingress <rate>;
}
}
polling-interval <number>;
sample-rate {
egress <rate>;
ingress <rate>;
}
}
}
show sflow global configurations – displays the global default parameters.
root> show sflow
sFlow : Enabled
Sample rate egress : 1:500 Enabled
Sample rate ingress : 1:2000 Disabled
Sample limit : 300 packets/second
Polling interval : 20 seconds
Agent ID : a.b.c.d
Source IP address : x.y.z.q
The sample rate Ingress and egress and polling interval mentioned here are of
sampling/polling rate configured globally.
Sample limit is Adaptive sample rate which is not configurable.
show sflow interfaces – displays the interfaces on which sflow is enabled and the
sampling parameters on them.
root> show sflow interfaces
Interface Status Sample-rate Actual Polling-interval
Egress Ingress Egress Ingress Egress Ingress
Tor1:xe-1/0/0.0 Enabled Disabled 300 200 1200 1400 20 sec
Tor2:xe-1/0/1.0 Enabled Enabled 200 500 800 500 30 sec
Hello fellow Juniperians.
I bought an ex4600 with a standard 24sfp+ ports. This hardware also have 4*40Gbit qsfp. This ports are able to connect breakout cables.
My question is. Can those breakout cables have 10Gbit copper in it, or is it just fixed sfp+ fiber?
What alternatives do I have for copper in the ex4600 if the breakout cables doesnt work?
At this time, and going forward, the best place to find any information regarding optics and cable support for any Juniper product would be the Pathfinder Hardware Compatiabily Tool (HCT). The list of supported items for any product change so fast that trying to keep up via on-line documentation is too difficult. Use this tool always going forward, as any other documentation is very likely outdated.
So for EX4600 the link is: https://pathfinder.juniper.net/hct/product/#prd=EX4600
You will see two 4x10GE break-out cables listed - QSFPP-4X10GE-SR (listed under 10GE) and JNP-QSFP-4x10GE-LR. Both of these cable terminate with fiber connectors, NOT copper. I believe there may not be such a 40 to 4x10GE breakout cable for copper.
I do know that ProLabs does have some 10GE Copper options available. You can look at:
http://www.prolabs.com/newproduct/10gbase-t-sfp-copper-transceiver/
http://www.prolabs.com/products/optical-transceivers/juniper/SFP_Plus/EX-SFP-10GE-T-C/
These may help you and ProLabs (not Juniper) states these will work with various vendors, including Juniper. YMMV.
You may also be able to find 40GE to [single] 10GE SFP+ adapters out there - google search for these. The disadvantge of this approach is you only get 1x10GE per 40GE interface, and then you probably need to use a 10GE SFP+ Copper Optic if you want 10GE Copper. These adapters allow 10/40 operation, just as SFP+ allow 1/10 operation. I am not aware of any devices whose native 40GE also supports 10GE or any format.
As I have stated a few times before on this forum, your best approach is to work with your Juniper [value-add] partner or Juniper account team to find all your options.
Hope this may help and good luck.
Agree with @kronicklez. Junos Space or Log Collector/Director is not a Flow Collector. LC/LD is designed to collect logs and other information from an SRX to be used by Security Director (SD).
Juniper flow analyser solution is the Junos Secure Analytics (JSA) solution.
I also agree with what @phyton said as good next step.
Two things you can do if you enable DHCP Snooping and it will help. (not sure if both can be enabled at the same time)
#set ethernet-switching-options secure-access-port interface ge-0/0/2.0 dhcp-trusted (2 is the interface where the device with static IP is connected to)
Add specific static IP addresses to the DHCP snooping database.
#set ethernet-switching-options secure-access-port interface ge-0/0/2.0 static-ip 192.168.1.4 vlan <vlan_of-device> mac <mac_addresss_of_devices>
You can add multiple static entries to the same interface
Not only that - we found out, that the recommended for the EX2200-C is broken and leaving the switch to always show the red alert due to "can't find temperature-sensors" - even worse the Revision before, the EX2200-C shuts itself down as soon as it boots up because of "missing temp sensor" and issuing "fire shutdown"...
We went back to the 12tree and the issues disappeared.
Hi everyone,
I can't figure out how to do this.
We're expanding our network one of our sites, and have bought an additional 3 EX2200 switches to the existing 2 that's setup in a Virtual Chassis.
The plan is to have one of the switches on a new rack that will contain all the servers, and the other four act as access switches to the workstations. Now I just realized that the virtual chassis for ex2200 max out at 4 units, and I can't add the other switch on the server rack.
So instead, I'm planning to do LACP (802.3ad) on the rack switch, to the virtual chassis. But I want the link between the two to be a VLAN trunk, so I can still use the switch on the server rack on the same VLAN as the one in the VC. Please take note of the LACP interfaces are across different member switches (all port 46).
The thing is, I can't seem to set this up properly. Access switch ports 0/0/46 and 1/0/46 are LACPd to connect to the server switch 0/0/46 and 0/0/47 respectively. I connected access switch ports 0/0/1 (Server VLAN), and another on server swtich ports 0/0/1 (Server VLAN). I got the LACPs up and running, but switching for the workstations on the SERVER vlan won't talk to each other.
Config (redacted some parts) is as follows:
# JEX-SWITCH (Access switch Virtual Chassis)
chassis {
aggregated-devices {
ethernet {
device-count 5;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching {
vlan {
members PHASE-1;
}
}
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching {
vlan {
members SERVERS;
}
}
}
}
ge-0/0/46 {
ether-options {
802.3ad ae0;
}
}
ge-1/0/46 {
ether-options {
802.3ad ae0;
}
}
ae0 {
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ PHASE-1 SERVERS default ];
}
}
}
}
vlans {
unit 0 {
family inet {
address 10.0.0.2/24;
}
}
unit 21 {
family inet {
address 10.0.21.1/24;
}
}
unit 101 {
family inet {
address 10.0.101.1/24;
}
}
}
}
virtual-chassis {
preprovisioned;
member 0 ...
member 1 ...
member 3 ...
member 4 ...
}
vlans {
PHASE-1 {
vlan-id 21;
l3-interface vlan.21;
}
SERVERS {
vlan-id 101;
l3-interface vlan.101;
}
default {
vlan-id 0;
}
}
---------------------------------------------------------
# SERVER-SWITCH
chassis {
aggregated-devices {
ethernet {
device-count 5;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching {
vlan {
members PHASE-1;
}
}
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching {
vlan {
members SERVERS;
}
}
}
}
ge-0/0/46 {
ether-options {
802.3ad ae0;
}
}
ge-0/0/47 {
ether-options {
802.3ad ae0;
}
}
ae0 {
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ PHASE-1 SERVERS default ];
}
}
}
}
vlans {
unit 0 {
family inet {
address 10.0.0.3/24;
}
}
unit 101 {
family inet {
address 10.0.101.2/24;
}
}
}
}
vlans {
PHASE-1 {
vlan-id 21;
l3-interface vlan.21;
}
SERVERS {
vlan-id 101;
l3-interface vlan.101;
}
default {
vlan-id 0;
}
}
You need to add the interfaces on both the VC portion and standalone switch into AE0. See attached Day One book for EX Switches (older version but still good for this), page 29 Step 3.
This should make all work. Good luck.