The following features have been added to JUNOS Release 9.2.
Following the description is the title of the manual or manuals to
consult for further information. For a complete list of manuals, see Table 3, Table 4, and Table 6.
- New profiles to support dynamic subscriber services (MX-series routers)—You can now use dynamic profiles to provide dynamic subscriber
services for broadband access applications. A new dynamic-profile hierarchy appears at the top level of the JUNOS CLI structure and
contains many JUNOS configuration statements that you would normally
define statically. These statements appear in the following CLI subcategories
within the dynamic-profile hierarchy:
- interfaces (supporting static VLAN and LAG on
Ethernet interfaces and static IP demux interfaces)
- protocols (supporting IGMP configuration)
- class-of-service (supporting traffic classification
and scheduling)
A dynamic profile is a set of characteristics that are
defined through statement settings and assigned to interfaces. Through
the use of filters and triggered by a client running DHCP, dynamic
profiles enable dynamic configuration of individual client access
as well as certain dynamic services that can be activated, modified,
and deactivated using RADIUS COA (Change Of Authorization) messaging.
[Subscriber Access Configuration]
- RADIUS MSCHAPv2
protocol support for administrator authentication, password aging,
and update—Adds support for login-time password
changing using telnet, SSH, HTTP (J-Web), and HTTPS (J-Web) access
methods. To use this feature, configure the password-protocol statement at the [edit system radius-options] hierarchy
level. Configuring MSCHAP-V2 enables the JUNOS software to communicate
with the RADIUS server regardless of access method. You can enable
MSCHAP-V2 on an IP-address–specified server by including the mschap-v2 statement at the [edit system radius-servers 1.1.1.1
password-protocol] hierarchy level. [System Basics]
- IGMP dynamic profiles—You can configure IGMP to function with dynamic profiles.
Dynamic profiles act as templates that enable the router to dynamically
create, update, or remove a configuration for DHCP clients. When the
router detects a DHCP client connecting to the network, the router
uses the dynamic profile to configure the client with IGMP attributes.
These attributes enable the client to communicate over the multicast
network. [Subscriber Access Configuration]
- RADIUS dynamic
request support (MX-series platforms)—Enables
the router to receive and support RADIUS-initiated dynamic requests,
including change of authorization (CoA) requests and disconnect requests.
The router updates existing client sessions based on modified or additional
RADIUS VSAs in CoA requests. The router immediately terminates specific
user sessions based on dynamic disconnect messages from RADIUS servers.
The router also supports RADIUS-based dynamic service activation and
deactivation during subscriber login.
To configure RADIUS dynamic request support, you create an access
profile that specifies the IP addresses of RADIUS dynamic-request
servers. To specify the IP addresses of the RADIUS servers from which
the router accepts dynamic requests, include the authentication-server statement at the [edit access profile profile-name radius] hierarchy level. The router uses this list of specified
servers for both authentication and dynamic request operations. You
can specify the addresses of multiple RADIUS servers. The router listens
on UDP port 3799 for dynamic requests.
To display the RADIUS dynamic request configuration, issue the show network-access aaa statistics dynamic-request operational
command. [Subscriber Access]
- Dynamic profiles
support by extended DHCP local server and extended DHCP relay agent
(MX-series platforms)—The extended DHCP local
server and the extended DHCP relay agent enable dynamic profiles to
be attached to interfaces during subscriber login. Dynamic profiles
can be attached to all interfaces or to specific groups of interfaces.
For example, when a subscriber logs in, the extended DHCP local server
or relay agent attaches the specified profile to a particular group
of interfaces. The dynamic profile in turn configures parameters for
the interface, such as creating a demux interface and applying QoS
parameters.
To configure the extended DHCP local server to support dynamic
profiles, include the dynamic-profile statement at the [edit system services dhcp-local-server] hierarchy level. For
a group-specific configuration, include the dynamic-profile statement at the [edit system services dhcp-local-server group group-name] hierarchy level.
To configure the extended DHCP relay agent to support dynamic
profiles, include the dynamic-profile statement at the [edit forwarding-options dhcp-relay] hierarchy level. For a
group-specific configuration, include the dynamic-profile statement at the [edit forwarding-options dhcp-relay group group-name] hierarchy level. [Subscriber
Access]
- Remote tracing—JUNOS software now supports remote tracing, which greatly
reduces use of the router's internal storage for tracing and is analogous
to remote system logging:
- To enable system-wide remote tracing, include the destination-override syslog host statement at the [edit
system tracing] hierarchy level. This specifies the remote host
running the system log process (syslogd), which collects the traces.
Traces are written to one or more files on the remote host per the
syslogd configuration in /etc/syslog.conf.
- To override the system-wide remote tracing configuration
for a particular process, include the no-remote-trace statement
at the [edit process-name traceoptions] hierarchy. When no-remote-trace is enabled, the process
does local tracing.
- To collect traces, use the local0 facility as
the selector in /etc/syslog.conf on the remote host. If your
system log server supports parsing hostname and program name, you
can separate traces from various processes into different files by
including the process name or trace-file name, if it is specified
at the [edit process-name traceoptions file] hierarchy level, in the “program” field in /etc/syslog.conf. To separate traces from different routers into different files,
include the hostname of the router in the “hostname” field
in /etc/syslog.conf. For more information, see man syslog.conf on the remote host.
- The following processes are currently supported:
- chassis-control process (chassisd)
- event-processing process (eventd)
- class-of-service process (cosd)
- adaptive-services process (spd)
[System Basics]
- Per interface DHCP
lease limits (MX-series platform)—The extended
DHCP local server and the extended DHCP relay can be configured to
set a limit for the number of clients allowed per interface. The limit
is specified by either a local configuration or by Juniper Networks
VSA 26-143 during client login. Once an interface reaches the limit,
no additional clients are accepted on that interface. However, if
the number of clients subsequently falls below the limit, additional
clients can again be accepted. You can set a limit for a specific
group of interfaces, or you can set a global limit for all interfaces.
A group-specific limit takes precedence over the global limit, and
a VSA-configured limit takes precedence over a local configuration.
By default, there is no limit to the number of clients per interface.
To set a limit to the number of clients per interface:
- For DHCP local server support, include the overrides
interface-client-limit statement at the [edit system services
dhcp-local-server] or the [edit system services dhcp-local-server
group] hierarchy level.
- For DHCP relay agent support, include the overrides
interface-client-limit statement at the [edit forwarding-options
dhcp-relay] or the [edit forwarding-options dhcp-relay group] hierarchy level.
[Subscriber Access]
- Enhancement
to IPSec PIC redundancy support—Improves high
availability for IPSec functionality on services PICs by dispensing
with the requirement to renegotiate security associations (SAs) during
warm standby PIC switchover. Instead, the warm standby feature has
been made stateful by periodically correlating the working state of
the PIC to the Routing Engine, which should lessen the downtime during
switchover. To retain the previous behavior, in which the router renegotiates
the IPSec SAs on warm standby PIC switchover, include the clear-ipsec-sas-on-pic-restart statement at the [edit services ipsec-vpn] hierarchy level.
[Services Interfaces]
- Dynamic flow capture enhancements—Allow you to
set thresholds that regulate dynamic flow capture processing in the
following areas:
- Minimum priority for each control source in a capture
group—To specify this optional value, include the minimum-priority statement at the [edit services dynamic-flow-capture capture-group client-name control-source identifier] hierarchy level.
- Bandwidth limits per content destination—Allow you
to set a series of congestion limits in bits per second, including
both a soft limit range in which congestion notifications are sent
and a hard limit range in which lower-priority criteria are purged.
To specify the thresholds, include either the soft-limit and soft-limit-clear statements or the hard-limit-target and hard-limit statements at the [edit services dynamic-flow-capture
capture-group client-name control-source identifier] hierarchy level. You can include one
or both of these optional threshold pairs in a configuration.
- Maximum number of duplicate packet sets—Limit the
number of duplicate packet sets the DFC PIC can send from a single
input. To specify the limit, include either the g-max-duplicates statement at the [edit services dynamic-flow-capture] level
for global regulation or the max-duplicates statement at
the [edit services dynamic-flow-capture capture-group client-name] level. You can also include the g-duplicates-dropped-periodicity or duplicates-dropped-periodicity statement at the same hierarchy levels to regulate how often notifications
are sent when duplicate packets are limited by the threshold. [Services Interfaces]
- Reassemble fragmented tunnel packets on services interfaces (M-series
platforms except M320 routers)—Supports reassembly
of postencapsulation fragmented generic routing encapsulation (GRE)
tunnel packets. To enable this feature, include the reassemble-packets statement at the [edit interfaces gr-fpc/pic/port unit logical-unit-number] hierarchy level. To enable postencapsulation
fragmentation of GRE-encapsulated packets when the packet exceeds
the MTU of the egress interface, include the allow-fragmentation statement at the [edit interfaces gr-fpc/pic/port unit logical-unit-number tunnel] hierarchy level. To disable
fragmentation of these packets, include the do-not-fragment statement at the same level. The Flags field in the show interfaces gr-fpc/pic/port command output displays the configured
setting. [Services Interfaces, Interfaces
Command Reference]
 |
Note:
Whenever you configure allow-fragmentation on a GRE
tunnel, you must also include either the tunnel key or the clear-dont-fragment-bit statement. This configuration enables the router to send affected
packets to the PIC so that the correct IP header can be placed in
the fragments. Otherwise, on the reassembly side some packets might
be lost when fragments arrive in the PIC out of sequence at high
speeds.
|
- Enhancement to IPSec
dead peer detection—Allows a services PIC to send
dead peer detection (DPD) hello messages to a remote peer regardless
of whether a backup remote gateway is configured for the tunnel. To
configure this feature, include the initiate-dead-peer-detection statement at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level.
[Services Interfaces]
- Support
for cflowd with VPNs—Adds support for collection
of flow statistics for sampled packets on flows in virtual private
networks (VPNs) when PIC-based sampling is enabled. No additional
CLI configuration is required. [Services Interfaces]
- Session mirroring
for voice sessions—The Packet Gateway Control
Protocol (PGCP) software allows you to mirror packets of selected
voice sessions. You can mirror up to seven copies of the original
packet and send the copies to one IPv4 destination. For a gate marked
for mirroring, both Real-Time Transport Protocol (RTP) and Real-Time
Control Protocol (RTCP) packets are mirrored. You can use session
mirroring to mirror IPv4 traffic. You can use session mirroring along
with IPSec to encrypt mirrored packets. Access to session mirroring
statements and commands is restricted to users with appropriate permission.
To configure permission to configure session mirroring, include
the permissions pgcp-session-mirroring-control statement
at the [edit system login class class-name] hierarchy level. To configure permission to view session mirroring
information, include the permissions pgcp-session-mirroring statement at the [edit system login class class-name] hierarchy level. To configure session mirroring, configure
the substatements at the [edit services pgcp session-mirroring] hierarchy level. To view whether session mirroring is active for
a specific gate, issue the show services pgcp gates gate-id gate-id session-mirroring command. [Multiplay
Solutions Guide, Services Interfaces, System Basics, System Basics and
Services Command Reference]
- Rate limiting for
PGCP traffic—The packet gateway provides a two-rate
policer that you can apply to the ingress traffic of any gate. The
policer allows you to configure:
- Sustained data rate
- Peak data rate
- Maximum burst size
You can configure these parameters for gate streams of
any protocol or for Real-Time Transport Protocol/ Real-Time Control
Protocol (RTP/RTCP) gate streams only. If the packet gateway controller
(PGC) specifies any of these parameters in PGCP messages, the packet
gateway (PG) uses the parameters in the PGCP message, and not the
parameters set with the router CLI. To configure these gate stream
parameters, include the statements at the [edit services pgcp
gateway gateway-name h248-properties traffic-management] hierarchy level. To display the traffic management values, issue
the show services pgcp flows extensive, show services
pgcp conversations extensive, and show services pgcp gates
gate-id gate-id extensive commands. [Multiplay Solutions Guide, Services Interfaces, System Basics and Services Command Reference]
- Symmetric control
association for PGCP—For control association between
the packet gateway (PG) and a packet gateway controller (PGC), you
define the address and port of the PG and the PGC. The packet gateway
always sends H.248 messages from the PG address and port configured
on the router. The PG uses the address and port configured for the
PGC when it sends registration messages to the PGC. If the registration
reply contains a ServiceChangeAddress message, the PG uses the new
address and port instead of the address and port configured in the
CLI. The PG accepts only H.248 messages that arrive from the PGC address
and port. All other messages are dropped. In the following cases—loss
of the PG-to-PGC connection, restarting of the PGCP services, or a
reboot of the router—the PG attempts to connect to the address
and port configured on the router. If needed, the PGC can reply with
a new ServiceChangeAddress message. [Multiplay Solutions
Guide]
- Selection
of NAT pools based on transport protocol—Extends
NAT pool specification to allow the option of selecting NAT pools
based on the transport protocol type. You can use this method of selecting
NAT pools only for locally controlled NAT pools. When you set up your
NAT pools, you specify a transport type that is made up of any combination
of TCP, UDP, and Real-Time Transport Protocol using Audio/Video profile
(RTP/AVP). The packet gateway selects the NAT pool by matching the
transport type portion of the local descriptor in H.248 messages to
the transport type in the NAT pool. To configure the transport type,
include the transport statement at the [edit services
nat pool pool-name pgcp] hierarchy level.
[Multiplay Solutions Guide, Services
Interfaces, System Basics and Services Command
Reference]
- Latch deadlock
detection—To detect latch deadlocks on a gate,
the packet gateway (PG) uses data inactivity detection. When a gate
is installed, the PG begins inactivity detection after a configurable
delay. There are two delays that you can configure: a delay for terminations
that do not include a latch event and a delay for terminations that
do include a latch event. Allowing you to configure both an inactivity
delay and a latch deadlock delay gives you more flexibility in managing
the PG. You can configure a very short delay for latch deadlock detection
and a longer delay for data inactivity.
When the delay expires, the PG checks whether any data packets
have passed through the gate. If no data has passed through the gate,
the PG sends a data inactivity notification to the PGC. You can suppress
the sending of the first data inactivity notification by turning off
the send-notification-on-delay toggle in the data inactivity
configuration. You can also specify that, instead of sending a data
inactivity notification, the PG sends either an FO/906 or an FO/910
ServiceChange command to the PGC. Once the PG sends a ServiceChange
command, the termination state becomes active, and the PG stops inactivity
checks for the termination.
The PG has a duration timer for each flow that specifies the
interval between PG checks for data inactivity. The PG starts the
duration timer when the delay timer expires. When the duration timer
expires, the PG checks for activity on the termination. If there has
been activity, the PG resets the timer.
To handle calls that are placed on hold, you can configure the
PG to stop inactivity detection when a gate action is set to drop.
When the call is resumed, the PG starts the delay timer and resumes
data inactivity detection.
To configure data inactivity detection, include the statements
at the [edit services pgcp gateway gateway-name data-inactivity-detection] hierarchy level. [Multiplay
Solutions Guide, Services Interfaces]
- RTP/RTCP drop
and forward gate operations—The drop and forward
behavior for RTP and Real-Time Control Protocol (RTCP) gates within
the same stream has changed. The StreamMode LocalDescriptor property
in H.248 messages can be used to change RTP mode without affecting
RTCP mode. Therefore, if an RTP gate goes into a drop state, the RTP
gate remains in a forward state. To view whether RTP/RTCP gates are
in drop or forward mode, issue the show services pgcp flows command. [System Basics and Services Command Reference]
- Hanging termination
detection for PGCP—A hanging termination occurs
when corresponding data on the packet gateway (PG) and the packet
gateway controller (PGC) is mismatched. A hanging termination consumes
resources that could be used for chargeable calls. To detect hanging
terminations, the PG periodically sends an event called a termination
heartbeat (hangterm/thb) to the PGC. If the data on the PGC does not
match the data on the PG, the PGC returns an error message to the
PG. The PGC is responsible for correcting mismatches in data. You
can set a timer that specifies the interval between the last message
exchanged for this termination and the generation of the termination
heartbeat event. The timer is reset by any messaging between the PGC
and the PG for the termination. Setting this timer activates hanging
termination detection. To set the timer, include the timerx statement at the [edit services pgcp gateway gateway-name h248-properties hanging-termination-detection] hierarchy level.
To deactivate hanging termination detection, set the timerx statement to 0. To view the configuration of hanging termination
detection, issue the show services pgcp active-configuration command. [Multiplay Solutions Guide, Services Interfaces, System Basics and Services
Command Reference]
- Priority and emergency
for PGCP—The packet gateway controller (PGC) can
set values for priority and emergency indicators in an H.248 context.
If the packet gateway receives commands with the priority and emergency
indicators set, it stores the priority and emergency values and adds
the values to AuditValue replies. The packet gateway does not free
resources for emergency and priority calls. [Multiplay Solutions
Guide]
- Audit selection
filters for PGCP—The AuditValue command in H.248
messages requests the current values of properties, events, signals,
and statistics associated with terminations. You can use the AuditValue
command to maintain synchronization between the PG and the PGC. An
AuditValue may request the contents of a descriptor or of a single
property, event, signal, or statistic. An AuditValue command can include
selection criteria so that the returned values are filtered based
on specified selection criteria. Previously, the software supported
only the equal sign (=) for audit selection criteria. The software
now supports the # character to indicate not equal to, and also supports
the less than (<) and greater than (>) signs. [Multiplay
Solutions Guide]
- Virtual packet gateways
(VPGs)—You can now associate more than one VPG
with a single service PIC. For performance purposes, you can configure
the maximum number of concurrent calls allowed on each VPG. To configure,
include the max-concurrent-calls statement at the [edit
services pgcp gateway gateway-name] hierarchy
level. To view the configuration of the maximum concurrent calls,
issue the show services pgcp active-configuration command.
[Multiplay Solutions Guide, Services
Interfaces, System Basics and Services Command
Reference]
- Services PIC redundancy
for PGCP—The PIC failover procedure for PGCP ensures
service continuity in case of a service PIC failure. If a services
PIC fails, the Routing Engine configures a redundant services PIC
with the same configuration as the PIC that failed (that is, the same
service sets, PGCP rules, NAT pools, and so forth). The software then
switches over to the new services PIC. The PGCP process (pgcpd) continues
to provide the PGCP services as if the services PIC had simply restarted.
When the failed services PIC recovers, it does not take over from
the redundant PIC. Rather, it stands by in case of a failover.
To configure redundancy, create a redundancy services PIC (rsp) interface and specify the primary and secondary services
PIC by including the primary and secondary statements
at the [edit interfaces interface-name redundancy-options] hierarchy level. To manually switch from the primary to the secondary
interface, issue the request interface interface-name switchover command. To manually revert from the secondary interface
to the primary interface, issue the request interface interface-name revert command. You can display the
status of the redundant services PICs by entering the show interfaces
redundancy command. [Multiplay Solutions Guide, Services Interfaces, Interfaces
Command Reference]
- Support for limiting
the number of prefixes accepted from a BGP peer—Enables
you to specify a limit to the number of prefixes received and accepted
by a policy on a BGP peering session. When the maximum number of
specified accepted prefixes is exceeded, a system log message is sent.
To specify a limit for the number of prefixes accepted on a BGP peering
session, include the accepted-prefix-limit maximum number statement at the [edit protocols bgp family inet | inet6
(any | flow | labeled-unicast | multicast | unicast)], [edit
protocols bgp group group-name family inet |
inet6 (any | flow labeled-unicast | multicast | unicast)],
or [edit protocols bgp group group-name neighbor address family inet | inet6 (any | flow | labeled-unicast
| multicast | unicast)] hierarchy levels. For number, specify a value from 1 through 4,294,967,295.
This feature also enables you to reset the BGP session and have
a system log message sent when the number of active prefixes exceeds
the configured limit. To specify the BGP session be reset when the
maximum number of active prefixes is reached, include the accepted-prefix-limit
teardown statement. Optionally, you can specify a percentage
value from 1 through 100 with the teardown statement to specify
that a system log message be sent when the number of prefixes exceeds
the specified percentage of the maximum number configured. By default,
any BGP session that is torn down is reestablished within a short
time. However, you can optionally specify that the session be kept
down for a specified amount of time by including the idle-timeout minutes statement with the teardown statement.
For minutes, you can specify a value
from 1 through 2400.
To prevent the BGP session from being reestablished until you
issue the clear bgp neighbor command, include the idle-timeout
forever statement with the teardown statement. The
operational mode commands show bgp summary, show bgp
neighbor, and show bgp group have been enhanced to display
the accepted route count. [Routing Protocols, Routing Protocols and Policies Command Reference]
- BGP graceful restart
helper mode enhancement—BGP graceful restart helper
mode is now enabled without requiring graceful restart to be configured.
In helper mode, a neighboring router assists in a restart. Helper
mode is not sustained during a graceful Routing Engine switchover
(GRES) event. A router can both act as a graceful restart helper and
be configured to support nonstop active routing. However, you cannot
configure graceful restart and nonstop active routing at the same
time at the [edit routing-options] hierarchy level (by including
the graceful-restart statement and the nonstop-routing statement, respectively). [High Availability]
- Support for route-filter-based
BGP outbound route filtering—Enables you to configure
a BGP peer to accept prefix-based outbound filters from remote peers
and perform outbound route filtering using the received filters. To
configure a BGP peer to accept prefix-based outbound route filters,
include the outbound-route-filter prefix-based accept (inet |
inet6) statement at the [edit protocols bgp], [edit
protocols bgp group group-name], or [edit protocols bgp group group-name neighbor address] hierarchy levels. The maximum number of
prefix-based outbound route filters that a BGP peer can accept is
5000. If a remote peer sends more than 5000 outbound route filters,
the additional filters are discarded and a system log message is sent.
Issue the new operational mode command show bgp neighbor orf
address detail to display statistics about the prefix-based outbound
route filters received from a peer. [Routing Protocols, Routing Protocols and Policies Command Reference]
- Support for multiarea
adjacency in OSPFv2—Enables you to configure a
single logical interface to belong to more than one OSPF area. This
allows the corresponding link to be considered an intra-area link
in multiple areas and to be preferred over other higher-cost intra-area
paths. As defined in RFC 5185, OSPF Multi-Area Adjacency, the area border routers establish multiple adjacencies belonging
to different areas over the same logical interface. Each multiarea
adjacency is announced as a point-to-point unnumbered link in the
configured area by the routers connected to the link. To configure
a logical interface to belong to another area, include the secondary statement at the [edit protocols ospf area area-id interface interface-name] hierarchy level.
Multiarea adjacency is also supported for routing instances and logical
routers. Any logical interface not configured as a secondary interface
for an area is treated as primary interface for that area. A logical
interface can be configured as primary interface only for one area.
For any other area for which you configure the interface, you must
configure it as a secondary interface.
The operational mode command show ospf interface now
includes an area area-name option to
display output only for interfaces that belong to the specified area.
In addition, the output for the show ospf interface detail and show ospf neighbor commands has been enhanced to display
information about secondary interfaces. [Routing Protocols, Routing Protocols and Policies Command Reference]
- 802.1ad provider
bridge support on MX-series routers—A provider
network can bridge the customer Spanning Tree Protocol (STP) bridge
protocol data unit (BPDU) packets between customer sites. Simultaneously,
the provider network can prevent forwarding loops using STP in the
provider network. To configure an interface to tunnel customer STP
BPDU packets, include the bridge-type statement and specify
the provider-edge option at the [edit protocols rstp] hierarchy level. To configure an interface to participate in the
provider Rapid Spanning Tree Protocol (RSTP) instance, include the bridge-type statement and specify the provider-core option at the [edit protocols rstp] hierarchy level. [Routing Protocols]
- Support for multiple
address families in OSPFv3—Enables you to configure
OSPFv3 to support unicast IPv4, multicast IPv4, and multicast IPv6,
in addition to unicast IPv6. The JUNOS software provides support
to advertise address families other than unicast IPv6 in OSPFv3 by
mapping each family to a separate realm as defined in Internet draft draft-ietf-ospf-af-alt-06.txt, Support for Address
Families in OSPFv3. Each realm maintains a separate set
of neighbors and link-state database. To configure a realm for unicast
IPv4, multicast IPv4, or multicast IPv6, include the realm (ipv4-unicast
| ipv4-multicast | ipv6-multicast) statement at the [edit
protocols opsf3] hierarchy level. Realms are also supported for
routing instances and logical routers. You continue to configure the
default IPv6 unicast address family directly under the [edit protocols
ospf3] hierarchy level.
The following operational mode commands now include a realm realm-name option to display information about a
specified realm: clear ospf3 neighbor, clear ospf3 database, clear ospf3 statistics, clear ospf3 grace-lsa, show ospf3 overview, show ospf3 database, show ospf3 interface, show ospf3 neighbor, show
ospf3 route, show ospf3 statistics, and show ospf3
log. In addition, the show ospf3 neighbor instance all command displays information about all configured realms [Routing Protocols, Routing Protocols and Policies
Command Reference]
