Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Network Management and Monitoring

  • OAM on S-VLAN bidirectional state propagation (MX204, MX240, MX304, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10004, MX10008, and MX10016)—We've enhanced the OAM on S-VLAN feature for bidirectional state propagation. The OAM on S-VLAN feature allows monitoring of CFM at the S-VLAN level and propagates the state to associated C-VLANs within the S-VLAN for point-to-point services. This reduces the scale of CFM monitoring by propagating the state from the customer edge (CE) to the provider edge (PE) for a specific S-VLAN.

    To enable PE to CE state propagation for an OAM on SVLAN session, configure the interface-status-tlv for the CFM session on the S-VLAN logical interface. This configuration ensures that the PE state is propagated as part of the interface status TLV.

    The feature supports propagating SVLAN status on down MEP CFM session using interface-status-tlv for CCC family in PPMAN and CFMMAN modes (inline and non-inline).:

    [See Ethernet OAM Support for Service VLANs Overview]

  • Mirror outgoing control-plane traffic with family any filters (MX Series with MPC-9 or MPC-10 line cards)—Port mirroring copies IPv4 or IPv6 packets entering or leaving an interface and sends copies of these packets to an external host or packet analyzer for analysis. One port-mirroring method that you can use allows you to mirror selected transit network traffic to remote network analyzers by sending the mirrored packets through overlay tunnels. The enhanced method allows you to use family any filters with the same match conditions that you would use with family inet or family inet6 to selectively mirror the host-outbound traffic.

    For IPv4 traffic—You can use the family any filter with these match conditions:

    • address, destination-port, destination-port-except, destination-prefix-list, dscp, dscp-except, first-fragment, fragment-flags, fragment-offset, fragment-offset-except, gre-key, gre-key-except, icmp-code, icmp-code-except, icmp-type, icmp-type-except, ip-address, ip-destination-address, ip-precedence, ip-precedence-except, ip-protocol, ip-protocol-except, ip-source-address, is-fragment, port, port-except, prefix-list, source-port, source-port-except, source-prefix-list, tcp-established, tcp-flags, tcp-initial, ttl, ttl-except

    For IPv6 traffic—You can use the family any filter with these match conditions:

    • address, destination-port, destination-port-except, destination-prefix-list, extension-header, extension-header-except, first-fragment, gre-key, gre-key-except, hop-limit, hop-limit-except, icmp-code, icmp-code-except, icmp-type, icmp-type-except, ip6-address, ip6-destination-address, ip6-source-address, is-fragment, last-fragment, next-header, next-header-except, payload-protocol, payload-protocol-except, port, port-except, prefix-list, source-port, source-port-except, source-prefix-list, tcp-established, tcp-flags, tcp-initial, traffic-class, traffic-class-except

  • Chunked framing support in NETCONF sessions (MX304, MX960, MX2020, MX10008, and MX10016)—Junos devices support the chunked framing mechanism for messages in a NETCONF session. Chunked framing is a standardized framing mechanism that ensures that character sequences within XML elements are not misinterpreted as message boundaries. If you enable RFC 6242 compliance, and both peers advertise the :base:1.1 capability, the NETCONF session uses chunked framing for the remainder of the session. Otherwise, the NETCONF session uses the character sequence ]]>]]> as the message separator.

    [See Configure RFC-Compliant NETCONF Sessions.]

  • 64-bit nanosecond EPOCH timestamp over port-mirrored packets (MX10008, MX10016)—You can specify that the software provide a 64-bit nanosecond EPOCH timestamp over a port-mirrored packet for family any packets mirrored in ingress and egress directions.

    The port-mirroring destination can be a next-hop group. In this case, every mirrored packet, for each member of the group, carries the same timestamp.

    The timestamp on the mirrored packet is extracted during port-mirror post processing, which executes after the mainline packet is processed. Thus, there is a microsecond-worth delay since the mainline packet entered or exited on the corresponding interface. Also, an L2 or L3 feature that depends on the MAC address for forwarding of the mirrored packet might not function as expected, because the MAC header fields are overwritten with the timestamp.

    [See Timestamping of Port-Mirrored Packets.]