interfaces forming an Layer 2 Virtual Circuit is down. [PR/572780: This issue has been resolved.] Release 10.3R2 The following issues have been resolved since Junos OS Release 10.3R2. The identifier following the description is the tracking number in our bug database. Class of Service
When a VLAN ID is changed, the following message appears in the messages log: "COSD_GENCFG_WRITE_FAILED: GENCFG write failed for Classifier to IFL 74. Reason: File exists. This log message appears when the configuration is committed with VPLS configured on the Gigabit Ethernet interface, and a class-of-service classifier or rewrite rules that contain IEEE 802.1P on the interface are used. [PR/408552: This issue has been resolved.] When a logical interface set has a shaping-rate less than the sum of transmit-rates of its queues and when the configuration is corrected so that the logical interface set gets the correct shaping-rate, ADPC might crash. [PR/523507: This issue has been resolved.] During a graceful Routing Engine switchover, the traffic control profile might not be applied on the interfaces. As a workaround, deactivate and reactivate class of service. [PR/533862: This issue has been resolved.] When per-unit-scheduler is applied under the interfaces hierarchy level, and shaping rate is applied under the class-of-service interface hierarchy level in the same commit operation, port shaping rate does not work and the total logical interface transmitted byte rate exceeds the physical interface shaping rate. As a workaround, configure shaping-rate within a traffic-control-profile and apply that to an interface, or deactivate and activate shaping-rate using the class-of-service interface interface-name shaping-rate command. [PR/539590: This issue has been resolved.] Under certain conditions, the class of service configuration might not take effect on an IQ2 PIC. [PR/541814: This issue has been resolved.] When the rate-limit option is configured on a physical interface on IQ2 PICs, the show interface queue command might not display the RL-dropped counters. [PR/547218: This issue has been resolved.] The egress rate limit over a logical interface may drop large packets. [PR/547506: This issue has been resolved.] In Junos OS Release 10.2 and later, the cosd process might crash while a configured commit is processed, as this process accesses a memory location that has already been freed. However, this issue is encountered rarely. [PR/548367: This issue has been resolved.]

[Network Interfaces]

For Ethernet shared interfaces on the JCS 1200 Platform, gratuitous-arp configuration statements are supported on the Root System Domain (RSD), but not the Protected System Domain (PSD). These statements are configured at the [edit interfaces ge-x/y/x] hierarchy level. These statements include: gratuitous-arp-reply, no-gratuitous-arp-replay, and no-gratuitous-arp-request. Values you configure for gratuitous-arp statements on the RSD are not passed to the PSD. This is not communicated in the Junos Software 10.3 JCS 1200 documentation. [JCS 1200]
The Junos OS Configuration and Operations Automation Guide erroneously states that persistent changes work like the load merge command and transient changes work like the load update command. Both persistent and transient changes behave like the load replace command. In the chapter Summary of Junos XML and XSLT Tag Elements Used in Commit Scripts, the <change> and <transient-change> tag element summaries include attributes for both tags. Neither the <change> tag nor the <transient-change> tag have attributes. All references to the attributes in the Description section are not applicable to these tags. [Junos OS Configuration and Operations Automation Guide]

J-Web Interface

To access the J-Web interface, your management device requires the following software:
Supported browsersMicrosoft Internet Explorer version 7.0 or Mozilla Firefox version 3.0 Language supportEnglish-version browsers Supported OSMicrosoft Windows XP Service Pack 3
The listings for the following RFCs incorrectly state that the Junos OS supports only SSM include mode. Both include mode and exclude mode are supported in Junos OS Release 9.3 and later.
RFC 3376, Internet Group Management Protocol, Version 3 RFC 3590, Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
[Hierarchy and Standards Reference] Routing Protocols
Bidirectional Forwarding DetectionThe Routing Protocols Configuration Guide contains conflicting information about how to configure the Bidirectional Forwarding Detection (BFD) liveness detection minimum-interval statement. BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping. Depending on your network environment, these additional recommendations might apply:
For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 ms for Routing Engine-based sessions and 100 ms for distributed BFD sessions.

NOTE: You might want to maintain a multicast VPN instance lo0.x address to use for protocol peering (such as IBGP sessions), or as a stable router identifier, or to support the PIM bootstrap server function within the VPN instance.
Complete the following steps when upgrading routers in your draft-rosen multicast VPN network to Junos OS Release 10.1 if you want to configure the routerss main instance loopback address for draft-rosen multicast VPN:
Upgrade all PE routers to Junos OS Release 10.1 before you configure the loopback address for draft-rosen Multicast VPN.
NOTE: Do not configure the new feature until all the PE routers in the network have been upgraded to Junos OS Release 10.1.
2. After you have upgraded all routers, configure each routers main instance loopback
address as the source address for multicast interfaces. Include the default-vpn-source interface-name loopback-interface-name] statement at the [edit protocols pim] hierarchy level.
3. After you have configured the routers main loopback address on each PE router,
delete the multicast VPN loopback address (lo0.x) from all routers. We also recommend that you remove the multicast VPN loopback address from all PE routers from other vendors. In Junos OS releases prior to 10.1, to ensure interoperability with other vendors routers in a draft-rosen multicast VPN network, you had to perform additional configuration. Remove that configuration from both the Juniper Networks routers and the other vendors routers. This configuration should be on Juniper Networks routers and on the other vendors routers where you configured the lo0.mvpn address in each VRF instance as the same address as the main loopback (lo0.0) address. This configuration is not required when you upgrade to Junos OS Release 10.1 and use the main loopback address as the source address for multicast interfaces.
NOTE: To maintain a loopback address for a specific instance, configure a loopback address value that does not match the main instance address (lo0.0).
For more information about configuring the draft-rosen Multicast VPN feature, see the Junos Multicast Configuration Guide.
Upgrading the Software for a Routing Matrix
A routing matrix can use either a TX Matrix router as the switch-card chassis (SCC) or a TX Matrix Plus router as the switch-fabric chassis (SFC). By default, when you upgrade software for a TX Matrix router or a TX Matrix Plus router, the new image is loaded onto the TX Matrix or TX Matrix Plus router (specified in the Junos OS CLI by using the scc or sfc option) and distributed to all T640 routers or T1600 routers in the routing matrix (specified in the Junos OS CLI by using the lcc option). To avoid network disruption during the upgrade, ensure the following conditions before beginning the upgrade process:

Disable graceful Routing Engine switchover (GRES) on the master Routing Engine (re0) and save the configuration change to both Routing Engines.
2. Install the new Junos OS release on the backup Routing Engine (re1) while keeping
the currently running software version on the master Routing Engine (re0).
3. Load the new Junos OS on the backup Routing Engine. After making sure that the new
software version is running correctly on the backup Routing Engine (re1), switch mastership back to the original master Routing Engine (re0) to activate the new software.
4. Install the new software on the new backup Routing Engine (re0).
For the detailed procedure, see the Routing Matrix with a TX Matrix Feature Guide or the Routing Matrix with a TX Matrix Plus Feature Guide.

Upgrading Using ISSU

Unified in-service software upgrade (ISSU) enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic. Unified in-service software upgrade is only supported by dual Routing Engine platforms. In addition, graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) must be enabled. For additional information about using unified in-service software upgrade, see the Junos OS High Availability Configuration Guide.
Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM and NSR
Junos OS Release 9.3 introduced NSR support for PIM for IPv4 traffic. However, the following PIM features are not currently supported with NSR. The commit operation fails if the configuration includes both NSR and one or more of these features:
Anycast RP Draft-Rosen multicast VPNs (MVPNs) Local RP Next-generation MVPNs with PIM provider tunnels PIM join load balancing
Junos OS Release 9.3 introduced a new configuration statement that disables NSR for PIM only, so that you can activate incompatible PIM features and continue to use NSR for the other protocols on the router: the nonstop-routing disable statement at the [edit
protocols pim] hierarchy level. (Note that this statement disables NSR for all PIM features,
not only incompatible features.) If neither NSR nor PIM is enabled on the router to be upgraded or if one of the unsupported PIM features is enabled but NSR is not enabled, no additional steps are necessary and you can use the standard upgrade procedure described in other sections of these instructions. If NSR is enabled and no NSR-incompatible PIM features are enabled, use the standard reboot or ISSU procedures described in the other sections of these instructions. Because the nonstop-routing disable statement was not available in Junos OS Release 9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router to be upgraded from Junos OS Release 9.2 or earlier to a later release, you must disable PIM before the upgrade and reenable it after the router is running the upgraded Junos OS and you have entered the nonstop-routing disable statement. If your router is running Junos OS Release 9.3 or later, you can upgrade to a later release without disabling NSR or PIMsimply use the standard reboot or ISSU procedures described in the other sections of these instructions. To disable and reenable PIM:

[protocols ospf3 area area-id interface interface-name] [routing-instances routing-instances-name protocols ospf3 area area-id interface interface-name]
[LN1000 Mobile Secure Router User Guide]
Group VPN Interoperability with Ciscos GET VPN
Ciscos implementation of GDOI is called Group Encryption Transport (GET) VPN. While group VPN in Junos OS and Cisco's GET VPN are both based on RFC 3547, The Group Domain of Interpretation, there are some implementation differences that you need to be aware of when deploying GDOI in a networking environment that includes both Juniper Networks security devices and Cisco routers. This topic discusses important items to note when using Cisco routers with GET VPN and Juniper Networks security devices with group VPN.
Cisco GET VPN members and Juniper Group VPN members can interoperate as long as the server role is played by a Cisco GET VPN server, Juniper Networks security devices are group members, and with the following caveats: The group VPN in Release 10.3 of Junos OS has been tested with Cisco GET VPN servers running Version 12.4(22)T and Version 12.4(24)T. To avoid traffic disruption, do not enable rekey on a Cisco server when the VPN group includes a Juniper Networks security device. The Cisco GET VPN server implements a proprietary ACK for unicast rekey messages. If a group member does not respond to the unicast rekey messages, the group member is removed from the group and is not able to receive rekeys. An out-of-date key causes the remote peer to treat IPsec packets as bad SPIs. The Juniper Networks security device can recover from this situation by reregistering with the server to download the new key. Antireplay must be disabled on the Cisco server when a VPN group of more than two members includes a Juniper security device. The Cisco server supports time-based antireplay by default. A Juniper Networks security device will not be able to interoperate with a Cisco group member if time-based antireplay is used since the timestamp in the IPsec packet is proprietary. Juniper Networks security devices are not able to synchronize time with the Cisco GET VPN server and Cisco GET VPN members as the sync payload is also proprietary. Counter-based antireplay can be enabled if there are only two group members. According to Cisco documentation, the Cisco GET VPN server triggers rekeys 90 seconds before a key expires and the Cisco GET VPN member triggers rekeys 60 seconds before a key expires. When interacting with a Cisco GET VPN server, a Juniper Networks security device member would match Cisco behavior. A Cisco GET VPN member accepts all keys downloaded from the GET VPN server. Policies associated with the keys are dynamically installed. A policy does not have to be configured on a Cisco GET VPN member locally, but a deny policy can optionally be configured to prevent certain traffic from passing through the security policies set by the server. For example, the server can set a policy to have traffic between subnet A and subnet B be encrypted by key 1. The member can set a deny policy to allow OSPF traffic between subnet A and subnet B not be encrypted by key 1. However, the member cannot set a permit policy to allow more traffic to be protected by the key. The centralized security policy configuration does not apply to the Juniper Networks security device. On a Juniper Networks security device, the ipsec-group-vpn configuration statement in the permit tunnel rule in a scope policy references the group VPN. This allows multiple policies referencing a VPN to share an SA. This configuration is required to interoperate with Cisco GET VPN servers. Logical key hierarchy (LKH), a method for adding and removing group members, is not supported with group VPN on Juniper Networks security devices. GET VPN members can be configured for cooperative key servers (COOP KSs), an ordered list of servers with which the member can register or reregister. Multiple group servers cannot be configured on group VPN members.

In large chassis cluster configurations on SRX3400 or SRX3600 devices, you need to increase the wait time before triggering failover. In a full-capacity implementation, we recommend increasing the wait to 8 seconds by modifying heartbeat-threshold and heartbeat-interval values in the [edit chassis cluster] hierarchy. The product of the heartbeat-threshold and heartbeat-interval values defines the time before failover. The default values (heartbeat-threshold of 3 beats and heartbeat-interval of 1000 milliseconds) produce a wait time of 3 seconds. To change the wait time, modify the option values so that the product equals the desired setting. For example, setting the heartbeat-threshold to 8 and maintaining the default value for the heartbeat-interval (1000 milliseconds) yields a wait time of 8 seconds. Similarly, setting the heartbeat-threshold to 4 and the heartbeat-interval to 2000 milliseconds also yields a wait time of 8 seconds.
SRX100, SRX210, SRX240, and SRX650 devices have the following chassis cluster limitations:
Virtual Router Redundancy Protocol (VRRP) is not supported. In-service software upgrade (ISSU) is not supported. The 3G dialer interface is not supported.
On SRX Series device failover, access points on the Layer 2 switch reboot and all wireless clients lose connectivity for 4-6 minutes. On VDSL mini-PIM, chassis cluster is not supported for both VDSL and ADSL mode. Queuing on aggregated Ethernet (ae) interface is not supported. PoE is not supported in chassis cluster mode. Group VPN is not supported. Sampling features like J-FLow, packet capture, and port mirror on the reth interface are not supported. IDP is not supported for active/active chassis cluster, and it is supported for active/backup chassis cluster in Junos OS Release 10.2 R2 and later. Switching is not supported in chassis cluster mode. The Chassis Cluster MIB is not supported. Any packet-based services like MPLS and CLNS are not supported. lsq-0/0/0Link services Multilink Point-to-Point Protocol (MLPPP), Multilink Frame Relay (MLFR), and Compressed Real-Time Transport Protocol (CRTP) are not supported. gr-0/0/0Generic routing encapsulation (GRE) and tunneling are not supported. ip-0/0/0IP-over-IP (IP-IP) encapsulation is not supported. lt-0/0/0CoS for real-time performance monitoring (RPM) is not supported.

AX411 Access Point

On SRX210 PoE devices, the access point reboots when 100 clients are associated simultaneously and each one is transmitting 512 bytes packets at 100 pps. [PR/469418] On SRX650 devices, when an access point is part of the default cluster and you change the default cluster after the access point is connected to it, the changes might not be reflected. As a workaround, restart the wireless LAN service. [PR/497752]
On SRX650 devices, AX411 access points might not work in the following scenarios:
Multiple access points upgraded all at once Reboot of multiple access points managed by SRX Series devices in cluster mode
As a workaround, bring up one access point at a time and confirm that the configuration push has occurred on one access point before adding the next access point to the cluster. [PR/538994] Chassis Cluster
On J Series devices in a chassis cluster, the show interface terse command on the secondary Routing Engine does not display the same details as that of the primary Routing Engine. [PR/237982] On J4350 Services Routers, because the clear security alg sip call command triggers a SIP RTO to synchronize sessions in a chassis cluster, use of the command on one node with the node-id, local, or primary option might result in a SIP call being removed from both nodes. [PR/263976] On J Series devices, when a new redundancy group is added to a chassis cluster, the node with lower priority might be elected as primary when the preempt option is not enabled for the nodes in the redundancy group. [PR/265340] On J Series devices, when you commit a configuration for a node belonging to a chassis cluster, all the redundancy groups might fail over to node 0. If graceful protocol restart is not configured, the failover can destabilize routing protocol adjacencies and disrupt traffic forwarding. To allow the commit operation to take place without causing a failover, we recommend that you use the set chassis cluster heartbeat-threshold 5 command on the cluster. [PR/265801] On J Series devices in a chassis cluster, a high load of SIP ALG traffic might result in some call leaks in active resource manager groups and gates on the backup router. [PR/268613] On SRX Series devices in a chassis cluster, configuring the set system process jsrp-service disable command only on the primary node causes the cluster to go into an incorrect state. [PR/292411] On SRX Series devices in a chassis cluster, using the set system processes chassis-control disable command for 4 to 5 minutes and then enabling it causes the device to crash. Do not use this command on an SRX Series device in a chassis cluster. [PR/296022] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, 8-queue configurations are not reflected on the chassis cluster interface. [PR/389451] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the iflset functionality is not supported for aggregated interfaces like reth. [PR/391377] On an SRX210 device in a chassis cluster, when you upgrade the nodes, sometimes the forwarding process might crash and get restarted. [PR/396728] On an SRX210 device in a chassis cluster, sometimes the reth interface MAC address might not make it to the switch filter table. This results in the dropping of traffic sent

Example:

set interfaces at-5/0/0 unit 0 vci 1.110 set interfaces at-5/0/0 unit 0 shaping cbr 62400 ATM COS set class-of-service interfaces at-5/0/0 unit 0 scheduler-map sche_map IP COS set class-of-service interfaces at-5/0/0 unit 0 shaping-rate 62400 ADD IFL SHAPER

[PR/430756]

On SRX650 devices, configuring dual and quad T1/E1 framing at the chassis level has no effect. [PR/432071] On SRX Series devices, incorrect Layer 2 circuit replication on the backup Routing Engine might occur when you:
Configure nonstop active routing (NSR) and Layer 2 circuit standby simultaneously and commit them Delete the NSR configuration and then add the configuration back when both the NSR and Layer 2 circuits are up

As a workaround:

Configure the Layer 2 circuit for a nonstandby connection.
2. Change the configuration to a standby connection. 3. Add the NSR configuration.

[PR/440743]

On SRX210 Low Memory devices, the E1 interface will flap and traffic will not pass through the interface if you restart forwarding while traffic is passing through the interface. [PR/441312] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you configure the SAP listen option using the protocol sap listen command in the CLI, listening fails in both sparse and sparse-dense modes. [PR/441833] On J Series devices, one member link goes down in a Multilink (ML) bundle during bidirectional traffic with Multilink Frame Relay (MFR). [PR/445679] On SRX240 Low Memory devices and SRX240 High Memory devices, the RPM Server operation does not work when the probe is configured with the option destination-interface. [PR/450266] On J Series devices, the DS3 interface does not have an option to configure multilink-frame-relay-uni-nni (MFR). [PR/453289] On SRX210 PoE devices, the ATM interface on G.SHDSL interface will not go down when the interface is disabled through the disable command. [PR/453896] On SRX100, SRX210, and J Series devices, out-of-band dial-in access using a serial modem does not work. [PR/458114] On SRX100 and SRX200 devices with VDLS2, multiple carrier transitions (three to four) are seen during long duration traffic testing with ALU 7302 DSLAM. There is no
impact on traffic except for the packet loss after long duration traffic testing, which is also seen in the vendor CPE. [PR/467912]

On SRX210 devices with VDLS2, the remote end ping operation fails to go above the packet size of 1480 because the packets are dropped for the default MTU, which is 1496 on an interface, and because the default MTU of the remote host ethernet interface is 1514. [PR/469651] On SRX210 devices, the G.SHDSL ATM logical interface goes down when ATM CoS is enabled on the interface with OAM. As a workaround, restart the FPC to bring up the logical interface. [PR/472198] On SRX210 devices with VDLS2, ATM COS VBR related functionality cannot be tested because of lack of support from the vendor. [PR/474297] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, the show datapath-debug counter command gives error messages from the secondary node. [PR/477017] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, when you change the multicast scoping to a different multicast address, traffic other than which is configured for multicast scoping will not be received. [PR/482957] On SRX210 High Memory devices, IGMP v2 JOINS messages are dropped on an IRB interface. As a workaround, enable IGMP snooping to use IGMP over IRB interfaces. [PR/492564] On SRX210 and SRX210 devices, every time the VDSL2 PIM is restarted in the ADSL mode, the first packet passing through the PIM will be dropped. This occurs because there is a bug in the SAR engine, which will not set the ATM connection until the first packet has been dropped because of no ATM connection. [PR/493099] On all SRX Series devices, the destination and destination-profile options for address and unnumbered-address within family inet and inet6 are allowed to be specified within a dynamic profile but not supported. [PR/493279] On SRX210 High Memory devices, the physical interface module (PIM) shows time in ADSL2+ ANNEX-M, even though it is configured for ANNEX-M ADSL2. [PR/497129] On SRX100, SRX210, SRX240 and SRX650 devices, whenever radius-server is configured under profile option radius server is marked as dead permanently if radius times out. As a workaround, configure radius-server outside the profile option under access option. [PR/503717] On SRX5600 and SRX5800 devices, load balance does not happen within the aggregated Ethernet (ae) interface when you prefix the length with /24 while incrementing the dst ip. [PR/505840] On SRX100, SRX210, SRX240, and SRX650 devices, egress queues are not supported on VLAN or IRB interfaces.[PR/510568] On SRX650 devices, in the 2-port 10G XPIM, when the interface is linked with fiber, the activity LED does not blink when traffic enters the interface. However, the activity LED blinks properly when traffic goes out of the interface. [PR/513961] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, if stress FTP traffic sustains for several minutes, the device might might begin to accept only limited new FTP

On SRX210, SRX240, and SRX650 devices, J-Web online Help displays the list of all the countries and is not based on the regulatory domain within which the access point is deployed. [PR/469941]
WXC Integrated Services Module
When two J Series devices with WXC Integrated Services Modules (WXC ISM 200s) installed are configured as peers, traceroute fails if redirect-wx is configured on both peers. [PR/227958]
On J6350 devices, Junos OS does not support policy-based VPN with WXC Integrated Services Modules (WXC ISM 200s). [PR/281822]
Resolved Issues in Junos OS Release 10.3 for SRX Series Services Gateways and J Series Services Routers
The following are the issues that have been resolved since Junos OS Release 10.3 for Juniper Networks SRX Series Services Gateways and J Series Services Routers. The identifier following the descriptions is the tracking number in our bug database. Application Layer Gateways (ALGs)
On SRX3400 devices, the ALG Converter erroneously printed messages alg c enter to the flow traceoptions command and it was difficult to analyze flow traceoption output. [PR/571167: This issue has been resolved.]
On SRX3400, SRX3600, SRX5600, and SRX5800 devices in a chassis cluster, when a single node worked, and the interface failed, the LAG on the reth interface did not work. [PR/560485: This issue has been resolved.] On SRX650 devices in a chassis cluster, the Web management session limit feature did not work properly. [PR/573638: This issue has been resolved.] On SRX5600 devices, ISSU took additional time when network traffic was heavy. If the ISSU process duration was longer than one hour, it aborted automatically without completing the upgrade. [PR/585873: This issue has been resolved.]
On SRX3400 devices, the show security policy detail command output displayed incorrect values for the Active Session field. [PR/573600: This issue has been resolved.] On SRX210 High Memory devices, the request and deny CLI commands were seen. [PR/585837: This issue has been resolved.]
On SRX3600 devices, transit traffic that came to the VRRP MAC address was not policed by simple filter policing on the IOC. [PR/528402: This issue has been resolved.] On SRX220 devices, when oversubscribed traffic was sent through the gr interface (after tunnel queuing was enabled and the shaper was configured), there was an increase in tail-dropped packets at the egress of the gr interface. As a result of this, the output packet rate at the egress of the gr interface was much lower compared to that of the shaper. [PR/559378: This issue has been resolved.] On SRX3400, SRX3600, SRX5600, and SRX5800 devices, packets were dropped due to a memory leak in the SPU. [PR/574089: This issue has been resolved.] On SRX650 devices, the license was not released due to sudden loss of connection such as clientpc reboot. [PR/576138: This issue has been resolved.] On SRX3400, and SRX3600 devices, the message fru_is_present: out of range slot -1 for SCB appeared in the chassisd log file. [PR/578408: This issue has been resolved.]

of ternary content addressable memory (TCAM) to firewall filters is supported on EX8200 switches.
Firewall filter IPv6 support on EX8200 switchesFirewall filters for IPv6 traffic are now
supported on EX8200 switches.
PoE+ support on EX2200 switchesThe EX2200 switch now supports IEEE 802.3at
(PoE+). Each PoE port can provide up to 30 W for powered devices. Related Documentation
Changes in Default Behavior and Syntax in Junos OS Release 10.3 for EX Series Switches on page 174 Limitations in Junos OS Release 10.3 for EX Series Switches on page 174 Outstanding Issues in Junos OS Release 10.3 for EX Series Switches on page 176 Resolved Issues in Junos OS Release 10.3 for EX Series Switches on page 183 Errata in Documentation for Junos OS Release 10.3 for EX Series Switches on page 189 Upgrade and Downgrade Issues for Junos OS Release 10.3 for EX Series Switches on page 190
Changes in Default Behavior and Syntax in Junos OS Release 10.3 for EX Series Switches

Interfaces

The default PoE management mode has been changed from static mode to class mode. The output of the show chassis power-budget-statistics command now shows the power supply capacity in watts. If the power supply is offline, the capacity is shown as 0 W. New Features in Junos OS Release 10.3 for EX Series Switches on page 170 Limitations in Junos OS Release 10.3 for EX Series Switches on page 174 Outstanding Issues in Junos OS Release 10.3 for EX Series Switches on page 176 Resolved Issues in Junos OS Release 10.3 for EX Series Switches on page 183 Errata in Documentation for Junos OS Release 10.3 for EX Series Switches on page 189 Upgrade and Downgrade Issues for Junos OS Release 10.3 for EX Series Switches on page 190
Limitations in Junos OS Release 10.3 for EX Series Switches
This section lists the limitations in Junos OS Release 10.3R4 for EX Series switches. If the limitation is associated with an item in our bug database, the description is followed by the bug tracking number.
On EX4200 switches, the traffic is shaped at rates above 500 Kbps, even when the shaping rate configured is less than 500 Kbps. [This is a known software limitation.]

Profile) and then exit the pages without editing the configuration, no validation messages are displayed and the configuration of the switch proceeds. [PR/495603]
In the J-Web interface, the auto-complete feature might not be disabled in the password field. As a workaround, you can disable the auto-complete feature in the browser. [PR/508425] In the J-Web interface, the Software Upload and Install Package option might not display a warning message when there are pending changes to be committed. [PR/514853] 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. [PR/525671] When you use an HTTPS connection in the Microsoft Internet Explorer browser to save a report from the following pages in the J-Web interface, the error message "Internet Explorer was not able to open the Internet site" is displayed on the following pages:
Files page (Maintain > Files) History page (Maintain > Config Management > History) Port Troubleshooting page (Troubleshoot > Troubleshoot > Troubleshoot Port) Static Routing page (Monitor > Routing > Route Information) Support Information page (Maintain > Customer Support > Support Information) View Events page (Monitor > Events and Alarms > View Events)
When you open a J-Web session using HTTPS, then enter a username and password and click on 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. [PR/549934] On EX8200 switches in which no line cards are inserted, the Monitor Interface page in the J-Web interface might display an error message. You can ignore the error message. [PR/562454] In the J-Web interface, the link status might not be displayed correctly on the Port Configuration or the LACP (Link Aggregation Control Protocol) Configuration pages if the Commit Options preference is set to single commit (the Validate Configuration Changes option). [PR/566462] If you have accessed the J-Web interface 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

Revision History

15 August 2010Revision 1, Junos Release 10.3RNovember 2010Revision 2, Junos Release 10.3RFebruary 2011Revision 3, Junos Release 10.3RApril 2011Revision 4, Junos Release 10.3RMay 2011Revision 5, Junos Release 10.3RMay 2011Revision 6, Junos Release 10.3R4
Copyright 2011, Juniper Networks, Inc. All rights reserved. Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.