Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Related Documentation

  • New and Changed Features
  • Changes in Behavior and Syntax
  • Known Behavior
  • Resolved Issues
  • Documentation Updates
  • Migration, Upgrade, and Downgrade Instructions
  • Product Compatibility

Known Issues

This section lists the known issues in hardware and software in Junos OS Release 15.1F6 for the MX Series and T Series.

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

Forwarding and Sampling

  • If bandwidth-percent based policer is applied on aggregated Ethernet (AE) bundle without the "shared-bandwidth-policer" configuration statement, traffic will hit policer even if the traffic is not exceeding the configured bandwidth. As a workaround, configure the "shared-bandwidth-policer" configuration statement under the policer. PR1125071

General Routing

  • The following message is generated every 5 second in MX104 on 14.2R1~R3 and 15.1R1: “xxx chassisd[1362]: Cannot read hw.chassis.startup_time: No such file or directory.” PR1049015
  • Certain VTY JNH commands(see description of this PR-1094955) on Trinity platform will not decode properly, would need this PR fix. PR1094955
  • SFB2 offline/online with 20 line cards takes 9 minutes 52 seconds whereas for SFB it takes 42 seconds. PR1097338
  • On MX Series platform, executing CLI command "request ancp oam neighbor" might cause the ancpd process crash. PR1125230
  • Subscriber where TCP is attached to the underlying IFL will errantly end up in the control IFL queue. Workaround is to attach a TCP profile to each subscriber IFL. PR1162108
  • Under loaded router (i.e., 1000+ IPsec tunnels, 100+ BGP sessions, 1+ Mln routes) when performing a GRES some IPsec tunnels might fail to come up. PR1162385
  • Default EVPN policy in junos-defaults for mx-series is removed. This was used to enable per packet load-balance for EVPN routes. Now per-packet load balance needs to be configured explicitly. PR1162433
  • Stacked ifl and the underlying ifl cannot be part of the same iflset. PR1162805
  • On MS-MIC, starting from 15.1R3 onwards, the J-Flow scaling has come down to 12.5 M active flows. PR1163976
  • Traffic may drop during Routing Engine switchover. PR1164107

High Availability and Resiliency

  • After graceful switchover is triggered in the master VRRP router for the first time, the master state for all the VRRP instances is toggled to backup and comes back to master immediately. During this time all the traffic is dropped and comes back. PR1142227
  • When B2B switch over is done on TXP with 15.1F6 image, on first switch over the system performs as expected. However, packet loss may be seen on doing switch over for the second time. Here in second switch over , 0.21% packet loss happening. PR1172546

MPLS

  • These benign error messages can be ignored. The Junos OS code will be cleaned up to remove these message in later code. PR1136033
  • FPC cores may be seen during AE flap on Type 5-3D FPCs. PR1164175

Platform and Infrastructure

  • Once the Traffic Offload Engine (TOE) thread is stalled due to memory error at the lookup chip all statistics collection from the interfaces hosted by this PFE are not updated anymore. PR1051076
  • On MX Series Virtual Chassis (MX-VC) with "locality-bias" configured, when equal-cost multipath (ECMP) load-balancing is occurring in the VC system, multicast streams and flooded Layer 2 streams may be duplicated or lost. As a workaround, we can disable "locality-bias" if possible. PR1104096
  • When replying to operational RPCs executed over NETCONF sessions, the Junos OS software will add leading and trailing whitespace that is not present for Junoscript sessions. PR1143761
  • This issue can occur in subscriber management configuration that has a very large number of address pools on the order of 64K or more. At this scale of address pools, synchronizing the two Routing Engines after one GRES switchover can take a long time preventing a second graceful switchover. This issue is not expected in configurations with smaller address pool scale. PR1159972
  • VMX PE could send ICMP packet source from address of a disabled CE interface in L3 VRF instance. This could break the ping test without specifying the source address. An example is shown below that VMX PE send ICMP packet sourced from ae0.306 (disabled): 202.202.6.1. ae0.301 up up inet 202.202.1.1/30 ae0.306 down down inet 202.202.6.1/30 Router> ping 14.1.1.2 routing-instance VPN1 rapid PING 14.1.1.2 (14.1.1.2): 56 data bytes --- 14.1.1.2 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss 15:54:57.141675 In IP 202.202.6.1 > 14.1.1.2: ICMP echo request, id 14135, seq 0, length 64 15:54:57.141697 Out IP 14.1.1.2 > 202.202.6.1: ICMP echo reply, id 14135, seq 0, length 64 Workaround is to enable the ae0.306, or just add a lo0 logical interface under this L3 VRF instance VPN1, which can be used as ICMP source by default. PR1175658

Routing Protocols

  • The static/static access routes pointing to an unnumbered interface are getting added in the routing table even if the interface is down. In this case, if graceful Routing Engine switchover (GRES) is disabled, this type of route will never be added in routing table after Routing Engine switchover. PR1064331
  • When BGP speaker has multiple peers configured in a BGP group and when it receives the route from a peer and re-advertises route to another peer within the same group, MIB object "jnxBgpM2PrefixOutPrefixes" to the peers in the same group reports the total number of advertised prefixes in the group. MIB value "jnxBgpM2PrefixOutPrefixes" is defined as per peer basis but it looks as if it is per group basis. As a workaround, we can get the number of advertised prefixes from CLI command "show bgp neighbor" instead. PR1116382
  • When multiple addresses are configured on an interface, if the interface has "interface-type p2p" configured under OSPF and the router does not receive any OSPF packets from one of the IFAs, the OSPF state will not go down for the corresponding adjacency. It should has no impact on route learning, but it might cause confusion for troubleshooting, when peering with Cisco devices, which have multiple addresses configured as secondary addresses. PR1119685
  • On dual-Routing Engine platforms, in scaling scenario (e.g., there are 6 million routes on "old" master Routing Engine), if graceful Routing Engine switchover (GRES) or graceful restart (GR) is not enabled, the routing protocol process (rpd) may crash on the "old" master Routing Engine after performing Routing Engine switchover. As a workaround, if possible, rebooting the "old" master Routing Engine (new backup Routing Engine) after switchover could avoid the issue. PR1128023
  • Generate route does not inherit the next-hop from the contributing route in L3VPN case when the contributing route is learnt via MP-BGP. The next-hop remains as reject for the generated route. PR1149970

Services Applications

  • Space may be missing in tnp.bootpd log message output string. There is no known operational impact. PR1075355

VPNs

  • In a multi-homed source topology in NG-MVPN (applicable to both inter-AS and intra-AS scenario), there are two problems: The first problem is Multicast (S, G) signaling doesn't follow RPF. When the routing table (mvpninstancename.inet0) has two routes, due to the policy configuration, the best route to the source is via the MPLS core, but Multicast (S, G) PIM join and NG-MVPN Type 7 both point to inactive route via local BGP peer. The second problem is when "clear pim join instance NG" is entered, the multicast forwarding entries are wiped out. PR1099720

Related Documentation

  • New and Changed Features
  • Changes in Behavior and Syntax
  • Known Behavior
  • Resolved Issues
  • Documentation Updates
  • Migration, Upgrade, and Downgrade Instructions
  • Product Compatibility

Modified: 2017-03-22