Professional Documents
Culture Documents
ASR9000/XR - BNG Deployment Guide
ASR9000/XR - BNG Deployment Guide
Introduction
Broadband deployments are complex because of the options you have, varying
needs in terms of deployments, the combination of technologies and many other
reasons. In this article we'll go over the various designs, options and service
deliverables that you can achieve with the ASR9000 BNG solution.
Access models
One of the decissions to be made when running BNG is the type of access that is
preferred. There are 2 key options for the ASR9000 which is PPPoE (PPP over
Ethernet) or IP sessions. Both can run on single or double tagged subinterfaces.
PPPoE sessions are triggered by the reception of a PADI and IP sessions are
created by using DHCP as a session trigger.
In XR4.2.1 we can also use the "packet trigger" which means that an unclassified L3
address can be used to start a new session.
Also one has to decide on the Access interface, whether that is a single physical
interface or access via bundles with multiple members. When choosing bundles the
next decission is whether the members run in an active/active mode (that is all
members are forwarding traffic) or in an active standby mode (whereby there is one
link not forwarding traffic and only taking over when one of the member(s) fails).
When you are running bundles, the sessions are then maintained on the RSP.
The LC's currently have their own Control Policy Engine, PPP manager and AAA
processes. But they lack IGMP and LI today. This means that if you are planning to
use LI or IGMP or parameterized QOS LC based subscribers should not be the
choice for you.
You can use bundle interfaces with one member and disabling LACP to pull the subs
to the RSP so that you have access to these features:
interface GigabitEthernet0/0/0/0
When you are using bundle interfaces, all features enabled on the subscriber are
programmed to the NP's where the bundle has members on.
For downstream loadbalancing we can use destination based hashing, which is the
subscriber's ip address, so we always hash the traffic from one subscriber over 1
member, but the subscribers would be spread over the members based on their
destination address.
interface Bundle-Ether100
When one member fails, the traffic is carried over to the other member seemlessly.
For the upstream direction, we can't control how the traffic arrives to us, which is
controlled by the access layer device, whether that be your metro device or DSLAM.
This is an XR 5.1.1 deliverable. LC subs will increase the scale even further as it
distributed the control plane to the LC as opposed to the RSP.
Hardware requirements
The hardware you require for BNG on the ASR9000 is:
Note that for both the RSP and the linecard we need to have the "SE" or Service
Edge variant.
Trident linecards are not supported for subscriber termination, but they can be used
as core facing linecard for transport
The MOD80 is a 2NP based linecard. Per NP we support 32k sessions with 64k per
linecard.
Per Port we support up to 8K sessions when they are running QOS. This because of
the QOS architecture within the NP that won't allow more then 8k parent shapers per
phyiscal port. (that restriction is partially lifted in XR4.3.1 which allows for QOS
chunk allocation more dynamically. You still have 32k parent shapers, but you can
instruct a subinterface to use a chunk. This means a limitation of 8k per vlan, 32k per
NPU)
These retrictions apply regardless of whether you are using LC or RSP based
subscribers.
All linecards that run BNG need to be of the Typhoon kind (NP4). Your core facing
interfaces if not running BNG can be Trident based or SIP700 based. However if you
are using L2TP, then your core facing LC's need to be NP4 also. This is because the
L2TP decap is not implemented in SIP or Trident which is handled by the core facing
LC in the downstream direction.
Radius Source Ports
Each LC is assigned a source port range for radius, so while all LC's present
themselves as a single NAS-ID, the source ports they are using effectively identify
the node within the system. This is transparent for your use and nothing needs to be
configured for that.
However it is imperative that your radius server supports extended source-ports (so
the combination of source-port + radius-request-ID) defines a unique request. This is
the same in IOS otherwise you can only support a call window of 256 (as the radius
ID is only an 8 bit field). So check your radius-server capability!
This radius (accounting) request was sent from UDP Port 49080 and its radiusID is
number 12
You can check in LPTS in IOS-XR where that source port is mapping to:
The "1" represent the RSP's in the middle slot of a 10 slot chassis!
PPPoE vs DHCP/IP-sessions
Broadband access has natively been using PPP based access, which originates
from the dial days, whereby modems dialing into a modem-bank/access server
allowing the transmission of data packets by encapsulating them in PPP packets.
When access evolved to higher speeds using DSL (effectively ATM over the phone
line), PPP was still used in the flavor of PPPoA (PPP over ATM).
Now that the aggregation point's uplinks are transitioning from ATM based to
Ethernet based and the fact that there is Ethernet directly to the home, PPPoE has
made a strong hold in the access layer.
Still with DSL in the first mile, DSLAM's may convert the PPPoA session into PPPoE
towards the aggregator leaving PPP with a (well deserved) strong precense in the
access.
In a transition to an all ethernet, there is no need per-se to run PPP at the access.
PPPoE requires a client (which nowadays come natively in many operating systems
however), which created the opportunity for a more simple approach of direct IP
access using DHCP as a signal to trigger the session creation.
This this is a base configuration example to setup the FSOL handling for PPPoE or
IP sessions.
Using ambigious vlans
Originally for double tagged traffic, also known is QinQ or QiQ, we had to explicitly
configure the inner and outer vlan combination for each possible termination point. In
ASR9000/XR we can define ambigious ranges allowing us to specify the outer vlan
only and an inner range.
The most common deployment scenario for QIQ is whereby the outer vlan
represents the dslam and the inner vlan represents the subscriber, obviously
configuring 64k subinterfaces is not very easy to manage and the Ambigious vlan
support greatly reduces operational overhead, large configs and provides for much
more simplicity:
Configuration example:
interface Bundle-Ether1.50
service-policy type control subscriber PPP_IP_PM1
pppoe enable bba-group default
encapsulation ambiguous dot1q { any | <vlan range> }
dot1ad { any | <vlan range> }
dot1q <vlan#> second-dot1q { any |
<vlan range> }
dot1ad <vlan#> second-dot1q { any |
<vlan range> }
DHCP/IP sessions
PPP sessions have a native keepalive build in. If keepalives are not sent between
the BNG and the client, the sessions are automatically torn down. IP sessions don't
have a native keepalive mechanism and some implementations opted for an ICMP
or ARP keepalive methodology to detect absent IP sessions as opposed to relying
on (potentially long) DHCP lease timers.
ASR9000 does not have ICMP or ARP keepalives for IP sessions rather instead we
have a different mechanism of lease-proxy which is elaborated on in this section.
Restart handling
Problem domain 1:
IPoE sessions are initiated upon receipt of a DHCP discover and can be terminated
prior client’s IP address lease expires/is released by:
● CoA Account-Logoff/PoD
● Session Administratively cleared
● Reload
To support a sort of keepalive mechanism we can shorten the lease time, which will
require the session to renew its lease at half the lease time. So we effectively have a
keepalive mechanism at half-lease time in this scenario.
This inherently increases the load on the dhcp server because the BNG will forward
the renew requests to the dhcp server and when Acknowledged it will maintain the
binding and the session.
A smoother solution is the concept of "lease proxy". This means that eventhough the
server offers a lease, in this example of 40 minutes, the BNG advertises a lease to
the client of a configurable time, in this example 10 minutes.
Every 5 minute interval the client will renew, but now the BNG intercepts and
re-acknowledges the lease to the client, as opposed to relying on the dhcp server to
ack the renew.
At half the lease time, here 20 minutes, we renew with the dhcp server to maintain
proper state.
eg.,
dhcp ipv4
per circuit-id:
eg.,
dhcp ipv4
or
per interface:
eg.,
dhcp ipv4
Note that per circuit-id and per remote-id options are confined to any given access
interface. In other words, per circuit id limit on a given access interfaces doesn't
affect
or influence the circuit-id limit configured for any other access interface
Lease proxy:
DHCP lease proxy is also known as DHCP split lease. With this implementation, the
DHCP proxy
ie., BNG router will renew the lease of the client without contacting the DHCP server.
The
lease proxy value configured is assumed to be lower than the server lease.
Following terminologies
are used:
Configuration:
dhcp ipv4
dhcp ipv4
You can authenticate the user on mac address or option 82 information. The
following use cases depict on how to set that up with the ASR9000 BNG
implementation.
Example TAL use case 2
IP sessions and security forwarding
When your access interface is configured for IP it by nature can start forwarding IP
already. A session that takes a static source ip can start forwarding traffic just fine
then.
This could be a security issue and this has been done at the explicit request from
some our initial adopters of A9K BNG.
Downstream traffic can only flow on AMBIGUOUS vlans when we have a session
since the mapping from destination IP to mac and vlan is only held by the dhcp
binding. In UNAMB scenarios, we could technically send traffic down to the sub.
● uRPF
● ACL
a received packet from an IP source on the access interface when the "unclassified
In an ideal network, the subscriber would first send an ARP request to the access
interface and if the packet matching criteria are met, this in itself is a sufficient
condition to bringup the IPoE session. However, if there is a burst of traffic with
unique flows, this could overwhelm the BNG router in terms of processing each
packet
requests to 200. In cases where traffic rates for IPoE-PKT sessions are high (>120
pps) and
there are also parallel DHCP based sessions creates in progress, it may be
desirable to
configure static policer on the line cards. Based on testing results, a policer rate of
200 per LC is shown to handle this stress condition satisfactorily.
Configuration:
RP/0/RSP0/CPU0:BNG1#config
interface Bundle-Ether10.41
encapsulation dot1q 30
initiator dhcp
initiator unclassified-source
end-policy-map
end-class-map
dynamic-template
!
Using Control Polices
One integral part of the BNG solution in XR is the use of control policies.
With control policies you are able to manage the sessions life while various events
on the session are triggered.
You can handle these events or ignore them depending on your configuration and
deployment needs.
User authentication/control
One key action in the control policy is obviously the authentication.
These can be executed via the command under the event/class:
Both of these will trigger a RADIUS access-request message, but the difference
between the two is with the authorize statement we can compose the username
ourselves regardless of what is received on the line, where as the authenticate
statement uses the PPP chap or pap username and password received. The
authenticate option for that reason only applies to PPP based sessions.
You can define the username in the authorize statement either inline as per example
above or you can construct the username via a "formatted" way:
Note that an authentication does NOT have to succeed in order for BNG to bring up
the session.
The activation of a dynamic template will create the subscriber interface regardless
of the authentication result.
Nas identification
Source IP
Building configuration...
Route metric is 0
No advertising protos.
interface MgmtEth0/RSP0/CPU0/0
RADIUS:
Thu Mar 15 11:55:12 2012: [18848] NAS-IP-Address = 3.0.0.233
Nas-Port-ID
Attribute 87 can be filled with the configuration like this:
Nas-ID
Attribute 32 is the BNG's hostname, always and only configurable when changing
the router's hostname.
Example:
hostname A9K-BNG
RADIUS:
Thu Mar 15 11:55:12 2012: [18848] NAS-Identifier = "A9K-BNG"
Nas-PORT
Attribute 5
Type
ETHERNET 15
PPPOEOE 32
PPPOEOVLAN 33
PPPOEOQINQ 34
VIRTUAL_PPPOEOE 35
VIRTUAL_PPPOEOVLAN 36
VIRTUAL_PPPOEOQINQ 37
If type is omitted it will apply and be used for any session without a more specific
type definition.
The folllowing pictures shows how everything ties together in a control policy:
The diagram below shows where the various events would be triggered for a PPPoE
session.
Note that the session activate event is only applicable to PPP sessions.
You need to make sure that the session-start event has a template defined with the
lcp paramters
the power of the solution, amongst many others, is the differentiation you can do
between authentication failures as well as no response,
so you can act upon a faulty username differently then a radius-server not
responding.
Failover for that reason can be embedded in the control policy like this:
event authentication-failure
class ...
event authentication-no-response
Using Class-Maps
The class map definition allows you to control how the event triggered is handled.
Either the event is handled for the first class that is matched, or ALL classes for this
event are evaluated as part of the event definition directive.
Example:
class-map type control subscriber match-any IP_SUB
match protocol dhcpv4
! The above would match specifically on IP subscribers only
If you only have 1 match clause in your class-map it obviously doesn't make a
difference whether you choose match-all or match-any.
Also the class-maps allow for very extensive control of the event handling whereby
you can handle a particular event differently for an unauthenticated ppp subscriber
vs an authenticated ip subscriber or any combination of that of course!
So the order of actions executed during an event is very important along with using
do-until-success/failure etc.
Alternatively, you can pull in the event for authorization failure and disconnect the
service like this:
10 disconnect
Or you can use the authorization failure to apply HTTP-Redirect and start a timer, so
effectively allowing the user to login within that time before he is getting
disconnected.
Account Logon
If the user failed authentication and has a restricted access service applied, we can
force the user to go the web portal to provide credentials and try to login again, pay
their bill etc.
The model is here that the user goes to a web page to provide credentials that are
then send via a coa account logon to the BNG.
The BNG will generate an access request to authenticate using these credentials.
Multiple ranges can be provided and addresses in that range can be excluded.
Allocation Summary
---------------------------------------------------
Used: 1
Excl: 0
Free: 65278
Total: 65279
Utilization: 0%
The Pool can either be referenced directly on the dynamic template which is
activated to the subscriber during its event handling in the control policy like this:
This is the template that holds the base configuration for subscribers when this
template gets activated on the session:
dynamic-template
This template can then be referenced in an event handling of the control policy as
with this example:
Alternatively the POOL can also be referenced via Radius Attributes during the
Access-Accept as per following example:
● With a Cisco-Avpair
Service-Type = Framed-User,
Framed-Protocol = PPP,
Cisco-avpair = "ipv4:addr-pool=POOL",
Framed-Pool = POOL
Using this method of locally defined pools on the BNG is by far preferred because it
allows us to create a summary route and advertise the pool in its whole. This
reduces significant amount of routing updates, but has the limitation that a full block
is assigned to the BNG regardless of whether it needs it or not.
Pool advertisement
Can be done via the following methodology:
router static
199.1.0.0/16 Null0
Next inject that summary route into your eg IGP via a redistribution command
redistribute static
When users come online they will have a /32 in the routing table which is then
followed for forwarding rather then the summary route to NULL0.
IT is recommended to have the radius server select a pool per BNG device, this in
order to keep the model of summary advertisement.
If the pool attributes are distributed between different BNG's, you're required to inject
the /32's which will put unnecessary burden on your IGP.
In this case you probably want to consider STUB areas to keep the /32's only floating
in your OSPF STUB area and summarize them at the area border.
Radius based pools rely on the accounting mechanism from AAA to learn whether
addresses are in use or not.
This requires a strong Accounting back end on the radius-server and obviously
proper delivery of your AAA records.
The way to achieve this is via the radius attribute Framed-IP-Address (IETF number
8).
IP sessions
IP sessions address assignment is done via a DHCP Server. IOS-XR release 4.3.0
will come with an on board dhcp server.
In today's model the dhcp server is responsible for handing out addresses which are
picked based on the "giAddr" field in the dhcp discover which is filed in by the DHCP
Proxy component of the ASR9000.
In this example we set the dhcp server to 81.1.1.2, the giAddr for pool selection is
set to the red value to instruct the dhcp server where to pick an address from. The
giAddr selection in this example is based on the dhcp option 60, vendor Class which
is matching a hex string.
dhcp ipv4
class MATCHALL
class HardPhone1
class HardPhone2
dynamic-template
Which has then address in the same pool range as the giAddr and the dhcp server
will want to set the default-router option to this value.
interface Loopback12
Including Loopback 12 (passively) in your IGP will provide for proper downstream
routing!
1. Dynamic Template
2. Radius/Access-Accept (also known as Policy PULL)
3. COA (also known as Policy PUSH)
So that means that local template configuration can be overridden by RADIUS,
which can be overidden by COA.
Here are a few examples on how to match a CLI Configuration to a radius attribute,
full documentation is available in the XR configuration guide.
The picture below shows the different stages of PPP and which timers apply that
need evaluation.
The referenced timers can be configured on the dynamic template for PPP
subscribers:
Quality of Service
QOS application to the session can be done via static configuration in the dynamic
template, or the policy-map name can be referenced via Cisco AVP's in RADIUS
access-accept or COA requests.
QOS can be applied at the port level, vlan level (subinterface) and at the session
level with classes in a hierarchical manner.
Parameterized QOS
Parameterized QOS is a very powerful option in ASR9000 BNG. It allows you to
construct the policy-map and its values from the AAA server.
Note however that if you have defined a static policy-map via configuration to the
dynamic template or from radius
If you desire to use pQOS the initial policy-map needs to be pQOS'd also.
You can modify pQOS policies on a per class basis and while the session is active
add or remove classes dynamically as you go!!
To see pQOS in action and the benefits see this video on demand BNG demo on YOUtube
VSA definition
Understanding the format of the Vendor Specific Attribute for Parameterized QOS
(pQOS).
VSA(9-1)”qos-policy-in:add-class(
<target-specifier>,(<class-list>),<qos-action-params> )”
TARGET:
sub – The QoS policy attached to the subscriber session. This implies that the
CoA/Access-Accept target must be a subscriber session.
CLASS:
(class-default)
This example identifies the class “class-default” on the parent-policy.
(class-default,voip)
This example identifies a leaf class “voip”. This class will be added to or removed
from a nested child policy specified under the class “class-default” of the policy
attached to the target.
(class-default,voip-aggregate,voip-1)
This example specifies a leaf class “voip-1”. This class will be added to or removed
from a nested child policy specified under the class “voip-aggregate” of the policy
which is in turn nested under “class-default” of the policy attached to the target
ACTIONS:
See this next section on how to map IOS-XR MQC (modular Qos
configuration) actions to the parameterized QOS equivalent.
Examples
Policing
CLI Equivalent: police <bps> <burst-normal> <burst-max> <burst-size>
conform-action <action> exceed-action <action> violate-action <action>
police(CIR,CBS,PIR,PBS,conform-action,exceed-action,violate-action)
VSA value:
qos-policy-in:add-class(sub,(voip),police(200000,9216,0,0,transmit,drop,drop) )
Shaping
CLI Equivalent: shape <shape-rate>
VSA value: qos-policy-out:add-class(sub,(class-default),shape(14700))
For complete COA examples check the Change of Authorization document
Coming soon!!
Most of the time you may want to control the number of in flight sessions so you can
streamline the number of radius access requests that are being sent to the RADIUS
server.
The way to monitor and control the in flight sessions is via this command :
Limit means the number of in lfight sessions you want to control on a per node
basis. A node constitutes a pppoe processing entity which is either the LC for
phyiscal interface based sessions or the RSP when using bundle interfaces. This
number is configurable via the followingcommand:
RP/0/RSP0/CPU0:A9K-BNG(config)#pppoe in-flight-window 2000
Default value is 200, recommended for RP-based subscribers. Recommended value
for LC-based subscribers is 50.
In Flight is the number of sessions we are currently handling and have not fully
established yet. A fully established session is the signal from the session control
entity that the subscriber interface is up and forwarding
Dropped are the sessions when the in flight session number exceeds the Limit set.
Disconnected how many sessions ahve been disconnected for normal reasons, eg
send a PADT etc.
AAA
Throttling
This feature supports throttling of access (authentication and authorization) and
accounting records
that are sent to the radius server. Throttling rate can be configured separately for
access
and accounting requests. When the threshold is reached for a server, no more
requests of that type
will be sent. A retransmit timer is started when the threshold limit is reached. After
expiry of
the retransmit timer, the queue is checked to see if the outstanding requests is less
than the
configured limit. If so, then the request is sent out to the radius server
AAA throttling can be configured globally or at the server group level. Throttling
configured
configuration:
Subscriber Services
Services constitute a set of features under a common umbrella.
These features are enabled together constituting the service defintion.
For instance you can allow users to access or deny parts of the network, or modify
its qos parameters.
Dynamic templates allow for inline modifications, changes take effect immediately on
all sessions using template, with the exception: unmutable config options (e.g
session IP address)
dynamic-template
attribute 44 “<string>”
Account Logon
attribute 1 "<username>
Cisco-avpair = "subscriber:password=<subscriber
password>
Cisco-avpair = "subscriber:command=account-logon"
attribute 44 “<string>”
Account Logoff
Cisco-avpair = "subscriber:command=account-logoff"
attribute 44 “<string>”
Account Update
Cisco-avpair = "subscriber:command=account-update”
attribute 44 “<string>”
Service De-activate
Cisco-avpair = "subscriber:command=deactivate-service"
Cisco-avpair = "subscriber:service-name=<service-name>”
Attribute 44, or accounting session ID is always used for fastest lookup of the
subscriber session.
COA tool is available on the forum for Windows, MAC/OSX and Linux.
Cluster and Satellite are part of the ASR9000's nV concept (Network Virtualization).
Cluster
Cluster is the concept of binding two physical chassis together into 1 logical unit. The
control plane is extended via RSP on board 1 or 10G interfaces while the data plane
is extended via 1 or more physical interfaces on the linecards.
So when building a bundle from the access side, if you link them to each individual
chassis you'll have an active active bundle with failover between chassis!
Also the physical ASR's don't need to be on the same location. Only the control
plane extension needs to have minimum latency (~<20msec).
Satellite
Allows for port extension into a simple 1RU chassis with large 1G port fan out.
The Satellite connects via 1 or multiple 10G uplinks ot the ASR9000 host.
You can statically pin ports to an uplink or share an uplink via a bundle to multiple
ports.
Satellite interfaces appear in teh ASR9000 config as if they were physically on the
ASR9000.
nv
satellite 100 •ß define satellite ID
description my lovely satellite
type asr9000v
Wholesale Models
Most of the documentation here has been talking about locally terminating the
subscribers on the BNG for regular access. Obviously there deployment models
whereby a provider may like to just provide the initial termination on behalf of the
wholesale provider.
● L2TP tunneling
● RAMPLS
IP sessions
IP sessions only have one option for wholesaling which is inserting the subscribers in
a VRF and using MPLS VPN to transport the data traffic to the wholesale provider.
RAMPLS
(Remote Access into MPLS-VPN) Is the concept of terminating the subscriber
sesisions locally on the BNG and insert them in a specific vrf. This vrf is a separate
routing context and using MPLS-VPN to transport the users traffic to the wholesale
provider.
L2TP
Layer 2 Tunnelling Protocol is the concept of transporting the PPP session over to
the wholesale provider's LNS.
ASR9000 can only function as LAC which basically means that after authentication
we are creating a tunnel or inserting the user into an existing tunnel over to the LNS.
Doubledip
L2TP has as key advantage that the subscriber's PPP session is sent over to the
LNS. This allows the LNS to have full control over the PPP session including
authentication.
RAMPLS doesn't have such an option as the only Authentication stage is done on
the BNG one time.
The concept of "double dip" is a phenomenal extension allowing you to use a local
radius server on teh BNG and then contact the wholesale provider's AAA server and
merge the profiles together:
On the ASR9000 BNG you can filter the attributes from the retailer to make sure that
they don't override the user's vrf for instance like this:
radius-server attribute list RETAILER_X_ATTR_LIST
attribute <accepted or rejected attribute-list>
!
aaa group server radius RETAILER_X_SG
authorization reply { accept | reject } RETAILER_X_ATTR_LIST
vrf RETAILER_X_VRF
server-private 10.10.10.100 auth-port 1645 acct-port 1646
!
!
ICMP Unreachables
ICMP unreachables can significantly increase the CPU utilisation on line cards,
especially if security access lists are enabled on seubscriber interfaces. You can
disable the generation of ICMP unreachables in subscriber access interface
configuration or dynamic template configuration:
or in radius profile:
Cisco-avpair="ipv4-icmp-unreachable=1"
ARP
In deployment scenarios with IP unnumbered and loopback interfaces with multiple
secondary IP addresses, the ARP table size grows very quickly. Since on subscriber
interfaces the MAC to IPv4 mapping is known through either DHCP or PPPoE, ARP
entries are not required. On XR release 5.3.3 and later you can prevent the creation
of ARP entries associated with subscriber interfaces by configuring: