Chassis
|
Packet Forwarding Engine resiliency (PTX10008)—We provide resiliency feature
support for Packet Forwarding Engine (PFE) on the PTX10008 device with
PTX10K-LC1301-36DD line card. This feature enables the system to detect, report, and
take action on PFE faults. Actions are taken based on default configuration or user
configuration available for the errors.
|
Fabric hardening and resiliency support on PTX10K-LC1301-36DD line cards for
PTX10008 devices.
[See Fabric
Hardening and Recovery on PTX10K Devices.]
|
Class of Service (CoS)
|
Support for class-of-service (CoS) features, including classifiers (behavior
aggregate (BA), fixed, and multifield (MF)), rewrite rules, forwarding classes, loss
priorities, transmission scheduling, rate
control,drop
profiles, HCoS,
and policy map .
[See CoS Features and Limitations on PTX Series
Routers
and Class of Service.]
|
Dynamic Host Configuration Protocol (DHCP)
|
DHCPv4 Relay Agent and DHCPv6 Relay Agent are supported. Features included are:
-
DHCP Relay: Layer 3 (L3) interfaces
-
DHCP Relay: Option 82 for Layer 2 VLANs
-
DHCP Relay: Option 82 for L3 interfaces
-
Extended DHCP Relay Agent
-
Virtual router-aware DHCP (VR-aware DHCP)
[See Extended DHCP Relay Agent Overview.]
|
EVPN
|
|
Support for EVPN-MPLS Layer 2 and Layer 3 Features
[See EVPN Overview.]
|
Support for EVPN-VPWS
[See Overview of VPWS with EVPN Signalig
Mechanisms.]
|
Infrastructure
|
|
Interfaces and Chassis
|
-
Support for VRRP. The following features are not supported for VRRP on Junos OS
Evolved:
-
Support for the following protocols:
-
Support for link fault management (LFM)—We support IEEE 802.3ah OAM LFM to
monitor point-to-point Ethernet links that are connected either directly or
through Ethernet repeaters. The following LFM features are supported:
|
We support the following optics:
-
800G
-
400G
-
100G/2x100G
-
10GbE/25GbE/40GbE
-
We support Mac address accounting for 10GE, 40GE, 100GE, 200GE, 400GE, and
800GE interfaces
-
Support for media access control (MAC) accounting for source and destination
macs for Layer 3 interfaces—We support media access control (MAC) accounting for
source and destination macs for Layer 3 interfaces and aggregated Ethernet
interfaces. To enable MAC accounting, use the existing
mac-learn-enable command under the [edit interfaces
interface-name gigether-options ethernet-switch-profile] or
[edit interfaces aex aggregated-ether-options
ethernet-switch-profile] hierarchy level.
|
IP Tunneling
|
-
Support for the following PFE tunnel features:
-
Filter-based GRE encapsulation and de-encapsulation and filter-based
MPLS-in-UDP de-encapsulation. We've enabled the following encapsulation and
de-encapsulation workflow:
An incoming packet matches a filter term with an encapsulate action.
The packet is encapsulated in an IP+GRE header and is forwarded to the
endpoint's
destination.
set firewall tunnel-end-point tunnel-name ipv4|ipv6 source-address address
set firewall tunnel-end-point tunnel-name ipv4|ipv6 destination-address address
set firewall tunnel-end-point tunnel-name gre
set firewall family inet|inet6 filter name term name from source-address address
set firewall family inet|inet6 filter name term name then encapsulate tunnel-name
set firewall family inet|inet6 filter name term last then accept
set interfaces interface-name unit number family inet|inet6 filter input
set interfaces interface-name unit number family inet|inet6 address address # This source address differs from the one for the tunnel endpoint.
At the destination, the packet matches a filter term with a
de-encapsulate action. The GRE header or MPLS-in-UDP header is stripped
from the packet. The inner packet is routed to its
destination.
set firewall family inet|inet6 filter name term name from source-address address
set firewall family inet|inet6 filter name term name from protocol gre
set firewall family inet|inet6 filter name term name then decapsulate gre # Optionally de-encapsulate mpls-in-udp.
set firewall family inet|inet6 filter name term last then accept
set interfaces interface-name unit number family inet|inet6 filter input filter-name
set interfaces interface-name unit number family inet|inet6 address address # This is the destination address.
[See Components of Filter-Based Tunneling
Across IPv4 Networks and tunnel-end-point.]
-
FTI Tunnels- Support for FTI-based encapsulation and de-encapsulation of
IPv4 and IPv6 packets. You can configure IP-IP encapsulation and
de-encapsulation on flexible tunnel interfaces (FTIs). The default mode is
loopback encap mode. Use the bypass-loopback statement at the [edit
interfaces fti number unit logical-unit-number tunnel encapsulation ipip]
hierarchy level to change into flattened encap mode to achieve line-rate
performance.
[See Tunnel and Encryption Services Interfaces
User Guide for Routing Devices.]
-
Support for configuring MPLS protocols over FTI tunnels, thereby
transporting MPLS packets over IP networks that do not support MPLS. Generic
routing encapsulation (GRE) and UDP tunnels support the MPLS protocol for
both IPv4 and IPv6 traffic. You can configure encapsulation and
deencapsulation for the GRE and UDP tunnels. To allow the MPLS traffic on
the UDP tunnels, include the mpls port-number statement at the [edit
forwarding-options tunnels udp port-profile profile-name ]
hierarchy level. To allow the MPLS traffic on the GRE tunnels, include the
mpls statement at the [edit interfaces fti0 unit unit
family ] hierarchy.
[See Flexible Tunnel Interfaces
Overview.]
-
Egress Filter based encapsulation. For an outgoing packet matching the filter
term, the packet is encapsulated inside an IP + GRE header as specified by the
tunnel configuration. IP lookup is performed on the outer header and packet is
forwarded accordingly. The IP lookup for GRE-encap capable route is limited to
the implicit default routing-instance.
[See Understanding Filter-Based Tunneling Across
IPv4 Networks.]
-
Egress Filter routing instance action- Support for configuring output filter
action with non-default routing instance or a specified routing instance.
[See Firewall Filter Terminating
Actions.]
-
Ingress Filter based decapsulation by using firewall filters for GRE and UDP
tunnels
[See Configuring a Filter to De-Encapsulate GRE
Traffic and decapsulate (Firewall
Filter.]
|
Junos Telemetry Interface
|
Junos telemetry interface (JTI) supports new platform sensors for PTX10008. You can
export platform-specific software and chassis component statistics using remote
procedure call (gRPC) services, gRPC Network Management Interface (gNMI) services,
and UDP transport. New xpaths are added in the YANG Data Model. For a complete list
of xpaths supported by the device, see Junos YANG Data Model Explorer.
[See Junos YANG Data Model Explorer.]
|
Packet Forwarding Engine's In-Band Network Telemetry for PTX routers. The Junos EVO
Packet Forwarding Engine introduces a framework in the data plane, called In-Band
Network Telemetry (INT), which collects and reports network state information,
without the intervention of the control plane. The header in the INT model has
telemetry instructions that instruct an INT-capable device the state it must
collect. The network state information is exported by the data plane either to the
telemetry monitoring system or is written into the packet.
INT has source, transit and sink support. INT source embeds the INT metadata in the
packet and sink collect the metadata from the data packet for processing. We do not
support INT source, sink and all INT application modes on PTX10008 routers. Juniper
JNP10K-LC1301-36DD line card on PTX10008 supports only INT transit node in Junos OS
Evolved Release 24.4R1. Among the three INT application modes INT-XD, INT-MX, and
INT-MD, Juniper JNP10K-LC1301 line card on PTX10008 supports only INT-MD mode and
INT as a transit node.
The set forwarding-options configuration statement is updated with
a new inband-telemetry option, to enable or disable this
feature.
[See Junos YANG Data Model Explorer.]
|
Layer 2 Features
|
Support for Q-in-Q tunneling (PTX10008).
[See Configuring Q-in-Q Tunneling and VLAN Q-in-Q
Tunneling and VLAN Translation.]
|
-
Support for basic Layer 2 features (PTX10008). The PTX10008 router
supports the following Layer 2 basic learning, bridging and flooding features:
-
Enterprise-style bridging (support both trunk and access mode)
-
Service provider-style bridging (also known as sub-interface mode)
-
BPDU block/filter
-
xSTP
-
Handle BUM (broadcast, unknown unicast and multicast) traffic, including
split horizon
-
MAC learning and aging
-
Static MAC addresses
-
Trunk port and VLAN membership
-
802.1Q EtherType—8100
-
802.1Q VLAN tagging—Single tagging with normalized to bridge domain tag at
ingress
-
Clearing all MAC address information
-
Global MAC limit
-
Global source MAC aging time
-
MAC moves
-
LACP and LLDP
-
Disabling MAC learning at global and interface level
-
Native VLAN ID for Layer 2 logical interfaces
-
Single VLAN-tagged Layer 2 logical interfaces
-
Interface statistics
Note: The show ethernet-switching statistics command and
child logical interface statistics for aggregated Ethernet are not
supported.
-
Flexible Ethernet services
Note: Enterprise-style Layer 2 logical interfaces aren't
allowed under the flexible-ethernet-services encapsulation.
-
Virtual switch
-
Persistent MAC learning (sticky MAC)
-
Service provider bridging:
-
Support for interface MAC limit action. You can specify the action (drop, drop
and log, log, or shut down) that Junos OS Evolved takes when packets with new
source MAC addresses are received after the MAC address limit is reached.
[See Configuring MAC Limiting and packet-action.]
|
Layer 3 Features
|
-
Support for 256-way ECMP. You can configure a maximum of 256 equal-cost
multipath (ECMP) next hops for external BGP (EBGP) peers. This feature increases
the number of direct BGP peer connections, which improves latency and optimizes
data flow. However, we support 128 ECMP next hops for MPLS routes. Note that we
do not support consistent load balancing (consistent hashing) for IPv4 or IPv6
with this feature.
[See Understanding BGP Multipath.]
-
Support for the following Layer 3 forwarding features for IPv4, IPv6, MPLS,
LAG, ECMP, MTU checks, ICMP, OSPF, IS-IS, ARP, NDP, BGP, BFD, LACP, LDP, RSVP,
LLDP, VRF-lite, TTL expiry, IP options, IP fragmentation, DDoS
-
BFD support, including:
-
BGP flowspec signaling support. BGP flow specification.
BGP
can carry flow-specification network layer reachability information (NLRI)
messages on PTX10008 devices with LC1201, LC1202 and LC1301 line
cards.. Propagating firewall filter information as part of BGP
enables you to propagate firewall filters against denial-of-service (DOS)
attacks dynamically across autonomous systems. The following match conditions
are not supported:
-
ICMP codes alone [inet/inet6]
-
Source/destination prefix with offset for inet6
-
Flow label for inet6 fragment [for inet6]
Junos OS Evolved running on this router doesn't support the traffic marking
action. To configure flow routes statically, configure the match conditions and
actions at the [edit routing-options] hierarchy level.
|
MACsec
|
Media Access Control Security (MACsec) is supported on physical interfaces.
[See Understanding Media Access control Security
(MACsec).]
|
Support for Media Access Control Security (MACsec) bounded delay protection.
[See Configuring Bounded Delay Protection.]
|
Managing Devices
|
Support for additional RPCs for the gNOI certificate management (cert) service.
Junos OS Evolved supports the following gRPC Network Operations Interface (gNOI)
cert service RPCs:
-
CanGenerateCSR() —Query if the target device can generate a certificate signing
request (CSR) with the specified key type, key size, and certificate type.
-
RevokeCertificates()—Revoke certificates on the target device.
[See gNOI Certificate Management (Cert)
Service .]
|
MPLS
|
-
We support the following MPLs features:
-
Support for MPLS FRR—MPLS fast reroute (FRR) provides faster convergence
time (less than 50 milliseconds) for RSVP tunnels. The Routing Engine
creates backup paths and the Packet Forwarding Engine installs the
backup-path labels and next hops.
[See Fast Reroute Overview.]
-
Support for 256-way ECMP. You can configure a maximum of 256 equal-cost
multipath (ECMP) next hops for external BGP (EBGP) peers. This feature
increases the number of direct BGP peer connections, which improves latency
and optimizes data flow. However, we support 128 ECMP next hops for MPLS
routes. Note that we do not support consistent load balancing (consistent
hashing) for IPv4 or IPv6 with this feature.
[See Understanding BGP Multipath.]
-
Support for MPLS features,including:
-
CLI support for monitoring MPLS label usage
-
Inline MPLS and IPv6 lookup for explicit null
-
32,000 transit LSPs
-
Explicit null support for MPLS LSPs
-
MPLS Label Block Configuration
-
MPLS over untagged Layer 3 interfaces
-
MPLS OAM - LSP ping
-
JTI: OCST: MPLS operational state streaming (v2.2.0)
-
2000 ingress LSP support
-
2000 egress LSP support
-
Entropy label support
-
MPLS: JTI: Junos telemetry interface MPLS self-ping, TE++, and misc
augmentation
-
LDP, including:
- Configurable label withdraw delay
-
Egress policy
-
Explicit null
-
Graceful restart signaling
-
IGP synchronization
-
Ingress policy
-
IPv6 for LDP transport session
-
Strict targeted hellos
-
Track IGP metric
-
Tunneling (LDP over RSVP)
-
RSVP++
-
RSVP-TE, including:
-
Bypass LSP static configuration
-
Ingress LSP statistics in a file
-
RSVP-TE hitless-MBB with no artificial delays
-
32,000 transit LSPs
-
Auto bandwidth
-
Class-based forwarding (CBF) with 16 classes
-
CBF with next-hop resolution
-
Convergence and scalability
-
Graceful restart signaling
-
JTI interface statistics and LSP event export
-
LSP next-hop policy
-
LSP self-ping
-
MPLS fast reroute (FRR)
-
MTU signaling
-
Optimize adaptive teardown
-
Node/link protection
-
Refresh reduction
-
Soft preemption
-
Shared Risk Link Group (SRLG)
-
Static LSPs with IPv4 nexthop, IPv6 next-hop, and IPv6 nexthop with
next-table support for bypass
-
Traffic engineering, including:
-
TE++: Dynamic ingress LSP splitting
-
Traffic engineering extensions (OSPF-TE and ISIS-TE)
-
Traffic engineering options: bgp ,
bgp-igp , bgp-igp-both-ribs , and
mpls-forwarding
[See MPLS Applications User Guide .]
-
Segment routing support. You can configure the following Source Packet
Routing in Networking (SPRING) or segment routing features on the
router:
-
MPLS (segment routing using IS-IS):
-
BGP Link State (BGP-LS):
-
BGP:
-
Binding segment identifier (SID) for segment routing–traffic
engineering (SR-TE)
-
Binding SID for SR-TE
[draft-previdi-idr-segment-routing-te-policy]
-
Programmable routing protocol process APIs for SR-TE policy
provisioning
-
Static SR-TE policy with mandatory color specification
-
Static SR-TE policy without color specification
-
IS-IS:
-
Adjacency SID
-
Advertising maximum link bandwidth and administrative color without
RSVP-TE configuration
-
Anycast and prefix SIDs
-
Configurable segment routing global block (SRGB)
-
Node and link SIDs
-
Segment Routing Mapping Server (SRMS) and client
-
Topology-independent loop-free alternate (TI-LFA):
-
Link and node protection for IPv4 addressing (not required for
IPv6 prefixes)
-
Link and node protection for IPv4 addressing (required for IPv6
prefixes)
-
Protection for SRMS prefixes
-
OSPF:
-
BGP IPv4 labeled-unicast resolution over:
-
BGP IPv4 SR-TE with IPv4 segment routing using IS-IS and OSPF
-
Non-colored IPv4 SR-TE with segment routing using IS-IS and
OSPF
-
Static colored IPv4 SR-TE with segment routing using IS-IS and
OSPF
-
• BGP Layer 3 VPN over:
-
BGP-triggered dynamic SR-TE colored tunnels
-
Class-based forwarding and forwarding table policy LSP next-hop
selection among non-colored SR-TE LSPs
-
First-hop label support for SID instead of an IP address
-
Path specification using router IP addresses (segment routing segment
list path ERO support using IP address as next hop and loose mode)
-
SR-TE color mode:
-
Static LSPs with member-link next hops for aggregated Ethernet bundles
(also known as adjacent SID per LAG bundle or aggregated Ethernet member
link)
[See Understanding Source Packet Routing in
Networking (SPRING).]
-
Layer 2 VPN feature support includes:
-
Transport of Layer 2 frames over MPLS (LDP signaling)
-
Layer 2 VPNs over tunnels (BGP signaling)
-
Simple Ethernet and VLAN-based cross-connect (also known as
connections)
-
Local and remote switching
-
Ethernet and VLAN CCC
-
Single-tagged CCC logical interfaces
-
Control word
-
Regular and aggregated Ethernet interfaces
-
Layer 2 protocol pass-through
-
Layer 2 circuit backup interface and backup neighbor
-
Layer 2 circuit statistics and CoS
-
VCCV with type 2 and type 3
[See Layer 2 VPNs and VPLS User Guide for Routing
Devices and TCC Overview.]
-
VLAN ID lists for Layer 2 Circuits. VLAN ID lists allow you to link multiple
VLAN ID's to a single logical interface for Layer 2 traffic.
[See vlan-id-list (Ethernet VLAN Circuit),
vlan-id-list, and Configuring VLAN Identifiers for VLANs and VPLS
Routing Instances.]
-
MPLS-based Layer 3 VPNs support includes:
-
MPLS over Layer 3 VLAN-tagged subinterfaces
-
Per-next-hop label allocation
-
Mapping of the label-switched interface (LSI) logical interface label to
the VPN routing and forwarding (VRF) routing table using the
vrf-table-label statement
-
ICMP tunneling and MPLS traceroute
-
Disabling time-to-live (TTL) decrementing using
no-propagate-ttl
[See Layer 3 VPNs Feature Guide for Routing
Devices.]
-
Support for IP-over-IP encapsulation to facilitate IP overlay construction over
an IP transport network. An IP network contains edge devices and core devices.
To achieve higher scale and reliability among these devices, use an overlay
encapsulation to logically isolate the core network from the external network
that the edge devices interact with.
Static configuration or a BGP protocol configuration is used to distribute
routes and signal dynamic tunnels. The dynamic-tunnels configuration creates
IP-over-IP encapsulation-only tunnels in the Packet Forwarding Engine.
The following are not supported:
-
Dynamic tunnel de-encapsulation operation
-
Next-hop-based statistics for dynamic tunnels
-
IP fragmentation at tunnel start point and path MTU discovery for IPv4/IPv6
[See Next-Hop-Based Dynamic Tunneling Using
IP-Over-IP Encapsulation .]
-
Redistribution of IPv4 routes with IPv6 next hop into BGP. Devices can forward
IPv4 traffic over an IPv6-only network, which generally cannot forward IPv4
traffic.
[See Understanding Redistribution of IPv4 Routes
with IPv6 Next Hop into BGP.]
-
Link delay advertisement- You can get the measurement of various performance
metrics in IP networks, which helps to distribute network-performance
information in a scalable fashion.
[See How to Enable Link Delay Measurement and
Advertising in IS-IS.]
|
Multicast
|
-
Support for multicast-only fast reroute (MoFRR) for both IPv4 and IPv6 traffic
flows. MoFRR is supported for PIM sparse mode (SM) and sourcespecific multicast
(SSM) modes only. Support does not extend to Multipoint LDP-based MoFRR.
[See Understanding Multicast-Only Fast
Reroute.]
-
Bidirectional Protocol Independent Multicast for multicast traffic.
See pim-snooping
-
Support for RSVP-based and LDP-based point-to-multipoint (P2MP) LSPs with
graceful restart. In addition, the router supports IP unicast traffic in a
label-edge router (LER) role and both IP unicast and multicast traffic in a
label-switching router (LSR) role.
[See Point-to-Multipoint LSP
Configuration]
-
Support for MPLS features P2MP ping and P2MP LSPs traceroute. MPLS ping and
traceroute provide the mechanism to detect data-plane failure and isolate faults
in the MPLS network. The traceroute or ping is initiated to validate LSP paths
on P2MP.
[See MPLS Applications User Guide.]
-
Optimized fast branch updates. The method of making fastbranch updates to a
multicast replication tree has been refined. Now, any membership changes in the
tree trigger fast makebefore- break (FMBB) re-optimization of the tree and
ensure that there is no traffic loss.
[See Multicast Shortest-Path Tree.]
-
Multicast support for Next-Generation MVPN (NG-MVPN) including IR, RSVP-P2MP,
and LDP-P2MP provider tunnel, inclusive and Selective PMSI tunnel,
Rendezvous-point tree (RPT)-shortest-path tree (SPT) mode, turnaround provider
edge (PE) device, RP mechanisms such as auto rendezvous point (RP), bootstrap
router (BSR), and embedded RP.
[See Multiprotocol BGP MVPNs Overview, Understanding Next-Generation MVPN
Concepts, and Understanding Next-Generation MVPN Control
Plane.]
-
Multicast support for Next-Generation MVPN (NG-MVPN) including IR, RSVP-P2MP,
and LDP-P2MP provider tunnel, inclusive and Selective PMSI tunnel,
Rendezvous-point tree (RPT)-shortest-path tree (SPT) mode, turnaround provider
edge (PE) device, RP mechanisms such as auto rendezvous point (RP), bootstrap
router (BSR), and embedded RP.
[See Multiprotocol BGP MVPNs Overview, Understanding Next-Generation MVPN
Concepts, and Understanding Next-Generation MVPN Control
Plane.]
|
-
MVPN BIER with MPLS encapsulation- Junos OS Evolved supports the Bit Index
Explicit Replication (BIER) architecture to simplify control and forwarding
planes by eliminating the need for multicast trees and per-flow states. With
BGP-MVPN as an overlay, you can configure BIER-enabled provider tunnels for
multicast VPNs.
[See BIER Overview and bier.]
-
IS-IS as routing underlay for BIER. Junos OS Evolved supports the advertisement
of BIER information of one or more BIER sub-domains using IS-IS as the IGP
underlay. Key BIER information such as BFR IDs and BFR prefixes in each
subdomain are flooded through the IS-IS domain to generate the BIER forwarding
table.
[See IS-IS Extension for BIER and bier-sub-domain (Protocols IS-IS).]
|
Network Management and Monitoring
|
-
Local and Remote Port mirroring:
-
Local port mirroring is used to copy the packet entering or leaving the
system or port and send sampled packet through pre-designated port provided
by configuration to remote devices/servers. Applications running on servers
can analyze these packets and use the results based on the requirement.
-
Remote Port-Mirroring is used to send a sampled packet to remote
destination provided by configuration. Packet will be encapsulated in a GRE
header. Remote port mirroring will make use of the Flexible tunnel interface
(FTI), to encapsulate and send the packets out of the box. This feature will
also provide an option for configuring policer for the given instance, so
that rate of sampling can be policed.
-
Port Mirror support for EVPN-VXLAN
-
Filter and mirror ingress and egress traffic on any network port to CPU- Junos
devices support filtering and mirroring incoming and outgoing packets, sending
those packets to the CPU, and saving them into a file. This feature, on-device
packet capture, can help you with protocol and application analysis, debugging,
troubleshooting, network forensics, audit trails, and network attack detection.
On-device packet capture (or “self-mirroring”) sends the sampled copy to a CPU
and writes the copy into a packet capture (.pcap) file. The process does not
require you to use any device connected to your network device.
[See On-Device Packet Capture.]
|
|
Support for additional RPCs for the gNOI certificate management (cert) service.
Junos OS Evolved supports the following gRPC Network Operations Interface (gNOI)
cert service RPCs:
-
CanGenerateCSR() —Query if the target device can generate a certificate signing
request (CSR) with the specified key type, key size, and certificate type.
-
RevokeCertificates()—Revoke certificates on the target device.
[See gNOI Certificate Management (Cert) Service
.]
|
-
Up maintenance association end points (MEPs) in distributed periodic packet
management (PPM)
-
Distributed Y.1731 on synthetic loss measurement (SLM), delay measurement (DM),
and loss measurement (LM)
-
Down MEPs on bridges, circuit cross-connect (CCC) , and Ethernet VPN (EVPN)
-
Distributed session support for connectivity fault management (CFM) on
aggregated Ethernet
-
Enhanced CFM mode
-
IPv4 (inet) support for Data Model (DM) and synthetic loss message (SLM)
-
Action profile for marking a link down, except for EVPN and bridge up MEP
-
LM colorless mode
-
DM and LM on aggregated Ethernet if all active child links are on the same
Packet Forwarding Engine
-
Supported CFM protocol data units (PDUs), as follows:
-
Continuity check messages (CCM)
-
LBM
-
LBR
-
Link Trace Message (LTM)
-
Link Trace Reply (LTR)
-
Delay measurement message (DMM)
-
Delay measurement reply (DMR)
-
LMM
-
LMR
-
Synthetic loss message (SLM)
-
Synthetic loss reply (SLR)
-
Enterprise and service provider configurations
-
VLAN normalization
-
VLAN transparency for CFM PDUs
-
CoS forwarding class (FC) and CoS packet loss priority (PLP) for CFM
-
CFM session on child physical interface in distributed mode
-
SNMP
-
Chassis ID or Send ID type, length, and value
-
Trunk mode
-
Maintenance association intermediate point (MIP)
|
Platform and Infrastructure
|
Support for SYNCE timing, SYNCE over LAG, and Timing SNMP and MIB ( SYNCE)
|
Platform resiliency support. PTX10008 routers with specific line cards support
platform resiliency. Resiliency enables the router to handle failures and faults
related to the hardware components such as line cards, switch fabric, control
boards, fan trays, fan tray controllers, and power supply units. Fault handling
includes detecting and logging the error, raising alarms, sending SNMP traps,
providing indication about the error through LEDs, self-healing, and taking
components out of service.
[See show system errors active.]
|
Segment Routing
|
-
See How to Enable SRv6 Network Programming in IS-IS
Networks.]
-
Support for SRv6 network programming and Layer 3 Services over SRv6 in BGP. You
can configure BGP-based Layer 3 service over an SRv6 core. You can enable Layer
3 overlay services with BGP as the control plane and SRv6 as the data plane.
SRv6 network programming provides flexibility to leverage segment routing
without deploying MPLS.
[See Understanding SRv6 Network Programming and
Layer 3 Services over SRv6 in BGP.]
-
Operations, Administration and Management (OAM) ping support for segment
routing with IPv6 (SRv6) network programming. You can perform an OAM ping
operation for any SRv6 segment identifier (SID) whose behavior allows upper
layer header processing for an applicable OAM payload. As segment routing with
IPv6 data plane (SRv6) adds only the new type-4 routing extension header, you
can use the existing ICMPv6-based ping mechanisms for an SRv6 network to provide
OAM support for SRv6. Ping with O-Flag (segment header) is not supported.
[See ITU-T Y.1731 Ethernet Service OAM
Overview and How to Enable SRv6 Network Programming in IS-IS
Networks.]
-
Support for SRv6 traceroute. We support the traceroute mechanism for segment
routing for IPv6 (SRv6) segment identifiers. You can use traceroute for both UDP
and ICMP probes. By default, traceroute uses UDP probes. For ICMP probes, use
the traceroute command with the probe-icmp option.
[See How to Enable SRv6 Network Programming in IS-IS
Networks.]
-
SRv6 support for static SR-TE policy. You can configure static segment
routing–traffic engineering (SR-TE) tunnels over an SRv6 data plane. Use the
following configuration commands to enable SRv6 support:
-
For an SR-TE policy: set protocols source-packet-routing
srv6
-
For an SR-TE tunnel: set protocols source-packet-routing
source-routing-path lsp name srv6
-
For an SR-TE segment list: set protocols source-packet-routing
source-routing-path segment-list srv6
[See Understanding SR-TE Policy for SRv6
Tunnel.]
|
Support for SRv6 micro-SIDs or uSID. You can compress multiple SRv6 addresses into
a single IPv6 address (micro-SID).
[See Micro SID support in SRv6, micro-sid, and block.]
|
Services Applications
|
|
Software Installation and Upgrade
|
Support for ZTP using WAN interfaces.
[See See Zero Touch Provisioning.]
|
Additional feature support
|
Firewall filter support.
[See Firewall filter support.]
|
Policer and policer overhead interop support
[See Routing Policies, Firewall Filters, and Traffic
Policers User Guide.]
|