Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Known Behavior


This section lists known behavior, system maximums, and limitations in hardware and software in Junos OS Release 15.1R7 for the EX Series.

For the most complete and latest information about known Junos OS defects, use the Juniper Networks online Junos Problem Report Search application.

Authentication and Access Control

  • On EX4300 switches, a maximum of 5K supplicants is supported for dot1xd. PR962292

  • On EX9200 switches, if you configure a firewall filter such that the number of characters in the filter name, term name, and counter name added together exceeds 128 characters, 802.1X (dot1x) authentication might fail and cause the Network Processing Card (NPC) to crash. As a workaround, configure the filter name, term name, and counter name such that when the sum of the number of characters in those three names is added to the sum of the number of characters in the interface name and the MAC address, the total does not exceed 128. PR1083132

  • On EX9200 switches, 802.1X (dot1x) authentication might not be performed if a voice VLAN is changed or modified to a data VLAN after a client is authenticated in that voice VLAN. This problem occurs when a VoIP VLAN is configured, a client is authenticated in a configured data VLAN, and then the VoIP VLAN is configured as a new data VLAN (that is, you delete the VoIP configuration and delete the current data VLAN membership, and configure the original VoIP VLAN as the new data VLAN). PR1074668

  • On an EX4300 or a QFX5100 switch, a MAC address that is specified as part of a MAC-based VLAN is authenticated on an interface, for example, xe-1/1/1, on which 802.1X authentication in multiple supplicant mode is configured. However, the same MAC address might not be authenticated on another interface, for example, xe-2/1/1, if the MAC address moves to interface xe-2/1/1 from interface xe-1/1/1. PR1007589

High Availability (HA) and Resiliency

  • Keepalives might not exit an EX8200 Virtual Chassis; this is a race condition during an NSSU or a switchover. As a workaround, clear all ARP entries and OSPF/BGP neighbors. PR1302562


  • On EX Series switches, ARP reply packets might get dropped when the switch receives reverse-path forwarding (RPF) multicast failure packets at a high rate (for example, 300 pps). As a workaround, create a static ARP entry for the next-hop device. PR1007438

  • System logging (syslog) messages for EX9200-MPC line cards include error messages on FPC initialization. Initialization can be triggered by FPC restart, insertion and removal, or power off and on. The message is Error "kernel: GENCFG: op 32 (Resync blob) failed; err 7 (Doesn't Exist)". This has no functional impact. PR1171487

  • On EX3300 and EX4200 switches, DHCPv6 packets are duplicated with option18 configured (one packet with option 18 and one without option 18) when switches are configured with dhcpv6-option18 use-option82. This is an expected behavior. PR1184593

  • A MAC hash collision happens when 16K static sequential MAC is configured. If there is an FDB hash collision, an EX Series switch cannot learn the specific MAC address. Also, packet flooding occurs in the same VLAN when the EX Series switch receives a packet with that MAC address as the destination. The MAC hashing algorithm uses vlan-hw and MAC to compute the hash value, and the computation works better for random MACs. Increasing the mac-lookup-length value might improve the situation. Related KB: PR1303375

  • A MAC hash collision happens when a huge number of static sequential MACs are configured. If there is an FDB hash collision, an EX Series switch cannot learn the specific MAC address. Subsequently, an IGMP snooping entry is not added, leading to traffic loss. The MAC hashing algorithm uses vlan-hw and MAC to compute the hash value, and the computation works better for random MACs. Increasing the mac-lookup-length value might improve the situation. Related KB: PR1304652 , PR1312322

  • Issuing snmpwalk on the entire MIB tree on a 7-plus member EX3300, EX4200, EX4500, or EX4550 Virtual Chassis can result in the command timing out, and some SNMP subagent daemons such as rpd and rmopd might take more CPU. PR1304114

  • Performing configuration validation on an EX Series switch that does not run under Junos OS with Enhanced Layer 2 Software (ELS) can generate a low memory signal when sufficient free memory in RAM is not available in the switch. PR1307788

  • Fatal errors in the flash storage can trigger a kernel panic in soft-update processing. PR1311909

  • On EX4200 and EX4500 Virtual Chassis, a configuration change with 8K+ static routes might cause a commit failure as /var/rundb runs out of storage space. PR1312341

Interfaces and Chassis

  • Internal management Ethernet interfaces (em-) might fail autonegotiation after a reboot if one of the em- interfaces is in a link-down condition. PR829521

  • On an EX2200 Virtual Chassis with three members, if you configure nine link aggregation groups (LAGs) and eight interfaces per LAG bundle, the LACP links might move down and up continuously. As a workaround, configure eight link aggregation groups and eight interfaces per LAG bundle. PR1030809

  • On EX9200 switches configured with an MC-LAG, the Inter-Chassis Control Protocol (ICCP) might flap if you configure another interchassis link (ICL) that is on new multichassis aggregated Ethernet (MC-AE) interfaces. PR1046022

  • On EX9200 switches on which a MAC limit is configured with packet-action log, a packet drop might occur when interface-mac-limit is configured with mac-table-size on a specific VLAN or on a global VLAN hierarchy. PR1076546

  • On EX9200 switches, if you configure mac-move-limit with packet-action shutdown on a VLAN that includes an MC-AE interface and an access interface, the packet action is not performed if traffic hits the limit between the MC-AE interface and the access interface. PR1079383

  • On EX9200 switches, if you configure mac-move-limit with packet-action shutdown on a VLAN that includes two members of a multichassis link aggregation group (MC-LAG) AE interface, if traffic hits the limit between the two MC-AE interfaces, a peer link belonging to one of the MC-AE interfaces might go down and only 50 percent of the traffic might reach its destination. PR1079436

  • On EX9200 switches, unified in-service software upgrade (ISSU) might not work properly for an upgrade to Junos OS Release 15.1. As a workaround, manually upgrade the Routing Engine. PR1091610

  • On EX9200 switches, traffic loss of more than one second (two through six seconds) might occur on the active node of an MC-LAG when the Inter-Chassis Control Protocol (ICCP) goes down and comes back up. PR1107001

  • If an Inter-Chassis Control Protocol (ICCP) interface on an EX9200 switch in an MC-LAG Active-Active topology is disabled and then reenabled, traffic could be dropped for more than 2 seconds. PR1173923

  • In a scaled environment, configuring more than 96 LAG members in a single commit results in an sfid process hog and interface flaps. We recommend that you configure and commit LAG members gradually. PR1300533

  • As an MTU change is considered a catastrophic event in the dcd process, a DELETE followed by an ADD is sent for all vlan logical interfaces, interface families, and interface addresses whenever there is a change in the MTU on the vlan physical interface. The message error: interface vlan.2001 not foundis observed on issuing the show interfaces vlan.2001command because of a small window in which the logical-interface subtree is not present when the DELETE and ADD operations are performed for all of the logical-interface subtree under the vlan physical interface. In a scaled configuration, we recommend that you give some time for the system to stabilize in a case of a set or delete of MTU on the vlan physical interface before you check the status of any of the logical interfaces by using the show interfaces vlan.logical-interface-number command. PR1313883


  • In the J-Web interface, you cannot commit some of the configuration changes in the Port Configuration page or the VLAN Configuration page because of the following limitations for port-mirroring ports and port-mirroring VLANs:

    • A port configured as the output port for an analyzer cannot be a member of any VLAN other than the default VLAN.

    • A VLAN configured to receive analyzer output can be associated with only one interface.


  • In the J-Web interface, in the Port Security Configuration page, configuring the action option when you configure the MAC limit option is mandatory, even though configuring an action value is not mandatory in the CLI. PR434836

  • On EX4200 switches, in the J-Web interface, if you try to change the position of columns using the drag-and-drop method, only the column headers move to the new position instead of the entire column in the OSPF Global Settings table in the OSPF Configuration page, the Global Information table in the BGP Configuration page, and the Add Interface window in the LACP (Link Aggregation Control Protocol) Configuration page. PR465030

  • When a large number of static routes are configured and you have navigated to pages other than page 1 in the Route Information table in the Static Routing monitoring page in the J-Web interface (Monitor > Routing > Route Information), changing the Route Table to query other routes refreshes the page, but does not return to page 1. For example, if you run a query from page 3 and the new query returns very few results, the Results table continues to display page 3 and shows no results. To view the results, navigate to page 1 manually. PR476338

  • In the J-Web interface for EX4500 switches, the Port Configuration page (Configure > Interfaces > Ports), the Port Security Configuration page (Configure > Security > Port Security), and the Filters Configuration page (Configure > Security > Filters) display features that are not supported on EX4500 switches. PR525671

  • When you open a J-Web interface session using HTTPS, enter a username and a password, and then click the Login button, the J-Web interface takes 20 seconds longer to launch and load the Dashboard page than it does if you use HTTP. PR549934

  • If you access the J-Web interface by using an HTTPS connection through the Microsoft Internet Explorer Web browser, you might not be able to download and save reports from some pages on the Monitor, Maintain, and Troubleshoot tabs. Some affected pages are at these locations:

    • Maintain > Files > Log Files > Download

    • Maintain > Config Management > History

    • Maintain > Customer Support > Support Information > Generate Report

    • Troubleshoot > Troubleshoot Port > Generate Report

    • Monitor > Events and Alarms > View Events > Generate Report

    • Monitor > Routing > Route Information > Generate Report

    As a workaround, use the Mozilla Firefox Web browser to download and save reports while using an HTTPS connection. PR566581

  • If you access the J-Web interface using Microsoft Internet Explorer version 7, on the BGP Configuration page (Configure > Routing > BGP), all flags might be shown in the Configured Flags list (in the Edit Global Settings window, in the Trace Options tab), even though the flags are not configured. As a workaround, use the Mozilla Firefox browser. PR603669

  • On the J-Web interface, on the Route Information page (Monitor > Routing > Route Information), the Next Hop column displays only the interface address, and the corresponding IP address is missing. The title of the first column displays Static Route Address instead of Destination Address. As a workaround, use the show route detail CLI command to fetch the IP address of the next-hop interface. PR684552

  • On the J-Web interface, HTTPS access might work even with an invalid certificate. As a workaround, change the certificate and then issue the restart web-management command to restart the J-Web interface. PR700135

  • On EX2200-C switches, if you change the media type of an uplink port and commit the change, the Ports Configuration page (Configure > Interfaces > Ports) might not list that uplink port. PR742847

  • If either a copper uplink port or a fiber uplink port is connected on an EX2200-C switch, both might be displayed as up in the J-Web dashboard. PR862411

  • On an EX4300 Virtual Chassis, if you renumber the Virtual Chassis members while there is an active J-Web session, a socket error might be created. As a workaround, refresh the J-Web session. PR857269

  • On EX Series switches, the subscriber management infrastructure daemon (smid) might randomly crash when the smid daemon is interleaved with another daemon that is attempting to access the same shared memory. PR1082211

  • On an EX4600 Virtual Chassis, if lossless traffic is passing through a switch in the linecard role over a 10-gigabit SFP+ link configured as a Virtual Chassis port (VCP), traffic on the link might be dropped when the link is congested. PR1006974

  • On EX Series switches except EX4600, if you configure an IPv4 GRE interface on an IPv6 interface, the GRE tunnel might not work properly. Traffic is not forwarded through the tunnel. PR1008157

  • The J-Web dashboard might take longer than usual to load depending on the number of EX8200 Virtual Chassis members, due to time taken for collecting CLI responses. PR806803

Layer 2 Features

  • On EX Series switches, after a switch reboot, a Q-in-Q tunneling interface might not function as expected. The problem occurs when the interface is a member of a PVLAN with mapping set to swap and is also a member of a non-private VLAN. The PVID of the access interface does not get set when the PVLAN is configured before the non-private VLAN. The problem does not occur when the non-private VLAN is configured before the PVLAN. PR937927

  • On ELS (Enhanced Layer 2 Software) platforms (including EX4300, EX4600, EX9200, QFX3500, QFX3600, and QFX5100), if Q-in-Q tunneling is enabled, if you configure an RTG (redundant trunk group) on a Q-in-Q interface, the RTG configuration cannot be applied; there is a commit check error. PR1134126

  • On EX4500 Virtual Chassis, when one member of the Virtual Chassis is switched off, ERPS should be reinitialized on the other members. However, because the interfaces are on the member ERPS ring that is not active anymore, ERPS cannot complete initialization properly and it stays in the init state. Thus, the rest of the interfaces do not converge to a proper state. This is expected behavior. If there is a requirement to have complete ERPS support in a ring topology and to perform a mastership failover test on a Virtual Chassis with ERPS, then Interfaces of the Virtual Chassis that are part of the ERPS link should be configured as aggregated Ethernet (AE) interfaces. Ideally physical interfaces that are part of this AE interface should be spread across all members of the Virtual Chassis. However, this is not necessary—the AE interface can contain only one physical interface and the mastership failover will still work properly. PR1235062

  • If the fast-interval configured value is less than 500ms, the VRRP session can flap. This is due to PPMD not being able to process all the packets. PR1258597

  • A vmember limit warning message might be displayed if the total number of VLANs members exceeds approximately 4093 * 8, assuming 8 members per VLAN. This is a warning message and still allows the configuration. However, in field configurations, this limit is not breached. PR1300513

  • If you configure an uplink or network port as an extended VCP to create a redundant link with a dedicated VCP connection on EX4200, EX4500, or EX4550 switches, to avoid traffic looping within the Virtual Chassis, we recommend rebooting the Virtual Chassis after configuring the port conversion. PR1313088

  • On an EX4200 and EX4500 mixed Virtual Chassis, in a scaled setup, changing the MTU value for interfaces might trigger resetting of adjacencies associated with the interfaces and result in high CPU utilization for the respective daemons, pfem and sfid. During this process, rolling back the configuration and committing it might result in the generation of core files. We recommend ensuring that enough time is provided for the system to stabilize before rolling back the configuration and triggering a successive commit. PR1319164

  • On EX4200 and EX4500 Virtual Chassis, a pfem core file might be generated in a scaled environment when STP flaps, due to which all other configured protocols—VSTP, VRRP, OSPF and LACP—flap. In this case, upon trying to reinstall the multicast route, the TCAM entry for the related route entry is found to be invalid and the pfem core file is generated. PR1355286


  • On EX4600 switches, user-to-network (UNI) interfaces that have over 100 pseudowires might not function correctly. Up to 100 pseudowires are supported in active/backup configurations (cold standby). If more than 100 active and backup pseudowires are configured, traffic might not be forwarded correctly after a provider edge (PE) switch is either rebooted or disabled then reenabled. PR1048500

Multicast Protocols

  • On EX4550 switches, if you configure IGMP on all interfaces and create a large number of multicast groups, the maximum scale for IGMP can be achieved on some interfaces but not all interfaces. PR1025169

  • On EX9200 switches, multicast traffic might fail when the source is on an ordinary VLAN and the receiver is on a PVLAN with a primary VLAN ID, with both source and receiver on the same switch. PR1028869

  • On Virtual Chassis models EX2200, EX3300, EX4200, EX4500, EX4550, and EX8200, Layer 3 multicast traffic does not flow if VLAN pruning is enabled for the upstream interface and the VLAN does not have a member on the device on which the downstream interface resides. As a workaround, disable VLAN pruning for the upstream interface if the device where the downstream interface resides does not have a member for that VLAN. PR1156014

Network Management and Monitoring

  • This is a limitation with the physical layer (being used in EX4550-32F), while reading the SFP-T optics registers (16-bit register), hence there is a delay while doing an SNMP walk or an SNMP GET request for interface-specific MIBs. PR832071

  • On EX4300 switches, if you configure a remote analyzer with an output IP address that is reachable through routes learned by BGP, the analyzer state is DOWN. PR1007963

  • On EX8200 switches, some sFlow data might have incorrect input and output interface index values. PR1051435

Platform and Infrastructure

  • You cannot connect EX2200-C-12P-2G switches to the prestandard Cisco IP Phone 7960 using a straight cable. As a workaround, use a crossover cable. PR726929

  • On EX4300 switches, Ethernet ring protection (ERP) fails if the control VLAN is replaced with a different VLAN at runtime. PR817456

  • On EX4300 switches, despite an administrative link being down, child members of an aggregated Ethernet group that is part of a multicast downstream IRB VLAN might be programmed into a multicast route index in the Packet Forwarding Engine, resulting in the failure of multicast replication of packets for some VLANs. PR880769

  • On EX4300 switches, if multicast data packets that fail an RPF check are received on a nonshared tree, the packets might be trapped on the Routing Engine at a high rate, resulting in poor PIM convergence. PR911649

  • On EX4300 switches, in an egress router-based firewall filter, IPv6 Layer 4 headers (of ICMP type) might not work. PR912483

  • On EX9200 Virtual Chassis, commit errors might occur if commits are done frequently. PR1188816

Port Security

  • On EX4300 switches, when storm-control or storm-control-profiles with action-shutdown is configured, if the storm-triggered traffic is control traffic such as LACP, the physical interface will be put into an STP blocking state rather than turned down, so valid control traffic might be trapped to the control plane and unrelated interfaces might be set down as an LACP timeout. PR1130099

Routing Protocols

  • On EX4300, EX4600, and QFX Series switches, a Bidirectional Forwarding Detection (BFD) session might not come up when BFD version 0 is configured. As a workaround, deactivate or delete the version configuration. PR1076052

  • In a highly scaled scenario, deleting an EX4200 or EX4500 Virtual Chassis member and adding it back might lead to session flaps and unintended consequences. We recommend that you plan to delete the Virtual Chassis member after the protocols sessions and interfaces are administratively brought down and then enable it later. PR1309806

Software Installation and Upgrade

  • On EX Series or QFX Series Virtual Chassis or Virtual Chassis Fabric (VCF), nonstop software upgrade (NSSU) cannot be used to upgrade from a Junos OS Release 14.1X53 image to a Junos OS Release 15.1 or later image. PR1087893

  • On EX4600, QFX3500, and QFX5100 switches, the amount of time that it takes for Zero Touch Provisioning to complete might be lengthy because TFTP might take a long time to fetch required data. PR980530

  • In a mixed EX4200 and EX4500 Virtual Chassis or in an EX3300 Virtual Chassis, or on an EX6200 or EX8200 switch, during a nonstop software upgrade (NSSU), packets might be duplicated. PR1062944

  • Substantial traffic losses might occur when executing a nonstop software upgrade (NSSU) on a mixed EX4200 and EX4500 Virtual Chassis or on an EX3300 Virtual Chassis, an EX6200 switch, an EX8200 switch, or an EX8200 Virtual Chassis. PR1062960

  • On an EX8200 Virtual Chassis, an NSSU to Junos OS Release 15.1R1 might fail after the image is pushed to the backup Routing Engine, and a vmcore might be created. PR1075232

  • On EX4300 switches, traffic might be lost for Layer 3 protocols (such as RIP, OSPF, BGP, and VRRP) during a nonstop system upgrade (NSSU). PR1065405

  • In Junos Space, the Junos OS Release 15.1R1 image for EX9200 switches is not mapped to the correct platform. As a workaround, in Junos Space, right-click the device image, and select ex-92xx in Modify device image. PR1090863

  • On EX9200 switches, during an in-service software upgrade (ISSU) from Junos OS Release 15.1R1 to Release 15.1R2, BGP and Layer 3 multicast traffic might be dropped for approximately 30 seconds. PR1116299

  • On an EX4300 Virtual Chassis and on EX8200 switches, when you perform an NSSU, there might be up to five seconds of traffic loss for multicast traffic. PR1125155

  • On EX4300 Virtual Chassis, NSSU is not supported from Junos OS Release 14.1X53-D35 to Release 15.1. PR1148760

Spanning-Tree Protocols

  • On EX4200 and EX4500 Virtual Chassis, in a scaled setup, with 2k VLANs, multiple protocol sessions and LAG interfaces, MSTP instances might not converge. We recommend that you have as few a number of MSTIs as possible. PR1308944

  • On EX4550 Virtual Chassis, in a scaled Virtual Chassis environment, configuring more VSTP instances might lead to convergence issues. We recommend that you configure VSTP only when absolutely needed and that you put VLANs under RSTP. You can use MSTP if the VLANs can be grouped together under a single spanning-tree instance. PR1352986

User Interface and Configuration

  • On EX8200 Virtual Chassis, if you are using the Virtual Chassis wizard in the J-Web interface in the Mozilla Firefox version 3.x browser and select more than six port pairs from the same member to convert from VCPs to network ports, the wizard might display incorrect port conversion status. Also, if you double-click Next after deleting an active member in the Members page, the J-Web interface might stop responding. PR796584

  • If you uninstall the J-Web Platform package by using the CLI, reinstalling the Application package does not restore J-Web. PR1026308

Virtual Chassis

  • On an EX9200 Virtual Chassis, if you restart an FPC with Virtual Chassis ports (VCPs) and there are no other FPCs with VCPs, a Virtual Chassis split might occur and the backup FPC might show a machine check exception and create a Network Processing Card (NPC) core file. PR1083965

  • When two uplink or network ports are connected back to back on an EX3300 Virtual Chassis, there is a chance of unexpected behavior such as traffic looping, a member in the routing-engine role changing to the linecard role, or traffic loss on the ports that are connected back to back. PR1275115

  • If both members of a two-member EX4300 Virtual Chassis are shut down and only one member is powered on again, it will take about 10 minutes until this member transitions from linecard mode to master. PR1278105

  • In a Virtual Chassis composed of EX4200, EX4500, or EX4550 switches, if two member switches are already connected with a dedicated VCP link and a redundant VCP link is added between the two members using uplink ports converted into VCPs, traffic might loop in the Virtual Chassis. The issue can occur whether the redundant link is added intentionally or inadvertently due to miscabling, and whether the link is converted into a VCP link manually or by the VCP automatic conversion feature. As a workaround to stop the looping behavior, reboot the Virtual Chassis after adding the additional VCP link, or reboot the Virtual Chassis after correcting the miscabling and removing unintentional VCP settings.


    When enabled, VCP automatic conversion is invoked if the Virtual Chassis is preprovisioned, LLDP is enabled on the ports on both sides of the link, and the ports on both sides of the link are network ports that are not already converted into VCPs.