These release notes accompany Release 10.4R1 of the Junos operating system (Junos
OS). They describe device documentation and known problems with the software. Junos
OS runs on all Juniper Networks M Series, MX Series, and T Series routing platforms, SRX
Series Services Gateways, J Series Services Routers, and EX Series Ethernet Switches.
You can also find these release notes on the Juniper Networks Junos OS Documentation
Web page, which is located at http://www.juniper.net/techpubs/software/junos.
Contents
Junos OS Release Notes for Juniper NetworksM Series Multiservice Edge Routers,
MX Series Ethernet Service Routers, and T Series Core Routers . . . . . . . . . . . . 6
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series
Junos OS Release Notes for Juniper Networks M Series Multiservice Edge Routers, MX
Series Ethernet Service Routers, and T Series Core Routers
•
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series
Routers on page 6
•
Changes in Default Behavior and Syntax in Junos OS Release 10.4 for M Series, MX
Series, and T Series Routers on page 37
•
Issues in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers on page 48
•
Errata and Changes in Documentation for Junos OS Release 10.4 for M Series, MX
Series, and T Series Routers on page 66
•
Upgrade and Downgrade Instructions for Junos OS Release 10.4forM Series, MX Series,
and T Series Routers on page 70
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
The following features have been added to Junos OS Release 10.4. Following the
description is the title of the manual or manuals to consult for further information.
Class of Service
•
Hierarchical policer functionality extended to Modular Interface Cards (MICs) (MX
Series routers)—Provides hierarchical policer feature parity with Enhanced Intelligent
Queuing (IQE) PICs. This is useful in provideredge applications using aggregate policing
for general traffic and when applying a separate policer for premium traffic on a logical
or physical interface.
Hierarchical policing on MICs supports the following features:
•
Ingress traffic is first classified into premium and non-premium traffic before a policer
is applied.
•
The hierarchical policer contains two policers: premium and aggregate.
Premium trafficis policed by both the premium policer and the aggregate policer. While
the premium policer rate-limits premium traffic, the aggregate policer only decrements
the credits but does not drop packets. Non-premium traffic is rate-limited by the
aggregate policer only, resulting in the following behavior:
•
Premium trafficis assured to have the bandwidth configuredforthe premium policer.
•
Non-premium traffic is policed to the specified rate limit.
The logical-interface-policer and physical-interface-policerstatements provide additional
hierarchical policer parameters beyond those of the IQE PICs.
You can apply the policer at the inet, inet6, or mpls family level, as follows:
[edit interfaces ge-0/1/0 unit 0 family (inet | inet6 | mpls)]
input-hierarchical-policer Test-HP;
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
By making a hierarchical policer a logical-interface-policer, you can achieve aggregation
within a logical interface. A hierarchical policer configured as a physical-interface-policer
supports aggregation within a physical interface. Please note that you still apply the
hierarchical policer at the interface and traffic of the families that do not have the
hierarchical policer will be policer. This is different from IQE PICs, where you apply a
hierarchical policer at the logical or physical interface.
For hierarchical policing of all traffic through a logical interface, a hierarchical policer
can be made a logical-interface-policerand applied to all families in the logical interface.
Similarly, you can achieve aggregation at the physical interface level.
[Network Interfaces, Class of Service, Policy]
•
DSCP classification for VPLS at the ingress PE (M320 with Enhanced Type III FPC
and M120)—Enables you to configure DSCP classification for VPLS at an ingress PE
for encapsulation types vlan-vpls (IQ2 or IQ2E PICs) or ATM II IQ PIC. To configure,
define the DSCP classifier at the [edit class-of-service classifiers dscp dscp-name]
hierarchy level and apply the DSCP classifier at the [edit interfaces at-fpc-pic-port
unit-logical-unit-numberclassifiers]hierarchylevel.The ATM interfacemust be included
in the routing instance.
[Class of Service]
Interfaces and Chassis
•
Ethernet encapsulation for ATM scheduler (M7i, M10i, M120, and M320 [with
Enhanced III FPC] routers)—Enables support for the configuration of an ATM scheduler
map on an Ethernet VPLS over a bridged ATM interface.
[Network Interfaces]
•
Synchronous Ethernet (SyncE) on MX80 routers and MX Series routers with
MPCs—Supportsthe Ethernet synchronization messaging channel (ESMC), G.8264-like
clock selection mechanism, and external clocking on MX80 routers and MX Series
routers with MPCs. Wireless backhaul and wireline transport services are the primary
applications for these features.
The following features are supported:
•
On MX80 routers and MX Series routers, MPCs based on G.8261 and G.8262. This
feature does not work on the fixed configuration version of the MX80 routers.
•
All Ethernet type ports are supported on MX80 routers and MX Series routers with
MPCs
•
ESMC support as per G.8264
•
CLI command selection of clock sources
•
Monitoring clock sources (maximum of two clock sources can be monitored
simultaneously)
Enhanced container interface allows ATM children for containers—M Series and T
Series routers with ATM2 PICs automatically copy the parent container interface
configuration to the children interfaces. Container interfaces do not go down during
APS switchovers, thereby shielding upper layers. This feature allows the various ATM
features to work over the container ATM for APS.
To specify ATMchildrenwithin a container interface, use the container-list cin statement
and (primary | standby) option at the [edit interface at-fpc/pic/slot container] hierarchy
level.
To configure a container interface, including its children, use the cin statement and its
options at the [edit interface ci-n] hierarchy level.
Container ATM APS does not support inter-chassis APS. MLPPP over ATM CI is also
not supported.
[Network Interfaces]
•
Signaling neighboring routers of fabric down on T1600 and T640 routers—The
signaling of neighboring routers is supported when a T640 or T1600 router is unable
to carry traffic due to all fabric planes being taken offline for one of the following
reasons:
•
CLI or offline button pressed
•
Automatically taken offline by the SPMB due to high temperature.
•
PIO errors and voltage errors detected by the SPMB CPU to the SIBs.
The following scenarios are not supported by this feature:
•
All PFEs get destination errors on all planes to all destinations, even with the SIBs
staying online.
•
Complete fabric loss caused by destination timeouts, with the SIBs still online.
When chassisd detects that all fabric planes are down, the router reboots all FPCs in
the system. When the FPCs come back up, the interfaces will not be created again,
since all fabric planes are down.
Once you diagnose and fix the cause of all fabric planes going down, you must then
bring the SIBs back online. Bringing the SIBs back online brings up the interfaces.
Fabric down signaling to neighboring routers offers the following benefits:
•
FPCs reboot when the control plane connection to the Routing Engine times out.
•
Extends a simple approach to reboot FPCs when the dataplane blacks out.
When the router transitions from a state where SIBs are online or spare to a state where
there are no SIBs are online, then all the FPCs in the system are rebooted. An ERRMSG
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
indicates if all fabric planes are down, and the FPCs will reboot if any fabric planes do
not come up in 2 minutes.
An ERRMSG indicates the reason for FPC reboot on fabric connectivity loss.
The chassisd daemon traces when an FPC comes online, but a PIC attach is not done
because no fabric plane is present.
A CLI warning that the FPCs will reboot is issued when the last fabric plane is taken
offline.
You will need to bring the SIBs online after determining why the SIBs were not online.
When the first SIB goes online, and link training with the FPCs completes, the interfaces
will be created.
Fabric down signaling to neighboring routers functionality is available by default, and
no user configuration is required to enable it.
No new CLI commands or alarms are introduced for this feature. Alarms are already
implemented for when the SIBs are not online.
[Network Interfaces, System Basics]
•
New enterprise-specific MIB to support digital optical monitoring (MX960, MX480,
MX240, and 10-Gigabit Ethernet LAN/WAN PIC with XFP on T640 and T1600
routers)—Junos OS Release 10.4 introduces JUNIPER-DOM-MIB, a new
enterprise-specific MIB to extend MIB support for digital optical monitoring.
JUNIPER-DOM-MIB supports the SNMP Get request for statistics and SNMP Trap
notifications for alarms.
JUNIPER-DOM-MIB is part of the JUNIPER-SMI MIB hierarchy level.
The following MIB objects are supported by JUNIPER-DOM-MIB for digital optical
monitoring:
•
jnxDomCurrentTable
•
jnxDomAlarmSet
•
jnxDomAlarmCleared
[SNMP MIBs and Traps Reference]
•
Transition of IPv4 traffic to IPv6 addresses using Dual Stack Lite (DS-Lite)—Adds
support for DS-Lite, a means for transitioning IPv4 traffic to IPv6 addresses. This
transition will become necessary as the supply of unique IPv4 addresses nears
exhaustion. New subscriber homes are allocated IPv6 addresses and IPv6-capable
equipment; DS-Lite provides a method for the private IPv4 addresses behind the IPv6
equipment to reach the IPv4 network. An IPv4 host communicateswith a NATendpoint
over an IPv6 network using softwires. DS-Lite creates the IPv6 softwires that terminate
on the services PIC. Packets coming out of the softwire can then have other services
such as NAT applied on them.
[Services Interface, System Basics and Services Command Reference]
IPv6 statistics from IQ2 and IQ2E PICs on M320 routers with Enhanced III FPCs and
T Series routers—Support statistical accounting for IPv6 traffic traversing the IQ2 and
IQ2E PICs on M320 routers with Enhanced III FPCs and T Series routers.
For IQ2 and IQ2E PIC interfaces,the IPv6 trafficthat is reported will be the total statistics
(sum of local and transit IPv6 traffic) in the ingress and egress direction. The IPv6
traffic in the ingress direction will be accounted separately only if the IPv6 family is
configured for the logical interface.
Statistics are maintained for routed IPv6 packets in the egress direction.
Byte and packet counters are maintained in the ingress and egress direction.
Differences in IPv6 statistics for IQ2 interfaces and all other interfaces are as follows:
•
IQ2 and IQ2E PIC interfaces report the total statistics for the IPv6 traffic. For other
interfaces, the transit statistics are reported.
•
IQ2 and IQ2E PIC interfaces report all IPv6 traffic received on the logical interface.
For all other interfaces, only the routed traffic is accounted.
•
IQ2 and IQ2E PIC interfaces report IPv6 statistics for the Layer 2 frame size. For all
other interfaces, the Layer 3 packet size is accounted.
The IPv6 statistics can be viewed by logging in to the individual IQ2 PIC or IQ2E PIC, or
by using the CLI.
Local statistics are not accounted separately.
To display total IPv6 statistics for IQ2 and IQ2E PICs, use the show interfaces extensive
command.
NOTE: The reported IPv6 statistics do not account for the traffic manager
drops in egress direction or the Packet Forwarding Engine/traffic manager
drops in the ingress direction. Transitstatistics are not accountedseparately
because the IQ2 and IQ2E PICs cannot differentiate between transit and
local statistics.
[Network Interfaces]
•
100-Gigabit Ethernet PIC interoperability with VLAN steering—Supports
interoperability with similar PICs from other vendors using a VLAN steering forwarding
option. Previously, the PICs required interconnection to the same model PIC.
Interoperabilitywith interfacesfromother vendors was not supported.Junos OS Release
10.4 introduces a new VLAN steering algorithm to configure 100-Gigabit Ethernet PIC
interoperation with similar interfaces from other vendors.
Two packet forwarding modes exist under the forwarding-mode statement.SA multicast
mode, for proprietary connection of two Juniper Networks 100-Gigabit Ethernet PICs,
uses the Ethernet header SA MAC address multicast bit to steer the packets to the
appropriate PFE. VLAN steering mode allows the PIC to connect to non-Juniper
Networks equipment. On ingress, the PIC compares the outer VLAN ID against a
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
user-defined VLAN ID and VLAN mask combination and steers the packet accordingly.
Modifying the forwarding mode config reboots the PIC.
VLAN steering overview:
•
In VLAN steering mode, the SA multicast bit is not used for packet steering.
•
In SA multicast bit steering mode, VLAN ID and VLAN mask configuration is not used
for packet steering.
•
Configuration of packet forwarding mode and VLAN steering mode uses CLI
commands that result in a PIC reboot.
•
There are three tag types for ingress packets:
•
Untagged ingress packet–The packet is sent to PFE1.
•
Ingress packet with one VLAN–The packet forwards based on the VLAN ID.
•
Ingress packet with two VLANs–The packet forwards based on the outer VLAN
ID.
•
VLAN rules describe how the router forwards packets. For VLAN steering, you must
use one of the two rules available in the CLI:
•
Odd-even rule–Odd number VLAN IDs go to PFE1; even number VLAN IDs go to
PFE0.
•
High-low rule–1 through 2047 VLAN IDs go to PFE0; 2048 through 4096 VLAN
IDs go to PFE1.
•
When configured in VLAN steering mode, the PIC can be configured in two physical
interface mode or in aggregated Ethernet (AE) mode:
•
Two physical interface mode–When the PIC is in two physical interface mode, it
creates physical interfaces et-x/0/0:0 and et-x/0/0:1. Each physical interface can
configure its own logical interface and VLAN. CLI enforces the followingrestrictions
on commit:
•
The VLAN ID configuration must comply with the selected VLAN rule.
•
The previous restriction implies that the same VLAN ID cannot be configured
on both physical interfaces.
•
AE mode–In AE mode, the two physical interfaces on the same PIC are aggregated
into one AE physical interface. PIC egress traffic is based on the AE internal hash
algorithm. PIC ingress traffic steering is based on the customized VLAN ID rule. CLI
enforces the following restrictions on commit:
•
The PIC AE working in VLAN steering mode includes both links of this PIC, and
only the links of this PIC.
•
The PIC AE working in SA multicast steering mode can include more than one
PIC to achieve more than 100-gigabit capacity.
To configure the PIC forwarding mode, include the forwarding-mode statement and
its options at the [edit chassis fpc number pic number] hierarchy level.
[Network Interfaces]
•
New control queue disable feature (T Series routers with 10-Gigabit Ethernet PIC
with oversubscription)—Providesa new CLI statement for disabling the control queue
feature for the 10-Gigabit Ethernet PIC with oversubscription. To disable the control
queue, use the no-pre-classifier statement at the [chassis] hierarchy level.
When the no-pre-classifier statement is set, the control queue feature will be disabled
for all ports on that 10-Gigabit Ethernet PIC with oversubscription. Deleting this
configuration results in the control queue feature being re-enabled on all the ports of
that PIC.
[edit chassis]
fpc 2 {
pic 0 {
no-pre-classifier;
}
}
NOTE:
1. This feature is applicable in both oversubscribed and line-rate modes.
2. The control queue feature is enabled by default in both oversubscribed
and line-rate modes, which can be overridden by the user configuration.
3. CLI show commands remain unchanged. When the control queue is
disabled, various show queue commands continue to show the control
queue in the output. However, all control queue counters are reported
as zeros.
4. Enabling or disabling the control queue feature results in the PIC being
bounced (offline/online).
Once the control queue feature is disabled, then the Layer 2 and Layer 3 controlpackets
are subject to queue selection based on the BA classification. However, the following
control protocol packets are not classified using BA classification, as they might not
have a VLAN, MPLS, or IP header:
•
Untagged ARP packets
•
Untagged Layer 2 control packets such as LACP or Ethernet OAM
•
Untagged IS-IS packets
When the control queue feature is disabled, untagged ARP/IS-IS and other untagged
Layer 2 control packets will go to the restricted queue corresponding to the forwarding
class associated with queue 0.
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
Junos OS XML API and Scripting
New Junos OS XML API operational request tag elements—Table 1 on page 13 shows
the Junos OS Extensible Markup Language (XML) operational request tag elements that
are new in Junos OS Release 10.4 along with the corresponding CLI command and
response tag element for each one.
Table 1: Junos OS XML Tag Elements and CLI Command Equivalents New in Junos OS Release
10.4
Response Tag ElementCLI CommandRequest Tag Element
NONErequest dhcpv6 server reconfigure<requestdhcpv6-serverreconfigure-information>request_dhcpv6_
server_reconfigure_information
NONErequest system license update<request-license-update>
request_license_update
<relay-group-member>show system relay member<get_rollback_information>
<relay-summary>show system relay summary<get_dhcp_binding_information>
clear synchronousethernet esmc
statistics
<clock-synchronization-
clear-output>
Layer 2 Ethernet Services
•
Feature support for Trio 3D MPCs and MICs (MX Series routers)—Enables you to
configurethe following features through Junos OS Release 9.1: load balancing, Ethernet
OAM IEEE 802.1ag Phase 4 MIP support, LLDP, BPDU guard and loop guard, IRB support
for interworking of LDP-VPLS and BGP-VPLS, BGP multihoming for Inter-AS VPLS,
VPLS Ethernet as a core-facing interface, and limitations on next-hop flooding.
Ethernet CFM support on Trio 3D MPCs and MICs (MX Series routers)—Enables
support for Ethernet connectivity fault management (CFM) defined by IEEE 802.1ag
for family bridge interfaces.However, MEP configuration is not supported on aggregated
Ethernet interfaces.
[Layer 2 Configuration]
MPLS Applications
•
MPLS support on services PICs—Adds MPLS label pop support for services PICs on
Junos OS routers. Previously all MPLS traffic would be dropped at the services PIC. No
changes are required to CLI configurations for this enhancement. In-service software
upgrade (unified ISSU) is supported for tag next hops for MPLS on services PIC traffic,
but no support is provided for tags over IPv6 packets or labels on multiple gateways.
[MPLS]
•
Adding descriptions for bypass LSP—You can now add a text describing a bypass
LSP using the description option at the [edit protocols rsvp interface interface-name
link-protection bypass bypass-lsp-name] hierarchy level. Enclose any descriptive text
that includes spaces in quotation marks (" "). Any descriptive text you include is
displayed in the output of the show rsvp session bypass command and has no effect
on the operation of the bypass LSP.
[MPLS]
Multicast
•
Nonstop active routing PIM support for IPv6—Starting with Release 10.4, Junos OS
extends the nonstop active routing support for Protocol Independent Multicast (PIM),
which is already supported on IPv4, to include the IPv6 address families. The extension
of nonstop active routing PIM support to IPv6 enables IPv6 routers to maintain
self-generation IDs, multicastsession states, dynamic interface states, list of neighbors,
and RPSets across Routing Engine switchovers.
The nonstop active routing support for PIM on IPv6 is similar to the nonstop active
routing PIM support on IPv4 except for the following:
•
Nonstop active routing support for PIM on IPv6 supports an embedded rendezvous
point (RP) on non-RP routers.
•
Nonstop active routing support for PIM on IPv6 does not support auto-RP,as auto-RP
is not supported on IPv6.
For more information about nonstop active routing PIM support on IPv4 and IPv6, see
the Junos OS High Availability Configuration Guide.
[High Availability, Multicast]
Routing Policy and Firewall Filters
•
New routing policy system log message—Junos OS Release 10.3 supports a new
routing policy system log message. The RPD_PLCY_CFG_NH_NETMASK system log
message provides information about ignored netmasks. If you have a policy statement
with a term that contains a next-hop address with a netmask, the netmask is ignored.
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
The following sample shows the new systemlog message (depending on your network
configuration, the type of message you see might be different):
Jun 18 11:22:43 pro5-d rpd[1403]: RPD_PLCY_CFG_NH_NETMASK: Netmask ignored for
next hop: 10.0.0.1/24.
[System Log Messages Reference]
•
Support for displaying the firewall filter version information—You can display the
version number of the firewall filter installed in the Routing Engine. The initial version
number is 1 and increments by one when you modify the firewall filter settings or an
associated prefix action. To show the version number of the installed firewall filter,
use the show firewall filter version operational mode command.
[Routing Protocols and Policies Command Reference]
Routing Protocols
•
Point-to-multipoint (P2MP) LSP load balancing across aggregated Ethernet links
(M Series except M320)—Enables you to load-balance VPLS multicast and P2MP
multicast traffic over link aggregation. This feature also re-load-balances traffic after
a change in the next-hop topology. Next-hop topology changes might include but are
not limited to:
•
Layer 2 membership change in the link aggregation
•
Indirect next-hop change
•
Composite next-hop change
No new configuration is required to configure this feature. The load balancing over
aggregated links is automatically enabled with this release. For a sample topology and
configuration example, see Junos OS Policy Framework Configuration Guide.
[Policy]
•
Support for disabling traps for passive OSPFv2 interfaces—You can now disable
interface state change traps for passive OSPF interfaces. Passive OSPF interfaces
advertise address information as an internal OSPF route, but do not run the actual
protocol. If you are only interested in receiving notifications for active OSPF interfaces,
disabling traps for passive OSPF interfaces reduces the number of notificationsreceived
and processed by the SNMP server. This allows you to more quickly and easily scan
the logs for potential issues on active OSPF interfaces.
To disable and stop receiving notifications for statechanges in a passiveOSPF interface,
include the no-interface-state-traps statement at the following hierarchy levels:
•
[edit logical-systems logical-system-name protocols ospf area area-id interface
[edit protocols ospf area area-id interface interface-name]
•
[edit routing-instances routing-instance-name protocols ospf area area-id interface
interface-name]
[Routing Protocols]
•
Behavior change for BGP-independent AS domains—Independent domains use the
transitive path attribute 128 (attribute set) messages to tunnel the independent
domain’s BGP attributes through the internal BGP (IBGP) core. In Junos OS Release
10.3 and later,if you have not configured an independent domain in any routing instance,
BGP treats the received attribute 128 message as an unknown attribute. The AS path
field in the show route command has been updatedto display an unrecognized attribute
and associated hexadecimal value if you have not configured an independent domain.
The following is a sample output of the AS path field (depending on your network
configuration, the output might be different):
Support for disabling the attribute set messages on independent AS domains for
BGP loop detection—BGP loop detection for a specific route uses the localautonomous
system (AS) domain for the routing instance. By default, all routing instances belong
to a single primary routing instance domain. Therefore, BGP loop detection uses the
local ASs configured on all of the routing instances. Depending on your network
configuration, this default behavior can cause routes to be looped and hidden.
To limit the local ASs in the primary routing instance, configure an independent AS
domain for a routing instance. Independent domains use the transitive path attribute
128 (attribute set) messages to tunnel the independent domain’s BGP attributes
through the internal BGP (IBGP) core. If you want to configure independent domains
to maintain the independence of local ASs in the routing instance and perform BGP
loop detection only for the specified local ASs in the routing instance, disable attribute
set messages on the independent domain. To disable attribute set messages, include
the independent-domain no-attrset statement at the following hierarchy levels:
NAT-PT with DNS ALG support (M Series and T Series routers)—You can configure
Domain Name Service (DNS) application-level gateways (ALGs) using NAT with
protocol translation (NAT-PT) for IPv6 to IPv4. The implementation is described in
RFC 2766 and RFC 2694.
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
When you configure NAT-PT with DNS ALGsupport, you must configure two NAT rules.
The first NAT rule ensures that the DNS query and response packets are translated
correctly. For this rule to work, you must configure a DNS ALG application and reference
it in the rule. The second rule is required to ensure that NAT sessions are destined to
the address mapped by the DNS ALG.
•
To configure the correct translation of the DNS query and response packets, include
the dns-alg-pool dns-alg-pool or dns-alg-prefix dns-alg-prefix statement at the [edit
services nat rule rule-name term term-name then translated] hierarchy level.
•
To configure the DNS ALG application, include the application application-name
statement at the [edit applications] hierarchy level, then reference it at the [edit
services nat rule rule-name term term-name from] hierarchy level.
•
To configure destination translation with the DNS ALG address map, use the
use-dns-map-for-destination-translation statement at the [edit services nat rule
rule-name term term-name then translated] hierarchy level. This statement correlates
the DNS query or response processing done by the first rule with the actual data
sessions processed by the second rule.
You can also control the translation of IPv6 and IPv4 DNS queries in the following
ways.
•
For translation control of IPv6 DNS queries, use the
do-not-translate-AAAA-query-to-A-query statement at the [edit applications
application application-name] hierarchy level.
•
For translation control of IPv4 queries, use the
do-not-translate-A-query-to-AAAA-query statement at the [edit applications
application application-name] hierarchy level.
NOTE: The above two statements cannot be configured together. You
can only configure one at a time, but not both.
To check that the flows are established properly, use the show services
stateful-firewall flows command or the show services stateful-firewall conversations
command.
[Services Interfaces]
•
Enhancements to active flow monitoring—Add support for extraction of bandwidth
usage information for billing purposes in PIC-based sampling configurations. This
capability is supported on M Series, MX Series, and T Series routers and applies only
to IPv4 and IPv6 traffic. It is enabled only at the global instance hierarchy level and is
not available for per Packet Forwarding Engine instances. To configure the sampling
of traffic for billing purposes, include the template as-peer-billing-template-name
statement at the [edit forwarding-options sampling family (inet | inet6) output
flow-server server-name version version-number] hierarchy level. To define the peer-AS
billing functionality, include the peer-as-billing-template statement at the [edit services
flow-monitoring version9 template template-name] hierarchy level. For a list of the
template fields, see the Junos OS Services Interfaces ConfigurationGuide. You can apply
the existing destination class usage (DCU) policy option configuration for use with this
feature.
In addition, the MPLS top label IP address is added as a new field in the existing
MPLS-IPv4 flow template. Youcan use this field to gather MPLS forwarding equivalence
class (FEC) -based traffic information for MPLS network capacity planning. These
ALGs that use Junos Services Framework (JSF) (M Series) is a PIC-only feature applied
on sampled traffic and collected by the services PIC or DPC. You can define it for either
global or per Packet Forwarding Engine instances for MPLS traffic.
The show services accounting aggregation template operational command has been
updated to include new output fields that reflect the additional functionality.
[Services Interfaces, System Basics and Services Command Reference]
•
Support for the RPM timestamp on the Services SDK (M Series, MX Series, and T
Series)—Real-time performance monitoring (RPM), which has been supported on the
Adaptive Services (AS) interface, is now supported by the Services SDK. RPM is
supported on all platforms and service PICs that support the Services SDK.
RPM timestamping is needed to account for any latency in packet communications.
You can apply timestamps on the client, the server, or both the client and server. RPM
timestamping is supported only with the icmp-ping, icmp-ping-timestamp, udp-ping,
and udp-ping-timestamp probe types.
To specify the Services SDK interface, include the destination-interface statement at
the [edit services rpm probe probe-owner test test-name] hierarchy level:
To specify the RPM client router and the RPM server router, include the rpm statement
at the [edit interfaces interface-name unit logical-unit-number] hierarchy level:
rpm (client | server);
To enable RPM on the Services SDK on the AS interface, configure the object-cache-size,
policy-db-size, and package statements at the [edit chassis fpc slot-number pic
pic-number adaptive-services service-package extension-provider] hierarchy level. For
the Services SDK, package-name in the package package-name statement is
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
}
}
[Services Interfaces]
•
ALGs using Junos OS Services Framework (JSF) (M Series with MS PICs and MX
Series with MS DPCs)—Application-level gateways (ALGs) intercept and analyze
specified traffic, allocate resources, and define dynamic policies to permit traffic to
pass securely through a device. Beginning with Junos OS Release 10.4 on the specified
routers, you can use JSF ALGs with the following services:
•
Stateful firewall
•
Network Address Translation (NAT)
To use JSF to run ALGs, you must configure the jservices-alg package at the [edit
in the stateful firewall rule or the NAT rule in those respective configurations.
[Services Interfaces]
•
Enhancements to port mirroring with next-hop groups (MX Series only)—Adds
support for binding up to two port-mirroring instances to the same MX Series Packet
FowardingEngine. This enables you to choose multiple mirror destinations by specifying
different port-mirroring instances in the filters. Filters must include the
port-mirror-instanceinstance-name statementat the [edit firewall filter filter-name term
term-name then] hierarchy level. You must also include the port-mirror-instance
instance-name statement at the [edit chassis fpc number] hierarchy level to specify the
FPC to be used.
Inline port mirroring allows you to configure instances that are not bound to the FPC
specified in the firewall filter then port-mirror-instance instance-name action. Instead,
you can define the then next-hop-group action. Inline port-mirroring aims to decouple
the port-mirror destination from the input parameters, such as rate. While the input
parameters are programmed in the Switch Interface Board (SIB), the next-hop
destination for the mirrored packet is available in the packet itself.
A port-mirroring instance can now inherit input parameters from another instance that
specifies it. To configure this option, include the input-parameters-instance
instance-name statement at the [edit forwarding-options port-mirror instance
instance-name] hierarchy level.
You can also now configure port mirroring to next-hop groups using a tunnel interface.
[Services Interfaces]
•
Multiple IDP detector support (M120, M320, and MX Series routers with Enhanced
III FPCs)—The IDP detector provides information about services, contexts, and
anomalies that are supported by the associated protocol decoder.
The specified routers now support loading multiple IDP detectors simultaneously.
When a policy is loaded, it is also associated with a detector. If the new policy being
loaded has an associated detector that matches the detector already being used by
the existing policy, the new detector is not loaded and both policies use a single
associated detector. However, if the new detector does not match the current detector,
the new detector is loaded along with the new policy. In this case, each loaded policy
will then use its own associated detector for attack detection. Note that with the
specified routers, a maximum of four detectors can be loaded at any given time.
Multiple IDP detector support for the specified routers functions in a similar way to the
existing IDP detector support on J Series and SRX Series devices, except for the
maximum number of decoder binary instances that are loaded into the process space.
To view the current policy and the corresponding detector version, use the show security
idp status detail command.
For more information, see the Junos OS Security Configuration Guide.
[Services Interfaces]
•
NAT using Junos OS Services Framework (JSF) (M Series and T Series with
Multiservices PICs and MX Series with Multiservices DPCs)—The Junos OS Services
Framework (JSF) is a unified framework for Junos OS services integration. JSF Services
integration will allow the option of running Junos OS services on services PICs or DPCs
in any M Series, MX Series, or T Series routers. Beginning with Junos OS Release 10.4,
you can use JSF to run NAT on the specified routers.
To use JSF to run NAT, you must configure the jservices-nat package at the [edit chassis
level. In addition, you must configure NAT rules and a service set with a Multiservice
interface. Tocheck the configuration, use the show configurationservicesnat command.
To show the run time (dynamic state) information on the interface, use the show
services sessions and show services nat pool commands.
[Services Interfaces]
•
Stateful firewall using Junos OS Services Framework (JSF) (M Series with MS PICs,
MX Series with MS DPCs, and T Series routers)—The Junos OS Services Framework
(JSF) is a unified framework for Junos OS services integration. JSF Services integration
will allow the option of running Junos OS services on services PICs or DPCs in any M
Series, MX Series, or T Series routers. Beginning with Junos OS Release 10.4, you can
use JSF to run stateful firewall on the specified routers.
To use JSF to run stateful firewall, you must configure the jservices-sfw package at the
[edit chassis fpc slot pic slot adaptive-services service-package extension-provider
package] hierarchy level. In addition, you must configure stateful firewall rules and a
service set with a Multiservice interface. To check the configuration, use the show
configurationservices stateful-firewall command. To show the run time (dynamic state)
information on the interface, use the show services sessions command.
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
Subscriber Access Management
•
Redirecting HTTP redirect requests (MX Series routers)—Enables support for HTTP
traffic requests from subscribers to be aggregated from access networks onto a BRAS
router, where HTTP traffic can be intercepted and redirected to a captive portal. A
captive portal provides authentication and authorization services for redirected
subscribers before granting access to protected servers outside of a walled garden. A
walled garden defines a group of servers where access is provided to subscribers
without reauthorization through a captive portal. You can use a captive portal page as
the initial page a subscriber sees after logging in to a subscriber session and as a page
used to receive and manage HTTP requests to unauthorized Web resources. An HTTP
redirectremoteserver that resides in a walled garden behind Junos OS routers processes
HTTP requests redirected to it and responds with a redirect URL to a captive portal.
To configure HTTP redirect, include the captive-portal-content-delivery statement at
the [edit services] hierarchy level.
[Subscriber Access]
•
Filter support for service packet counting—You can count service packets, applying
them to a specific named counter (__junos-dyn-service-counter), for use by RADIUS.
To enable service packet accounting, specify the service-accounting action at the [edit
firewall family family-name filter filter-name term term-name then] hierarchy level.
[Policy Framework, Subscriber Access]
•
Support for domain maps that apply configuration options based on subscriber
domain names (MX Series and M Series routers)—You use domain maps to apply
access options and session-specific parameters to subscribers whose domain name
corresponds to the domain map name. You can also create a default domain map that
the router uses for subscribers whose username does not include a domain name or
has a non-matching domain name.
Domain maps apply subscriber-related characteristics such as profiles (access,
dynamic, and tunnel), target and AAA logical system mapping, address pool usage,
and PADN routing information.
You configure domain maps at the [edit access domain] hierarchy level.
[Subscriber Access]
•
L2TP LAC support for subscriber management (MX Series routers)—You can now
configure an L2TP access concentrator (LAC) on MPC-equipped MX Series routers.
As part of the new L2TP LAC support, you can configure how the router selects a tunnel
for a PPP subscriber from among a set of available tunnels. The default tunnel selection
method is to fail over between tunnel preference levels. When a PPP user tries to log
in to a domain, the router attempts to connect to a destination in that domain by means
of the associated tunnel with the highest preference level. If the destination is
unreachable, the router then moves to the next lower preference level and repeats the
process. No configuration is required for this tunnel selection method.
You can include the fail-over-within-preference statement at the [edit services l2tp]
hierarchy level to configure tunnel selection failover within a preference level. With this
method, when the router tries to connect to a destination and is unsuccessful, it selects
a new destination at the same preference level. If all destinations at a preference level
are marked as unreachable, the router does not attempt to connect to a destination
at that level. It drops to the next lower preference level to select a destination. If all
destinations at all preference levels are marked as unreachable, the router chooses
the destination that failed first and tries to make a connection. If the connection fails,
the router rejects the PPP user session without attempting to contact the remote
router.
By default, the router uses a round-robin selection process among tunnels at the same
preference level. Include the weighted-load-balancing statement at the statement at
the [edit servicesl2tp] hierarchy level to specify that the tunnel with the highest weight
within a preference is selected until its maximum sessions limit is reached. Then the
tunnel with the next highest weight is selected until its limit is reached, and so on. The
tunnel with the highest configured maximum sessions value has the greatest weight.
Another feature of L2TP LACs on MX Series routers is the ability to control whether
the LAC sends the Calling Number AVP 22 to the LNS. The AVP value is derived from
the Calling-Station-Id and identifies the interface that is connected to the customer
in the access network. By default, the LAC includes this AVP in ICRQ packets it sends
to the LNS. In some networks you may wish to conceal your networkaccessinformation.
To prevent the LAC from sending the Calling Number AVP to the LNS, include the
disable-calling-number-avp statement at the [edit services l2tp] hierarchy level.
[Subscriber Access]
•
Support for dynamic interface sets (M120, M320, and MX Series routers)—Enables
you to configure sets of subscriber interfaces in dynamic profiles. Interface sets are
used for providing hierarchical scheduling. Previously, interface sets were supported
for interfaces configured in the static hierarchies only.
Supported subscriber interfaces include static and dynamic demux, static and dynamic
PPPoE, and static and dynamic VLAN interfaces.
To configure an interface set in a dynamic profile, include the interface-set
interface-set-name statement at the [edit dynamic-profiles interfaces] hierarchy level.
To add a subscriber interface to the set, include the interface interface-name unit
logical-unit-number statement at the [edit dynamic-profiles interfaces interface-set
interface-set-name]hierarchy level. Youapplytrafficshaping and scheduling parameters
to the interface-set by including the interface-set interface-set-name and
output-traffic-control-profile profile-name statements at the static [editclass-of-service
interfaces] hierarchy level.
A new Juniper Networks VSA (attribute 26-130) is now supported for the interface set
name, and includes a predefined variable, $junos-interface-set-name. The VSA is
supported for RADIUS Access-Accept messages only; change of authorization (CoA)
requests are not supported.
[Subscriber Access]
•
Support for service session accounting statistics (MX Series routers)—You can now
capture accounting statistics for subscriber service sessions. Subscriber management
supports service session accounting based on service activation and deactivation, as
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
well as interim accounting. Time-based accounting is supported for all service sessions.
Time and volume-based accounting is supported for classic firewall filter and fast
update firewall filter service sessions only.
To provide volume service accounting, the well-known accounting counter
(junos-dyn-service-counter) must also be configured for the classic firewall filter and
fast update firewall filter service. You define the counter at the [edit firewall family
family filter filter term term then] hierarchy level.
The following VSAs (vendor ID 4874) are used for service accounting:
Attribute
Number
Service-Statistics26-69
Enable or disable
statistics for the
service.
ValueDescriptionAttribute Name
•
0 = disable
•
1 = enable time statistics
•
2 = enable time and
volume statistics
Acct-Service-Session26-83
service.
Service-Interim-Acct-Interval26-140
Amount of time
between interim
accounting
updates for this
service.
string: service-nameName of the
•
range = 600–86400
seconds
•
0 = disabled
[Subscriber Access]
•
Subscriber secure policy traffic mirroring supported for L2TP sessions on the LAC
(MX Series routers)—The L2TP access concentrator (LAC) implementation supports
RADIUS-initiated per-subscriber traffic mirroring. Both subscriber ingress traffic (from
the subscriber into the tunnel) and subscriber egress traffic (from the tunnel to the
subscriber) is mirrored at the (subscriber-facing) ingress interface on the LAC. The
ingress traffic is mirrored after PPPoE decapsulation and before L2TP encapsulation.
The egress traffic is mirrored after L2TP decapsulation. The mirrored packet includes
the complete HDLC frame sent to the LNS.
[Subscriber Access]
•
Support for static and dynamic CoS on L2TP LACsubscriber interfaces(M120,M320,
and MX Series routers)—Enables you to configure static and dynamic CoS for L2TP
accessconcentrator (LAC) tunnels that transport PPP subscribers at Layer 2 and Layer
3 of the network.
IP and L2TP headers are added to packets arriving at the LAC from a subscriber before
being tunneled to the L2TP network server (LNS). Classifiers and rewrite-rules enable
you to properly transfer the type-of-service (ToS) value or the 802.1p value from the
inner IP header to the outer IP header of the L2TP packet.
For ingress tunnels, you configure fixed or behavior aggregate (BA) classifiers for the
PPP interface or an underlying VLAN interface at Layer 2. You can configure Layer 3
classifiers for a family of PPP interfaces. Layer 2 and Layer 3 classifiers can co-exist
for a PPP subscriber.
For example, to classify incoming packets for a PPP subscriber, include the classifier
type classifier-name statement at the [edit class-of-service interfaces pp0 unit
logical-unit-number] hierarchy level or at the [edit dynamic-profiles class-of-serviceinterfaces pp0 unit logical-unit-number] hierarchy level.
On egress tunnels, you configure rewrite rules to set the ToS or 802.1p value of the
outer header. For example, to configure a rewrite-rule definition for an interface with
802.1p encapsulation, include the [rewrite-rule ieee-802.1 (rewrite-name | default)
statementat the edit class-of-service interfacesinterface-name unit logical-unit-number]
hierarchy level or the [edit dynamic-profiles class-of-service interfaces pp0 unit
logical-unit-number] hierarchy level.
Rewriterulesare applied accordinglytothe forwarding class, packet loss priority (PLP),
and code point. The proper transfer of the inner IP header to the outer IP header of the
L2TP packet depends on the classifier and rewrite rule configurations.
The following table shows how the classifier and rewrite-rule values transfer from the
inner IP header to the outer IP header. The inner IP header (ob001) is classified with
assured-forwarding and low loss priority at the ingress interface. Based on the
assured-forwarding class and low loss priority in the rewrite rule, the outer IP header
is set to ob001 at the egress interface.
Outer IP HeaderCode PointLoss PriorityForwarding ClassInner IP Header
ob001001lowassured-forwardingob001
[Subscriber Access, Class of Service]
•
L2TP tunnel profiles and AAA support for tunnels in subscriber management (MX
Series routers)—You can configure a set of attributes to define an L2TP tunnel for PPP
subscribers. More than one tunnel can be defined for a tunnel profile. Tunnel profiles
are applied by a domain map before RADIUS authentication. When the RADIUS
Tunnel-Group VSA [26-64] is specified in the RADIUS login, then the RADIUS tunnel
profile (group) overrides a tunnel profile specified by the domain map. The tunnel is
then configured according to RADIUS tunnel attributes and VSAs.
To configure a tunnel profile, include the tunnel-profile profile-name statement at the
[edit access] hierarchy level. To define a tunnel for a profile, include the tunnel tunnel-id
statement at the [edit access tunnel-profile profile-name] hierarchy level.
Define the attributes of the tunnel at the [edit access tunnel-profile profile-name tunnel
tunnel-id] hierarchy level. You must configure a preference for the tunnel and the IP
address of the LNS tunnel endpoint; all other attributes are optional. Include the
preferencenumber statement to configure the preference. Include the remote-gateway
address server-ip-address statement to configure the LNS address.
You can optionally configure the remaining tunnel attributes. Include the
remote-gateway name server-name statement to configure the LNS hostname. Include
the source -gatewayaddressclient-ip-addressstatementand the source-gatewayname
client-name statements to configure the local (LAC) tunnel endpoint. Although you
New Features in Junos OS Release 10.4 for M Series, MX Series, and T Series Routers
can configure a medium type (medium type) and protocol type (tunnel tunnel-type)
for the tunnel, only the default values of ipv4 and l2tp are supported in this release.
Include the identification name statement to configure an assignment ID for the tunnel.
Include the max-sessions number statement to configure the maximum number of
sessions permitted for the tunnel. Include the secret password statement to configure
a cleartext password for authentication by the remote tunnel endpoint (LNS). Finally,
you can configure a logical system and routing instance for the tunnel by including the
logical-system logical-system-name and routing-instance routing-instance-name
statements.
The following table shows the RADIUS attributes that are now supported for defining
a tunnel.
Attribute
Number
Tunnel-Type64
DescriptionAttribute Name
•
The tunneling protocol to use (in the case of a tunnel
initiator) or the tunneling protocol already in use (in
the case of a tunnel terminator).
•
Only L2TP tunnels are currently supported.
•
Tunnel-Medium-Type65
Tunnel-Assignment -Id82
Tunnel-Preference83
Tunnel-Client-Auth-Id90
Tunnel-Server-Auth-Id91
Transport medium to use when creating a tunnel for
protocols that can operate over multiple transports.
•
Only IPv4 is currently supported.
Address of the initiator end of the tunnel.Tunnel-Client-Endpoint66
Address of the server end of the tunnel.Tunnel-Server-Endpoint67
Password used to authenticate to a remote server.Tunnel-Password69
Indicates to the tunnel initiator the particular tunnel to
which a session is assigned.
•
If more than one set of tunneling attributesisreturned
by the RADIUS server to the tunnel initiator, this
attributeis included in each set to indicatethe relative
preference assigned to each tunnel.
•
Included in the Tunnel-Link-Start, the
Tunnel-Link-Reject, and the Tunnel-Link-Stop packets
(LAC only).
Name used by the tunnel initiator during the
authentication phase of tunnel establishment.
Name used by the tunnel terminator during the
authentication phase of tunnel establishment.
The following table shows the RADIUS VSAs that are now supported for defining a
tunnel.
Name of the tunnel group
(profile) assigned to a domain
map.
integer: 4-octetMaximum number of sessions
string:
tunnel-group-name
[Subscriber Access]
•
Dynamic reconfiguration of extended DHCPv6 local server clients (MX Series
routers)—You can enable dynamic reconfiguration of DHCPv6 clients to enable the
extended DHCPv6 local server to initiate a client update without waiting for the client
to initiate a request. In subscriber management scenarios, a client may need to be
quickly updated with its network address and configuration in the event of server
changes, such as a restructuring of the service provider’s addressing scheme or a change
in the local server IP addressesthat were provided to the clients. Include the reconfigure
statementto enable dynamic reconfiguration with default values for all DHCPv6 clients
at the [edit system services dhcp-local-server dhcpv6] hierarchy level, and for DHCPv6
clients serviced by a specified group of interfaces at the [edit system services
dhcp-local-server dhcpv6 group group-name] hierarchy level.
Optional statements enable you to modify default reconfiguration values: The number
of reconfiguration attempts, the interval between the first and second attempts, what
happens to the client if all reconfiguration attempts fail, what happens to the client in
the event of a RADIUS-initiateddisconnect,whether to bind clients that do not support
reconfiguration, and whether to send an authentication token. Issue the request dhcpv6
server reconfigure command to initiate reconfiguration. Use the show dhcpv6 server
binding and show dhcpv6 server statistics commands to monitor client-server
interactions.
[Subscriber Access]
•
Support for ascend data filters (RADIUS attribute 242) in subscriber firewall filters
(MX Series routers)—You can now configure subscriber management to use ascend
data filters (ADFs) to create and apply firewall filters to subscriber traffic. The ADF
creates a rule that specifies match conditions on the source and destination IP address,
the protocol, and the source and destination port, and also specifies the action to
perform (such as accept or discard). The ADF rule also specifies the filter direction,
and can optionally provide traffic class and policer information. The router supports
ADF rules for family types inet and inet6.
Subscriber management uses dynamic profilestoobtain the ADF rules from the RADIUS
server. You can use the new Junos OS predefined variables ($junos-adf-rule-v4 for
familyinet and $junos-adf-rule-v6 for inet6) to map ADF rules to Junos OS functionality,
or you can statically create ADF rules.
[Subscriber Access, System Basics and Services Command Reference]
•
Per-interface DHCP tracing operations (MX Series routers)—In addition to the existing
global DHCP tracing operation, you can now trace DHCP operations for a specific
interface or a range of interfaces.
Configuring interface-based tracing is a two-step procedure. First configure the tracing
options that you want to use, such as the file used for the trace operation and the trace
flags. In the second step, enable the tracing operation on the specific interface or range
of interfaces.
•
To configure the per-interface tracing options, use the interface-traceoptions
statementat the [edit system services dhcp-local-server] hierarchy levelfor the DHCP
local server or at the [edit forwarding-options dhcp-relay] hierarchy level for the DHCP
relay agent.
•
To enable tracing on an interface or interface range, use the trace statement at the
[edit system services dhcp-local-server group group-name interface interface-name]
hierarchy level for the DHCP local server, or the [edit forwarding-options dhcp-relay
group group-name interface interface-name] hierarchy level for the DHCP relay agent.
You can also enable tracing for DHCPv6 at the [edit system services dhcp-local-server
dhcpv6 group group-name interface interface-name] hierarchy level.
[Subscriber Access]
•
Automaticbinding of stray DHCP requests (MX Series routers)—The default behavior
has changed for handling DHCP requests that are received but which have no entry in
the database (stray requests). Beginning with Junos OS Release 10.4,automatic binding
of stray requests is enabled by default. In Junos OS Release 10.3 and earlier releases,
automatic binding of stray requests is disabled by default.
By default, DHCP relay and DHCP relay proxy now attempt to bind the requesting client
by creating a database entry and forwarding the request to the DHCP server. If the
server responds with an ACK, the client is bound and the ACK is forwarded to the client.
If the server responds with a NAK, the database entry is deleted and the NAK is
forwarded to the client. This behavior occurs regardless of whether authentication is
configured.
In Junos OS Release 10.3 and earlier releases, DHCP relay drops stray requests and
forwards a NAK to the client when authentication is configured. Otherwise, DHCP relay
attempts to bind the requesting client. In those releases, DHCP relay proxy always
drops stray requests and forwards a NAK to the client, regardless of the authentication
configuration.
You can override the new default configuration to cause DHCP relay and DHCP relay
proxy to drop all stray requests instead of attempting to bind the clients. To disable
automatic binding behavior globally, include the no-bind-on-request statement at the
[edit forwarding-options dhcp-relay overrides] hierarchy level. To disable automatic
binding behavior for a group, include the statement at the [edit forwarding-options
dhcp-relay overrides group group-name] hierarchy level. To disable automatic binding
behavior for a specific interface in a group, include the statement at the [edit
forwarding-options dhcp-relay overrides group group-name interface interface-name]
hierarchy level.
[Subscriber Access]
•
Support for VPLS Layer 2 wholesale configuration in a subscriber access
network—Enables you to configure Layer 2 wholesaling within a subscriber access
network. Wholesale access is the process by which an access network provider
(wholesaler) partitions the access network into separately manageable and
accountable subscriber segments for resale to other network providers. An access
network provider may elect to wholesale all or part of its network to one or more service
providers (retailers).
NOTE: In this release, Layer 2 wholesaling supports the use of only the
default logical system using multiple routing instances.
The Juniper Networks Layer 2 wholesale solution is similar to the Layer 3 wholesale
solution in many ways. However, when configuring the Juniper Networks Layer 2
wholesale solution, keep the following in mind:
•
No Layer 3 components (address assignment, Layer 3 interfaces, and so on) are
involved.
•
S-VLANs must be unique to any Gigabit Ethernet or Aggregated Ethernet interfaces
within the entire network (not just unique to one router).
•
Layer 2 wholesale supports only CoA disconnect and variable modification; CoA
service activation is not supported.
NOTE: For general information about configuring dynamic wholesale for
your subscriber access network, see the Broadband Subscriber Management
Solutions Guide.