Cisco ISG Design and Deployment Guide: Gigabit Ethernet Aggregation Using Cisco IOS Software Release 12.2(31)SB2
Available Languages
Table Of Contents
Information About ISG and GE Aggregation
GE Aggregation Platform Support
GE Aggregation High-Level Network Topology
IEEE 802.1Q Tunneling (Q-in-Q)
Basic Configuration Requirements
GE Deployment Models for Cisco IOS Software Release 12.2(31)SB2
Model 1: Authenticated IP Sessions over a .1Q Interface
Call Flow for Session Initiation
Call Flow for Bandwidth Upgrade
Model 2: Authenticated IP Sessions over a Q-in-Q Interface
Call Flow for a DHCP-Initiated Session
Model 3: Authenticated PPP Sessions over a Q-in-Q Interface
Call Flow for the Prepaid Feature
Call Flow for a Dynamic MQC/QoS Change
Model 1 Configuration: Authenticated IP Sessions over a .1Q Interface
Configuring Subscriber Access for Model 1
Configuring ISG to AAA Server Interfaces for Model 1
Configuring the User Profile on the AAA Server for Model 1
Configuring Service Profiles on the AAA Server for Model 1
Configuring Inbound and Outbound Access Lists for Model 1
Configuring the Policy/Portal Server Interface for Model 1
Configuring the CoA Interface in the ISG for Model 1
Configuring the Policy/Portal Server for CoA for Model 1
Configuring ISG to Support PBHK for Subscriber Access to the Portal for Model 1
Configuring Layer 4 Redirect for Model 1
Configuring ISG Control Policies for Model 1
Configuring the DHCP Server and DHCP Classes for Model 1
Configuring the Multiservice Interface for VRF Transfer for Model 1
Configuring mBGP and VPNv4 for Model 1
Configuring the Remote PE Side for Model 1
Model 2 Configuration: Authenticated IP Sessions over a Q-in-Q Interface
Configuring Subscriber Access for Model 2
Configuring ISG to AAA Server Interfaces for Model 2
Configuring the User Profile on the AAA Server for for Model 2
Configuring Service Profiles for Model 2
Configuring Inbound and Outbound Access Lists for Model 2
Configuring the Policy/Portal Server Interface for Model 2
Configuring the CoA Interface in the ISG for Model 2
Configuring the Policy/Portal Server for CoA for Model 2
Configuring ISG to Support PortBundle Host Key for Subscriber Access to the Portal for Model 2
Configuring Layer 4 Redirect for Model 2
Configuring ISG Control Policies for Model 2
Configuring the DHCP Server and DHCP Classes for Model 2
Configuring the Multiservice Interface for VRF Termination for Model 2
Configuring mBGP and VPNv4 for Model 2
Configuring the Remote PE Side for Model 2
Model 3 Configuration: Authenticated PPP Sessions over a Q-in-Q Interface
Configuring Subscriber Access for Model 3
Configuring ISG to AAA Server Interfaces for Model 3
Configuring the User Profile for Model 3
Configuring Service Profiles for Model 3
SERVICE_403_PL4R: Periodic Layer 4 Redirect Service
Configuring Inbound and Outbound Access Lists for Model 3
Configuring the Policy/Portal Server Interface for Model 3
Configuring the CoA Interface in the ISG in Model 3
Configuring the Policy/Portal Server for CoA in Model 3
Configuring ISG to Support Port-Bundle Host Key for Subscriber Access to the Portal in Model 3
Configuring the Prepaid Server for Model 3
Configuring Layer 4 Redirect for Model 3
Configuring ISG Control Policies for Model 3
Configuring QoS Policies for Model 3
Configuring mBGP and VPNv4 for Model 3
Configuring the Remote PE Side for Model 3
Configuration Verification Commands
ISG Configuration Information Verification
Basic ISG Operation Verification
Subscriber Service Verification
ISG Prepaid Service Verification
Cisco ISG Design and Deployment Guide:
Gigabit Ethernet Aggregation Using
Cisco IOS Software Release 12.2(31)SB2
First Published: November 27, 2006Last Updated: January 25, 2010This document uses model networks tested in a Cisco laboratory to describe how to deploy a service provider broadband-based network using Cisco 7200, 7300, and 10000 series routers as a Cisco Intelligent Services Gateway (ISG) and Gigabit Ethernet (GE) as the aggregation technology. The Cisco ISG software provides a feature set that assists the service provider with provisioning and maintaining broadband networks that have many types of edge devices and many subscribers and services. The Cisco ISG software combines real-time session and flow control with programmable, dynamic policy control to deliver flexible and scalable subscriber session management capabilities. The role of the Cisco ISG software is to execute policies that identify and authenticate subscribers and to provide access to the services that the subscriber is entitled to access. The role of the Cisco ISG router is deployment at network access control points so subscribers can access services through the software.
ISG Software Feature Sets
Cisco IOS software is packaged in feature sets that are supported on specific platforms. The Cisco ISG software is supported on Cisco 7200, 7300, and 10000 series routers. To get updated information regarding platform support and ISG feature sets, access Cisco Feature Navigator at http://www.cisco.com/go/fn. To access Cisco Feature Navigator, you must have an account on Cisco.com. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register. If you have an account but have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you.
Contents
•
Information About ISG and GE Aggregation
•
•
•
•
•
Information About ISG and GE Aggregation
This section provides the following information about ISG and GE aggregation:
•
•
GE Aggregation
Higher-performance LAN segment capacity and faster response times are needed to ease the demands placed on networks brought about by increases in the numbers of users buying faster computers and using bit-intensive applications such as video and gaming. Centralized, high-performance servers also contribute to traffic congestion. GE provides both the infrastructure and the bandwidth needed to ease response to the demands of increased network traffic. GE provides 1000 Mbps of raw bandwidth and is built upon the existing Institute of IEEE 802.3 Ethernet standard. The installed base of over 70 million Ethernet nodes and GE's adherence to the Ethernet standard make GE a logical choice for deployment in high-speed broadband networks. Ethernet supports a variety of physical media with different maximum link distances, including copper-based links, fiber optic, and Category 5 unshielded twisted-pair (UTP) wiring.
The shift towards Ethernet-based solutions offers the following benefits:
•
•
•
•
The result of deploying GE in a broadband-based network such as digital subscriber line (DSL) is the delivery of higher-bandwidth services at lower cost than other broadband aggregation methods while preserving quality of service (QoS).
The result of configuring an ISG is a collection of powerful and dynamic policies that can be applied to Internet subscriber sessions. The new policies are a superset of the Service Selection Gateway (SSG) concept of a service. With the ISG software, new subscriber rules allow you to build policies based on conditional events by triggering service actions. Services can be implemented within virtual routing contexts.
The dynamic policy enforcement inherent in the ISG software allows consistent, tailored, and secure user services to be deployed in the network, triggered by a service or by a user—concepts referred to in the ISG software as push and pull.
The ISG has the ability to initiate and manage sessions consistently, regardless of the access protocol type, network service, or session traffic policies configured. The ISG software provides seamless integration with existing Cisco IOS IP services such as Domain Name System (DNS), access control lists (also access lists or ACLs), Dynamic Host Configuration Protocol (DHCP), virtual private network (VPN) routing and forwarding (VRF) instance, and Multiprotocol Label Switching (MPLS).
The ISG software also provides enhanced accounting of the subscription services for both use and application, and for advanced accounting for such features as prepaid service. You will also find enhanced distributed conditional debugging that provides the ability to monitor and debug sessions and services based on identity.
GE Aggregation Platform Support
Cisco's broadband aggregation portfolio offers comprehensive solutions that provides innovative technologies for simplified operations, revenue-generating network services, comprehensive management, and proven high availability for broadband service deployment. The aggregation of traffic received from a GE-based DSL network element is supported by the following Cisco hardware:
•
•
GE Aggregation High-Level Network Topology
Figure 1 shows basic network elements in a GE-based network topology.
Figure 1 GE Aggregation Network Elements
The following elements play key roles in the network topology shown in Figure 1:
•
•
•
Note
•
•
•
•
•
•
•
•
Network Access Models
Figure 2 provides a high-level view of the protocol stacks that are used in GE-based network topologies.
Figure 2 Protocol Stacks
IP over Ethernet is routed to the ISP via the BRAS. The identity of the customer is maintained at Layer 2 by a unique customer source MAC address all the way to the BRAS. It is possible to insert IP routed application services at the BRAS. IP address allocation mechanisms must be tightly coordinated between the ISP and the BRAS operators, especially if run by different companies.
The CPE is typically an ADSL modem or ADSL Transmission Unit—remote (ATU-R). The CPE communicates to the rest of the network through a customer edge (CE) router.
The following sections summarize the network access types used in the ISG GE network:
•
•
DHCP
As described in RFC 2131, Dynamic Host Configuration Protocol, DHCP provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocating network addresses to hosts. DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. By default, Cisco routers running Cisco IOS software include DHCP server and relay agent software.
DHCP supports three mechanisms for IP address allocation:
•
•
•
Automatic DHCP address allocation is typically based on an IP address, whether it be the gateway IP or the incoming interface IP address. In some networks, it is necessary to use additional information to further determine which IP addresses to allocate. Using the relay agent information option (option 82) permits the Cisco IOS relay agent to include additional information about itself when forwarding client-originated DHCP packets to a DHCP server.
IP Sessions
An IP session includes all the traffic that is associated with a single subscriber IP address. If the IP address is not unique to the system, other distinguishing characteristics such as VRF or a MAC address form part of the identity of the session. An ISG can be configured to create IP sessions upon receipt of DHCP messages (packets) and unknown IP source addresses. IP sessions may be hosted for a connected subscriber device (one routing hop from the ISG) or one that is many hops from the gateway.
The following events may be used to signal the start of an IP session:
•
If the following conditions are met, receipt of a DHCPDISCOVER message will trigger the creation of an IP session:
–
–
–
•
In the absence of a DHCPDISCOVER message, a new IP session is triggered by the appearance of an IP packet with an unrecognized source IP address.
•
In the absence of a DHCPDISCOVER message, a new IP session is triggered by the appearance of an IP packet with an unrecognized source MAC address.
•
A new IP session can also be triggered by the appearance of a RADIUS Access-Request packet. The RADIUS proxy record is basically an insertion mechanism that allows an ISG device to be introduced to a network with minimum disruption to the existing AAA servers.
Because there is no inherent control protocol for IP sessions, the following events can be used to terminate a session:
•
•
•
•
•
IEEE 802.1Q
The IEEE 802.1Q protocol was developed to allow multiple bridged networks to share the same physical network link transparently without leakage of information between networks. The standard addresses how to break up large networks so that broadcast and multicast traffic does not take more bandwidth than is necessary. The standard also allows for individual virtual LANs (VLANs) to communicate with one another using a router.
The IEEE 802.1Q protocol establishes a method for inserting virtual VLAN membership information into Ethernet frames. The term VLAN refers to the ability to virtualize a LAN.
IEEE 802.1Q Tunneling (Q-in-Q)
Without VLANs, all subscribers in a switched network would be in the same broadcast domain. Dedicating a VLAN to each customer is possible but impractical because of the 4096 global VLAN limit in the IEEE 802.1Q protocol. It is more common to configure one single VLAN per switch, but this configuration still leaves all users on the same switch in the same broadcast domain. Private VLANs can be used to solve this issue, but another alternative is to use double VLAN encapsulation, where traffic from each subscriber's port is mapped to a different 802.1Q tag, and then each frame is tagged again when it leaves the switch with a tag that uniquely identifies the switch on the Ethernet network.
Double VLAN encapsulation adds another layer of IEEE 802.1Q tag (called metro tag or PE-VLAN) to 802.1Q tagged packets that enter the network. The purpose is to expand the VLAN space by tagging the tagged packets, thus producing a double-tagged frame. The expanded VLAN space allows the service provider to provide certain services, such as Internet access on specific VLANs for specific customers, and yet still allows the service provider to provide other types of services for their other customers on other VLANs.
Another term for this encapsulating functionality is tunneling, and another way to note this functionality is "802.1Q-in-802.1Q," or more simply "Q-in-Q."
Generally a service provider's customers require a range of VLANs to handle multiple applications. Service providers can allow their customers to use this feature to safely assign their own VLAN IDs on subinterfaces because these subinterface VLAN IDs are encapsulated within a service-provider-designated VLAN ID for a given customer. Therefore, there is no overlap of VLAN IDs among customers, nor does traffic from different customers become mixed. The double-tagged frame is terminated or assigned on a subinterface with an expanded encapsulation dot1q command that specifies the two VLAN ID tags (outer VLAN ID and inner VLAN ID) terminated on the subinterface.
When you configure Q-in-Q, you assign a tunnel port to a VLAN that you dedicate to tunneling, which then becomes a tunnel VLAN. To keep customer traffic segregated requires a separate tunnel VLAN for each customer, but that one tunnel VLAN supports all of the customer's traffic. Q-in-Q is not restricted to point-to-point tunnel configurations. Any tunnel port in a tunnel VLAN is a tunnel entry and exit point. An IEEE 802.1Q tunnel can have as many tunnel ports as needed to connect customer routers.
Q-in-Q is generally used in Metro Ethernet or Ethernet digital subscriber line access multiplexer (DSLAM) environments. Networks using Q-in-Q are commonly found in multi-tenant buildings such as a hotel where Internet services are provided individually to each tenant. Because Ethernet is inherent in Q-in-Q, customers have access to abundant bandwidth, and service providers can easily deliver services to the customer.
Q-in-Q is generally supported on whichever Cisco IOS features or protocols are supported on the subinterface. For example, if you can run PPP over Ethernet (PPPoE) on the subinterface, you can configure a double-tagged frame for PPPoE.
PPPoE
When you deploy ADSL in a network with PPP, you must support PPP-style authentication and authorization over a large installed base of legacy bridging customer premises equipment (CPE). PPPoE provides the ability to connect a network of hosts over a simple bridging access device to a remote access concentrator or aggregation concentrator. With this model, each host uses its own PPP stack, thus providing a familiar user interface. Access control, billing, and type of service can be done on a per-user, rather than a per-site, basis.
As specified in RFC 2516, PPPoE has two distinct stages, a discovery stage and a PPP session stage. When a host initiates a PPPoE session, it must first perform discovery to identify which server can meet the client's request. Then it must identify the Ethernet MAC address of the peer and establish a PPPoE session ID. Although PPP defines a peer-to-peer relationship, discovery is inherently a client-server relationship. In the discovery process, the client discovers the server (access concentrator). Based on the network topology, there may be more than one server with which the host can communicate. The discovery stage allows the host to discover all servers and select one. When the discovery phase completes successfully, both the host and the selected server have the information needed to build their point-to-point connection over Ethernet.
ISG Features Tested
Following are the features that were tested on the platforms—Cisco 7200, 7300, and 10000 series routers—used in the test environments described in this document:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Test Software and Equipment
Table 1 lists devices used in the ISG test network.
Table 2 lists the software used in the testing.
Configuration Prerequisites
This section describes prerequisites that must be in place before deploying the ISG features described in this document in the following sections:
•
Basic Configuration Requirements
Before beginning the configuration tasks, make sure that the following conditions are met:
•
•
•
•
•
Network administrators should also be familiar with the topics listed in the "Additional References" section.
Configuration Passwords
As you read through the configurations in this document, you will come across several types of passwords that will be required, such as for the Cisco IOS, for the Cisco Access Registrar (CAR) and AAA RADIUS server, for the billing server, and so on. The configurations in this document use the word "cisco" frequently as a password. You will need to provide unique passwords for each of these areas in your network and determine some secure method for identifying which passwords are associated with a particular service.
Vendor-Specific Attributes
The configurations in this document use RADIUS vendor-specific attributes. See the RADIUS document titles in the "Related Documents" section for help in configuring these attributes.
GE Deployment Models for Cisco IOS Software Release 12.2(31)SB2
Numerous configurations using various platforms and features were tested in the Cisco laboratories for Cisco IOS Software Release 12.2(31)SB2. The following network models are presented as representative of the features used most by Cisco customers:
•
•
•
Model 1: Authenticated IP Sessions over a .1Q Interface
This section is organized as follows:
•
•
Description of Model 1
Model 1 transports IP sessions over an IEEE 802.1Q interface (IPoQ in Figure 3). The session is initiated based on new DHCP traffic. TAL is used to authorize the session based on the DHCP relay agent information option (option 82) and the user MAC address.
Network subscribers can be authorized by one of two methods: either they log in at the portal using a username and password or the network can admit them transparently based on their MAC address and DHCP option 82 information. The AAA server is configured to force subscribers to log in the first time the network is accessed. The next time subscribers access the network, however, they should be transparently authorized into the network. The AAA server will force subscribers to log in when they do not connect from their usual location and may force login if they have been inactive for some interval of time.
Topology for Model 1
Figure 3 IP Sessions over .1Q Interface
Call Flow for Session Initiation
Figure 4 shows the call flows for the model 1 network. After the first login, the user will transparently be authorized for access to the network.
Figure 4 Session Initiation Call Flow for Model 1
Flow 1
•
•
•
•
Flow 2
•
Flow 3
•
Flow 4
•
Flow 5
•
Flow 6
•
Flow 7
•
Call Flow for Bandwidth Upgrade
Figure 5 depicts the logic that applies when PC users request an upgrade to the amount of bandwidth available for Internet access.
Figure 5 Bandwidth Upgrade Call Flow for Model 1
Flow 8
•
Flow 9
•
Flow 10
•
Flow 11
•
Flow 12
•
Flow 13
•
Flow 14
•
Flow 15:
•
Call Flow for VRF Transfer
Figure 6 depicts the logic that applies when the ISG activates new VRF service for the PC user.
Figure 6 VRF Transfer Call Flow for Model 1
Flow 16
•
Flow 17
•
Flow 18
•
Flow 19
•
Flow 20
•
Flow 21 and 22
•
Model 2: Authenticated IP Sessions over a Q-in-Q Interface
This section is organized as follows:
•
Description of Model 2
Model 2 transports authenticated IP sessions over a Q-in-Q interface. This model uses DHCP-initiated connections (IP sessions, Layer 2-connected). Each subscriber has a unique ID made up of an outer and inner VLAN ID. Session authentication information is based on the inner and outer VLAN tags (Q-in-Q VLANs) that are transported in the RADIUS NAS-Port attribute. User and service profiles are downloaded from the RADIUS server, and users are dynamically assigned to a VRF.
Topology for Model 2
Figure 7 shows the basic topology for network model 2.
Figure 7 IP Sessions over Q-in-Q Interface
Call Flow for a DHCP-Initiated Session
Figure 8 shows the call flows for DHCP-initiated session using dynamic VPN selection.
Figure 8 DHCP-Initiated Session Call Flow for Model 2
The call flows in Figure 8 can be summarized as follows:
Flow 1
•
•
•
•
Flow 2
•
Flow 3
•
Flow 4
•
•
•
•
Flow 5
•
Flow 6
•
Flow 7
•
Flow 8
•
•
Flow 9
•
•
Flow 10
•
•
•
Flow 11
The ISG acknowledges the service and activates and installs the service.
Flow 12
An accounting message signals the start of a new service.
Flow 13
The user deactivates the service from the portal.
Flow 14
An accounting Stop Service message is sent.
Refer to the "RFCs" section for more information about DHCP and HTTP and call flow logic.
Model 3: Authenticated PPP Sessions over a Q-in-Q Interface
This section is organized as follows:
•
•
Description of Model 3
The Model 3 network contains a BRAS or ISG that terminates PPPoE sessions on Q-in-Q subinterfaces.
PPPoE subscribers are authorized to access Internet content and services based on an inner and outer VLAN tag. Information from this tag is transported in the NAS-port attribute. The user and service profiles are downloaded from RADIUS, and users are dynamically assigned to a VRF. The downloaded services can have a prepaid feature enabled.
If the authentication fails, users are redirected to the portal, where they are given options to log in or purchase services.
Once subscribers are authorized in the ISG, they can log into the portal and activate or deactivate services. The following services are defined for the users to select in model 3:
•
•
•
•
•
•
•
•
Topology for Model 3
Figure 9 shows the network topology for model 3.
Figure 9 PPPoE Sessions over QinQ
Figure 10 and Figure 11 show call flows for authenticated PPP sessions.
Call Flow for the Prepaid Feature
Figure 10 shows call flows for the following prepaid feature processes:
•
•
•
•
•
•
•
Figure 10 Call Flow for the Prepaid Feature
The call flows seen in Figure 10 can be described as follows:
Flow 1
•
•
•
Flow 2
•
•
Flow 3
•
•
Flow 4
•
Flow 5
•
•
Flow 6
•
•
Flow 7
•
Flow 8
•
•
Flow 9
•
•
Flow 10
•
•
Flow 11
•
•
Flow 12
•
Call Flow for a Dynamic MQC/QoS Change
The call flows illustrated in Figure 11 are valid only for a PPP session. Figure 11 illustrates call flows for the following dynamic MQC/QoS change processes:
•
•
•
•
•
Figure 11 Call Flow for a Dynamic MQC/QoS Change
The call flows seen in Figure 11 can be described as follows:
Flow 1
•
Flow 2
•
Flow 3
•
•
Flow 4
•
Flow 5
•
•
Flow 6
•
Model 1 Configuration: Authenticated IP Sessions over a .1Q Interface
The following sections describe how to configure the model 1 network:
•
•
•
•
•
•
•
•
•
Prerequisites for Model 1
See the "Configuration Prerequisites" section for network configurations that must be in place before you begin the tasks described in this section. Network administrators should also be familiar with the topics listed in the "Additional References" section. See the "Configuration Passwords" section for information about configuration passwords. See the "Vendor-Specific Attributes" section for information about vendor-specific attributes. Figure 3 shows the devices that are configured.
Configuring Subscriber Access for Model 1
The following example configures an interface IP session using a DHCP initiator with class-aware capability:
interface GigabitEthernet1/0/0.400description TC406a using Local DHCP serverencapsulation dot1Q 400ip address 10.1.10.1 255.255.255.0no snmp trap link-statusservice-policy type control RULE_406aip subscriber l2-connectedinitiator dhcp class-aware!Configuring ISG to AAA Server Interfaces for Model 1
The following example shows a basic AAA configuration that includes connection to the RADIUS server:
aaa new-model!!aaa group server radius SERVER_GROUP1server 172.17.10.9 auth-port 1812 acct-port 1813!aaa authentication login default noneaaa authentication login AUTHEN_LIST1 group SERVER_GROUP1aaa authorization network default group SERVER_GROUP1aaa authorization network AUTHOR_LIST1 group SERVER_GROUP1aaa authorization subscriber-service default group SERVER_GROUP1aaa accounting delay-start allaaa accounting update periodic 5aaa accounting network default start-stop group SERVER_GROUP1aaa accounting network BH_ACCNT_LIST1 start-stop group SERVER_GROUP1!!aaa session-id common!!ip subnet-zeroradius-server attribute 44 include-in-access-req vrf defaultradius-server attribute 6 on-for-login-authradius-server attribute 8 include-in-access-reqradius-server attribute 32 include-in-access-reqradius-server attribute 32 include-in-accounting-reqradius-server attribute 55 include-in-acct-reqradius-server attribute 55 access-request includeradius-server attribute 25 access-request includeradius-server host 172.17.10.9 auth-port 1812 acct-port 1813 key aaaciscoradius-server vsa send authentication!radius-server vsa send accounting!ip radius source-interface Loopback0 vrf default!!subscriber service password servicecisco!Configuring the User Profile on the AAA Server for Model 1
Following is the user profile used in network model 1, which is configured on the AAA server:
User-Name: tc406auser1Idle-Timeout: 3000CiscoAVPair:"subscriber:accounting-list=BH_ACCNT_LIST1"ssg-account-info: "ABasic_Internet_Service"ssg-account-info: "NSERVICE_406_BOD1Mc"ssg-account-info: "NSERVICE_406_VPN_1001c"Configuring Service Profiles on the AAA Server for Model 1
This section contains examples for the following service profiles:
Note
PBHK_SERVICE
Service Name: "PBHK_SERVICE"CiscoAVPair: ip:portbundle=enableSERVICE_406_L4R
Service Name: "SERVICE_406_L4R"CiscoAVPair: ip:l4redirect=redirect list 199 to group REDIRECT_SERVER_GROUP1Basic_Internet_Service
Service Name: "Basic_Internet_Service"SERVICE INFO: QD;512000;256000SERVICE INFO: QU;256000;128000CiscoAVPair: ip:traffic-class=input access-group name ACL_IN_INTERNET_406 priority 30CiscoAVPair: ip:traffic-class=out default dropCiscoAVPair: ip:traffic-class=in default dropCiscoAVPair: subscriber:accounting-list=BH_ACCNT_LIST1CiscoAVPair: ip:traffic-class=output access-group name ACL_OUT_INTERNET_406 priority 30SERVICE_406_BOD1Mc
Service Name: "SERVICE_406_BOD1Mc"Idle-Timeout.value: 1800CiscoAVPair: subscriber:accounting-list=BH_ACCNT_LIST1SERVICE INFO: QU;512000;256000;D;1024000;512000CiscoAVPair: ip:traffic-class=input access-group name ACL_IN_BOD1M_406 priority 20CiscoAVPair: ip:traffic-class=out default dropCiscoAVPair: ip:traffic-class=output access-group name ACL_OUT_BOD1M_406 priority 20CiscoAVPair: ip:traffic-class=in default dropSERVICE_406_VPN_1001c
Service Name: "SERVICE_406_VPN_1001c"CiscoAVPair: ip:traffic-class=in default dropCiscoAVPair: ip:traffic-class=out default dropCiscoAVPair: ip:traffic-class=in access-group name ACL_IN_VPN_406_1001CiscoAVPair: ip:vrf-id=VPN_406_1001CiscoAVPair: subscriber:sg-service-type=primaryCiscoAVPair: subscriber:accounting-list=BH_ACCNT_LIST1CiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_VPN_406_1001CiscoAVPair: subscriber:classname=DHCP_CLASS_VPN_406_1001Configuring Inbound and Outbound Access Lists for Model 1
Basic access lists are configured to govern subscribers' Internet access. In the following example, the access lists are referenced in the AAA subscriber profile and govern incoming and outgoing Internet traffic. The Internet access lists should prevent subscribers from accessing the portal and other management devices, to help prevent denial-of-service attacks.
ip access-list extended ACL_IN_BOD1M_406permit ip any anyip access-list extended ACL_IN_INTERNET_406permit ip any anyip access-list extended ACL_IN_VPN_406_1001permit ip any anyip access-list extended ACL_OUT_BOD1M_406permit ip any anyip access-list extended ACL_OUT_INTERNET_406permit ip any anyip access-list extended ACL_OUT_VPN_406_1001permit ip any any!Configuring the Policy/Portal Server Interface for Model 1
The following examples show how to configure the policy/portal server interface for network model 1:
•
•
•
•
Configuring the CoA Interface in the ISG for Model 1
The following example shows how to configure the ISG with the CoA interface and define the policy and portal servers as clients:
aaa server radius dynamic-authorclient 172.17.10.9server-key cisco555Configuring the Policy/Portal Server for CoA for Model 1
The following example defines the secret keys and port (by default, the ISG uses port 1700) to be used for CoA communication between ISG and the policy/portal server:
NAS-IP-Address = 10.200.1.1Dyanmic-author Port number = 1700Shared Key = "cisco555"Configuring ISG to Support PBHK for Subscriber Access to the Portal for Model 1
When the PBHK feature is enabled, matching TCP packets from subscribers are mapped to the configured local IP address of the ISG gateway and a range of ports. The following configuration allows the policy/portal server to identify a subscriber session in the ISG to do dynamic updates using the CoA interface. It also specifies the loopback address in the ISG that will be used by the policy/portal server while communicating in CoA with ISG.
ip portbundlematch access-list 135source Loopback0!interface GigabitEthernet5/0/0ip address 10.1.50.1 255.255.255.0ip portbundle outsidenegotiation autompls ipcdp enableaccess-list 135 permit ip any host 172.17.10.9access-list 135 deny ip any any!interface Loopback 0ip address 10.200.1.1 255.255.255.0The PBHK ID is comprised of the ISG IP used for portbundle and a dynamically assigned port number by ISG.
Configuring Layer 4 Redirect for Model 1
The following commands define redirect server groups in the ISG. These groups will be used by the Layer 4 Redirect services to redirect subscriber traffic.
redirect server-group REDIRECT_SERVER_GROUP1server ip 172.17.10.9 port 8091!! L4 Redirect service access listaccess-list 199 deny ip any host 172.17.10.9access-list 199 permit tcp any any eq wwwaccess-list 199 permit tcp any any eq 8080access-list 199 permit tcp any any eq 8091!Configuring ISG Control Policies for Model 1
Control policies define the actions that the system will take in response to specified events and conditions. For example, a control policy can be configured to authenticate specific subscribers and then provide them with access to specific services.
A control policy is made of one or more control policy rules. A control policy rule is an association of a control class and one or more actions. The control class defines the conditions that must be met before the actions will be executed. There are three steps involved in defining a control policy:
Step 1
A control class map specifies the conditions that must be met for a policy to be activated, and, optionally, the event that causes the class to be evaluated. A control class map may contain many conditions, each of which will be evaluated as either true or false. Match directives can be used to specify whether all, any, or none of the individual conditions must evaluate true in order for the class to evaluate true.
Step 2
A control policy map contains one or more control policy rules. A control policy rule associates a control class map with one or more actions. Actions are numbered and executed sequentially.
Step 3
The following examples show how to configure control policies used in the model 1 network:
! This command is enabled by default. It sets the number of rules that are displayed! in the show subscriber session detail command.subscriber policy recording rules limit 64subscriber authorization enable!class-map type control match-all IP_UNAUTH_CONDmatch timer IP_UNAUTH_TIMERmatch authen-status unauthenticated!!policy-map type control RULE_406aclass type control IP_UNAUTH_COND event timed-policy-expiry1 service disconnect!class type control always event session-start10 service-policy type service name PBHK_SERVICE! TAL uses the remote-id + circuit-id + DHCP client source MAC address, which are! extracted from the DHCP DISCOVERY message20 authorize aaa list AUTHOR_LIST1 password cisco123 identifier remote-id plus circuit-id plus mac-address30 service-policy type service name SERVICE_406_L4R40 set-timer IP_UNAUTH_TIMER 5! The session is disconnected if the session stays in the unauthenticated state for more! than the time set (5 minutes) by IP_UNAUTH_TIMER!class type control always event session-restart10 service-policy type service name PBHK_SERVICE20 service-policy type service name SERVICE_406_L4R30 set-timer IP_UNAUTH_TIMER 5!class type control always event account-logon10 authenticate aaa list AUTHEN_LIST120 service-policy type service unapply name SERVICE_406_L4R!! After receiving the Account-Logoff message, the following commands allow the session to! stay active for another 10 secondsclass type control always event account-logoff10 service disconnect delay 10!Configuring the DHCP Server and DHCP Classes for Model 1
Cisco routers running Cisco IOS software include DHCP server and relay agent software. The Cisco IOS DHCP server assigns and manages IP addresses from specified address pools within the router to DHCP clients. If the Cisco IOS DHCP server cannot satisfy a DHCP request from its own database, it can forward the request to one or more secondary DHCP servers defined by the network administrator. DHCP supports three mechanisms for IP address allocation: automatic allocation of a permanent address, dynamic allocation for a limited period of time, and manual allocation where the network administrator assigns an IP address to a client and DHCP is used simply to convey the assigned address to the client.
The DHCP server and DHCP classes for Model 1 are configured as shown in the following example:
ip dhcp relay information policy keepip dhcp relay information trust-allip dhcp use vrf connectedip dhcp excluded-address 10.1.11.1ip dhcp excluded-address 10.1.10.1!ip dhcp pool TC406a_DHCP_POOL1network 10.1.10.0 255.255.255.0default-router 10.1.10.1lease 0 0 30class default!ip dhcp pool VPN_406_1001_POOL1vrf VPN_406_1001network 10.1.11.0 255.255.255.0default-router 10.1.11.1lease 0 0 30class DHCP_CLASS_VPN_406_1001!ip dhcp class default!ip dhcp class DHCP_CLASS_VPN_406_1001Configuring the Multiservice Interface for VRF Transfer for Model 1
The following commands configure the multiservice interface:
interface multiservice1ip vrf forwarding VPN_406_1001ip address 10.1.11.1 255.255.255.0no keepalive!Configuring mBGP and VPNv4 for Model 1
The following example shows a typical configuration to enable routing in the model 1 network:
ip vrf VPN_406_1001rd 406:1001route-target export 406:1001route-target import 406:1001!ip vrf forwardingrouter ospf 100router-id 10.200.1.1log-adjacency-changesnetwork 10.1.50.1 0.0.0.0 area 100network 10.1.0.0 0.0.255.255 area 100network 10.200.1.1 0.0.0.0 area 100!router bgp 100no synchronizationbgp router-id 10.200.1.1bgp log-neighbor-changesneighbor 10.200.1.9 remote-as 100neighbor 10.200.1.9 ebgp-multihop 2neighbor 10.200.1.9 update-source Loopback0no auto-summary!address-family vpnv4neighbor 10.200.1.9 activateneighbor 10.200.1.9 send-community bothexit-address-family!address-family ipv4 vrf VPN_406_1001redistribute connectedredistribute staticno auto-summaryno synchronizationexit-address-familyConfiguring the Remote PE Side for Model 1
The PE is configured to assign subscribers to a VRF and to allow subscribers to access the portal. Following is an example:
ip vrf VPN_406_1001rd 406:1001route-target export 406:1001route-target import 406:1001!!router bgp 100no synchronizationbgp router-id 10.200.1.9bgp log-neighbor-changesneighbor SP100 peer-groupneighbor SP100 remote-as 100neighbor SP100 ebgp-multihop 2neighbor SP100 update-source Loopback0neighbor 10.200.1.1 peer-group SP100no auto-summary!address-family vpnv4neighbor SP100 activateneighbor SP100 send-community extendedneighbor 10.200.1.1 peer-group SP100exit-address-family!address-family ipv4 vrf VPN_406_1001redistribute connectedredistribute staticno auto-summaryno synchronizationexit-address-family!ip classlessip route vrf VPN_406_1001 172.17.10.9 255.255.255.255 GigabitEthernet7/48 172.17.10.1Model 2 Configuration: Authenticated IP Sessions over a Q-in-Q Interface
The following sections describe how to configure the model 2 network:
•
•
•
•
•
•
•
•
•
•
Prerequisites for Model 2
See the "Configuration Prerequisites" section for network configurations that must be in place before you begin the tasks described in this section. Network administrators should also be familiar with the topics listed in the "Additional References" section. See the "Configuration Passwords" section for information about configuration passwords. See the "Vendor-Specific Attributes" section for information about vendor-specific attributes.
Figure 7 shows the devices that are configured.
Configuring Subscriber Access for Model 2
The following example configures an interface for IP subscriber sessions using DHCP with class-aware as the session initiator:
interface GigabitEthernet1/0/0.111encapsulation dot1Q 4020 second-dot1q 4043ip address 172.16.1.1 255.255.255.0no snmp trap link-statusservice-policy type control RULE-401a-1ip subscriber l2-connectedinitiator dhcp class-aware!Configuring ISG to AAA Server Interfaces for Model 2
The following example shows a basic AAA configuration that includes connection to the RADIUS server:
aaa new-model!!aaa group server radius BH_SERVER_GROUP1server 172.16.5.45 auth-port 1812 acct-port 1813!aaa authentication login default noneaaa authentication login BH_WEB_LOGON group BH_SERVER_GROUP1aaa authorization network default group BH_SERVER_GROUP1aaa authorization subscriber-service default local group BH_SERVER_GROUP1aaa accounting update periodic 5aaa accounting network default start-stop group BH_SERVER_GROUP1aaa accounting network BH_ACCNT_LIST start-stop group BH_SERVER_GROUP1!aaa session-id common!The following example shows how to configure the RADIUS server and enable a unique session ID for accounting by configuring the radius-server attribute 44 include-in-access-req global configuration command on the ISG:
!radius-server attribute 44 include-in-access-req radius-server attribute 8 include-in-access-req radius-server attribute 32 include-in-access-req radius-server attribute 55 access-request include radius-server attribute 25 access-request include radius-server attribute 4 172.16.4.4 radius-server host 172.16.5.45 auth-port 1812 acct-port 1813 key cisco radius-server vsa send accounting radius-server vsa send authentication !ip radius source-interface Loopback0 vrf default!Configuring the User Profile on the AAA Server for for Model 2
Following are the commands configured on the AAA server to create the user profile for network model 2:
Subscriber Identities:
ISG authorized the subscriber using nas-port-id:nas-port:172.16.4.4:1/0/0/4043.4020Where:
•
•
•
•
Complete RADIUS User Profile:
In the following example, the ID is auto-generated by the ISG. The subscriber login identity is defined as `tc401a1'.
nas-port:172.16.4.4:1/0/0/4043.4020 & tc401a1(second identity)User-Name.value: tc401a1CiscoAVPair: subscriber:accounting-list=BH_ACCNT_LISTHas the following selectable services:SERVICE_401_UPGRADED_INTERNETSERVICE_401_PERIODIC_L4RHas the following auto-started services:VPN_401_1001SERVICE_401_INTERNETConfiguring Service Profiles for Model 2
This section contains the following service profile examples:
•
L4_REDIRECT_SERVICE
CiscoAVPair: ip:l4redirect=redirect list 199 to group BROADHOPPBHK_SERVICE
CiscoAVPair: ip:portbundle=enableSERVICE_401_INTERNET
CiscoAVPair: ip:traffic-class=in access-group name ACL_IN_INTERNET_401 priority 10CiscoAVPair: ip:traffic-class=out default dropCiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_INTERNET_401 priority 10SERVICE INFO: QD;1024000;1024000CiscoAVPair: subscriber:accounting-list=BH_ACCNT_LISTSERVICE INFO: QU;512000;512000CiscoAVPair: ip:traffic-class=in default dropSERVICE_401_PERIODIC_L4R
CiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_PL4R_401 priority 5CiscoAVPair: subscriber:accounting-list=BH_ACCNT_LISTCiscoAVPair: ip:l4redirect=redirect list 199 to group PERIODIC_L4R duration 60 frequency 120CiscoAVPair: ip:traffic-class=out default dropCiscoAVPair: ip:traffic-class=in default dropSERVICE INFO: QD;1024000;1024000CiscoAVPair: ip:traffic-class=in access-group name ACL_IN_PL4R_401 priority 5SERVICE INFO: QU;512000;512000SERVICE_401_UPGRADED_INTERNET
Idle-Timeout.value: 90CiscoAVPair: ip:traffic-class=in default dropCiscoAVPair: subscriber:accounting-list=BH_ACCNT_LISTCiscoAVPair: ip:traffic-class=in access-group name ACL_IN_UPGRADED_INTERNET_401 priority 10CiscoAVPair: ip:traffic-class=out default dropCiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_UPGRADED_INTERNET_401 priority 10Session-Timeout.value: 300SERVICE INFO: QU;1024000;1024000SERVICE INFO: QD;2048000;2048000VPN_401_1001
CiscoAVPair: subscriber:classname=VPN_401_1001 CiscoAVPair: subscriber:sg-service-type=primary CiscoAVPair: ip:vrf-id=VPN_401_1001CoA_Session_Update
Session-Timeout.value: 600 Idle-Timeout.value: 120Configuring Inbound and Outbound Access Lists for Model 2
Basic access lists are configured to govern subscribers' Internet access. In the following example, the access lists are referenced in the AAA subscriber profile and govern incoming and outgoing Internet traffic. The Internet access lists should prevent subscribers from accessing the portal and other management devices, to help prevent denial-of-service attacks.
!ip access-list extended ACL_IN_INTERNET_401deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_IN_PL4R_401deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_IN_UPGRADED_INTERNET_401deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_OUT_INTERNET_401deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_OUT_PL4R_401deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_OUT_UPGRADED_INTERNET_401deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyConfiguring the Policy/Portal Server Interface for Model 2
The following examples show how to configure the policy/portal server interface for network model 2:
•
•
•
Configuring the CoA Interface in the ISG for Model 2
The following example shows how to configure ISG with CoA interface and define the policy and portal servers as clients. It also specifies the loopback address in the ISG that will be used by the policy/portal server while communicating in CoA with ISG.
aaa server radius dynamic-authorclient 172.16.5.45server-key cisco!interface Loopback0ip address 172.16.4.4 255.255.255.255Configuring the Policy/Portal Server for CoA for Model 2
The following example defines the secret keys and port (by default, the ISG uses port 1700) to be used for CoA communication between ISG and the policy/portal servers. Configure the following information on the policy/portal server:
NAS-IP-Address = 172.16.4.4Dyanmic-author Port number = 1700Shared Key = "cisco"Configuring ISG to Support PortBundle Host Key for Subscriber Access to the Portal for Model 2
When the Port-Bundle Host Key (PBHK) feature is enabled, matching TCP packets from subscribers are mapped to the configured local IP address of the ISG gateway and a range of ports. The mapping allows the policy/portal server to identify a subscriber session in the ISG to do dynamic updates using the CoA interface. The PBHK ID consists of the ISG IP used for the port bundle and a dynamically assigned port number by ISG. The key ip portbundle command in this configuration is highlighted in bold text for purpose of example.
ip portbundlematch access-list 198source Loopback0!interface GigabitEthernet5/0/0description P to c10k link 1 port GE 6/1mtu 1508ip address 172.16.3.4 255.255.255.0ip portbundle outsidenegotiation autompls label protocol ldpmpls ipcdp enable!! The PBHK feature is applied only to traffic destined to the portal IP 172.16.5.45!access-list 198 permit ip any host 172.16.5.45access-list 198 deny ip any anyConfiguring Layer 4 Redirect for Model 2
The following commands define redirect server groups in the ISG. These groups will be used by the Layer 4 Redirect services to redirect subscriber traffic.
redirect server-group PORTALserver ip 172.16.5.45 port 8091!redirect server-group PERIODIC_L4Rserver ip 172.16.5.57 port 80!! access-List 199 is used by L4_REDIRECT_SERVICE and SERVICE 401 Periodic L4 Redirect.!access-list 199 deny tcp any host 172.16.5.45 eq wwwaccess-list 199 deny tcp any host 172.16.5.45 eq 8080access-list 199 deny tcp any host 172.16.5.57 eq wwwaccess-list 199 permit tcp any any eq wwwConfiguring ISG Control Policies for Model 2
Control policies define the actions that the system will take in response to specified events and conditions. For example, a control policy can be configured to authenticate specific subscribers and then provide them with access to specific services.
A control policy is made of one or more control policy rules. A control policy rule is an association of a control class and one or more actions. The control class defines the conditions that must be met before the actions will be executed. There are three steps involved in defining a control policy:
Step 1
A control class map specifies the conditions that must be met for a policy to be activated, and, optionally, the event that causes the class to be evaluated. A control class map may contain many conditions, each of which will be evaluated as either true or false. Match directives can be used to specify whether all, any, or none of the individual conditions must evaluate true in order for the class to evaluate true.
Step 2
A control policy map contains one or more control policy rules. A control policy rule associates a control class map with one or more actions. Actions are numbered and executed sequentially.
Step 3
The following example shows how to configure subscriber rule RULE-401a-1 for IP TAL sessions using NAS-port as the identifier, and then how to apply common services that are configured remotely on the AAA server, such as PBHK_SERVICE, INTERNET, and so on. The L4_REDIRECT_SERVICE service is applied for unauthenticated users in the subscriber rule.
! This command is enabled by default. It sets the number of rules that are displayed! in the show subscriber session detail command.subscriber policy recording rules limit 64subscriber authorization enable!class-map type control match-all IP_UNAUTH_CONDmatch timer IP_UNAUTH_TIMERmatch authen-status unauthenticated!class-map type control match-all SERVICE_401_PERIODIC_L4_REDIRECTmatch service-name SERVICE_401_PERIODIC_L4R!class-map type control match-all SERVICE_401_UPGRADED_INTERNETmatch service-name SERVICE-401_UPGRADED_INTERNET!!policy-map type control RULE-401a-1class type control IP_UNAUTH_COND event timed-policy-expiry1 service disconnect!class type control SERVICE_401_UPGRADED_INTERNET event service-stop1 service-policy type service unapply identifier service-name2 service-policy type service name SERVICE-401-INTERNET!class type control SERVICE_401_UPGRADED_INTERNET event service-start1 service-policy type service unapply name SERVICE-401-INTERNET2 service-policy type service unapply name SERVICE_401_PERIODIC_L4R3 service-policy type service identifier service-name!class type control always event session-start1 service-policy type service name PBHK_SERVICE2 authorize aaa password lab123 identifier nas-port3 service-policy type service name L4_REDIRECT_SERVICE4 set-timer IP_UNAUTH_TIMER 5! The session is disconnected if it stays in unauthenticated state for more than the! time set by IP_UNAUTH_TIMER (5 minutes)!class type control always event account-logon1 authenticate aaa list BH_WEB_LOGON2 service-policy type service unapply name L4_REDIRECT_SERVICE!class type control always event account-logoff1 service disconnect delay 5!class type control always event session-restart1 service-policy type service name PBHK_SERVICE3 service-policy type service name L4_REDIRECT_SERVICE4 set-timer IP_UNAUTH_TIMER 5Configuring the DHCP Server and DHCP Classes for Model 2
Automatic DHCP address allocation is typically based on an IP address, whether it be the gateway or the incoming interface IP address. In some networks, it is necessary to use additional information to further determine which IP addresses to allocate. Using the relay agent information option (option 82) permits the Cisco IOS relay agent to include additional information about itself when forwarding client-originated DHCP packets to a DHCP server.
The ip dhcp relay information option command supports the relay agent functionality. The relay agent will automatically add the VPN information to the relay agent information option and forward them to the DHCP server. The DHCP server can use this information to assign IP addresses, perform access control, and set security policies (or other parameter-assignment policies) for each subscriber of a service provider network.
Cisco routers running Cisco IOS software include DHCP server and relay agent software. The Cisco IOS DHCP server assigns and manages IP addresses from specified address pools within the router to DHCP clients. If the Cisco IOS DHCP server cannot satisfy a DHCP request from its own database, it can forward the request to one or more secondary DHCP servers defined by the network administrator. DHCP supports three mechanisms for IP address allocation: automatic allocation of a permanent address, dynamic allocation for a limited period of time, and manual allocation, whereby the network administrator assigns an IP address to a client, and DHCP is used simply to convey the assigned address to the client.
The model 2 deployment uses DHCP dynamic allocation for a limited period of time, as shown in the following configuration example:
!no ip domain lookupip dhcp relay information option vpnip dhcp relay information optionip dhcp relay information trust-allip dhcp use vrf connectedip dhcp binding cleanup interval 10!ip dhcp pool VPN_401_1001vrf VPN_401_1001relay source 172.16.6.0 255.255.255.0relay destination global 172.16.5.56class VPN_401_1001!ip dhcp pool ISP1network 172.16.1.0 255.255.255.0default-router 172.16.1.1lease 0 0 3class default!!ip dhcp class VPN_401_1001!ip dhcp class default!Configuring the Multiservice Interface for VRF Termination for Model 2
The following commands configure the multiservice interface:
interface multiservice1ip vrf forwarding VPN_401_1001ip address 172.16.6.1 255.255.255.0no keepaliveConfiguring mBGP and VPNv4 for Model 2
The following example shows a typical configuration to enable VRF forwarding and IP routing in the model 2 network:
ip vrf VPN_401_1001rd 401:1001route-target export 401:1001route-target import 401:1001!router ospf 100router-id 172.16.4.4log-adjacency-changesredistribute connectednetwork 172.16.1.0 0.0.0.255 area 10network 172.16.4.4 0.0.0.0 area 10network 172.16.3.0 0.0.255.255 area 10!router bgp 100no synchronizationbgp router-id 172.16.4.4bgp log-neighbor-changesneighbor 172.16.4.9 remote-as 100neighbor 172.16.4.9 update-source Loopback0no auto-summary!address-family vpnv4neighbor 172.16.4.9 activateneighbor 172.16.4.9 send-community bothexit-address-family!address-family ipv4 vrf VPN_401_1001redistribute connectedredistribute staticno auto-summaryno synchronizationexit-address-family!Configuring the Remote PE Side for Model 2
The PE is configured to assign subscribers to a VRF and to allow subscribers to access the portal. Following is an example:
ip vrf VPN_401_1001rd 401:1001route-target export 401:1001route-target import 401:1001!router bgp 100no synchronizationbgp router-id 172.16.4.9bgp log-neighbor-changesneighbor 172.16.4.4 remote-as 100neighbor 172.16.4.4 update-source Loopback0no auto-summary!address-family vpnv4neighbor 172.16.4.4 activateneighbor 172.16.4.4 send-community bothexit-address-family!address-family ipv4 vrf VPN_401_1001redistribute connectedredistribute staticno auto-summaryno synchronizationexit-address-family!Model 3 Configuration: Authenticated PPP Sessions over a Q-in-Q Interface
The following sections describe how to configure the model 3 network:
•
•
•
•
•
•
•
•
•
•
•
•
Prerequisites for Model 3
See the "Configuration Prerequisites" section for network configurations that must be in place before you begin the tasks described in this section. Network administrators should also be familiar with the topics listed in the "Additional References" section. See the "Configuration Passwords" section for information about configuration passwords. See the "Vendor-Specific Attributes" section for information about vendor-specific attributes. Figure 9 shows the devices that are configured.
Configuring Subscriber Access for Model 3
The following example configures a PPPoE session:
bba-group pppoe PPPOE-GROUP4031virtual-template 201!interface GigabitEthernet1/0/0.4037encapsulation dot1Q 4020 second-dot1q 4037pppoe enable group PPPOE-GROUP4031no snmp trap link-status!interface Virtual-Template201no ip addresspeer default ip address pool PPPoE_POOL_403_1no keepaliveservice-policy type control RULE-403a-1ip local pool PPPoE_POOL_403_1 172.16.2.2 172.16.2.254Configuring ISG to AAA Server Interfaces for Model 3
The following example shows a basic AAA configuration that includes connection to the RADIUS server and has SESM installed and configured with the AAA information:
!aaa new-model!!! AAA Server Configuration!aaa group server radius BH-SERVERserver 172.16.5.45 auth-port 1812 acct-port 1813!! Prepaid Billing and Accounting Server!aaa group server radius BILLING-SERVERserver 172.16.13.2 auth-port 1812 acct-port 1813!aaa authentication login default noneaaa authentication login BH_WEB_LOGON group BH-SERVERaaa authentication ppp default group BH-SERVERaaa authentication ppp BH-PPP group BH-SERVERaaa authorization network default group BH-SERVERaaa authorization network PREPAID_AUTHOR_LIST group BILLING-SERVERaaa authorization subscriber-service default local group BH-SERVERaaa accounting update periodic 15aaa accounting network default start-stop group BH-SERVERaaa accounting network BH_ACCNT_LIST start-stop group BH-SERVERaaa accounting network PREPAID_ACCOUNT_LIST start-stop group BILLING-SERVERThe following example shows how to configure the RADIUS server and enable a unique session ID for accounting by configuring the radius-server attribute 44 include-in-access-req global configuration command on the ISG:
radius-server attribute 44 include-in-access-req vrf defaultradius-server attribute 8 include-in-access-reqradius-server attribute 55 access-request includeradius-server attribute 25 access-request includeradius-server attribute nas-port format dradius-server attribute 4 172.16.4.13radius-server host 172.16.13.2 auth-port 1812 acct-port 1813 key ciscoradius-server host 172.16.5.45 auth-port 1812 acct-port 1813 key ciscoradius-server vsa send accountingradius-server vsa send authenticationConfiguring the User Profile for Model 3
SUBSCRIBER IDENTITIES:ISG authorizes the subscriber using nas-port-id :nas-port:172.16.4.13:1/0/0/4020.4037where
•
•
•
•
The ID is auto-generated by the ISG. It requires the radius-server attribute nas-port format d command to be configured in the ISG.
The subscriber login or secondary identity is defined as `tc403a1'.
User Radius Profile
ip:ip-unnumbered=loopback201User-Name: nas-port:172.16.4.13:1/0/0/4020.4037subscriber:accounting-list=BH_ACCNT_LISTip:outacl=ACL_OUT_PARENT_403Idle-Timeout: 600ip:inacl=ACL_IN_PARENT_403ip:vrf-id=VPN_403_1001Configuring Service Profiles for Model 3
This section contains examples for the following service profiles:
•
•
•
L4_REDIRECT_SERVICE
CiscoAVPair: ip:l4redirect=redirect list 199 to group BROADHOPPBHK_SERVICE
CiscoAVPair: ip:portbundle=enableSERVICE_403_SPECIFIC_PORT_L4R
CiscoAVPair: ip:traffic-class=out default drop CiscoAVPair: ip:traffic-class=in default drop CiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_SPECIFIC_PORT_L4R_403 priority 7 CiscoAVPair: ip:l4redirect=redirect list 197 to group SPECIFIC_PORT_L4R CiscoAVPair: ip:traffic-class=in access-group name ACL_IN_SPECIFIC_PORT_L4R_403 priority 7SERVICE_403_L4R_TC
CiscoAVPair: ip:traffic-class=in access-group name ACL_IN_L4R_TC_403 priority 5CiscoAVPair: ip:l4redirect=redirect to group BROADHOPCiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_L4R_TC_403 priority 5CoA_403_QOS_UPDATE
CiscoAVPair: ip:sub-qos-policy-out=QOS_POLICY_OUT_512_PARENT_403 CiscoAVPair: ip:sub-qos-policy-in=QOS_POLICY_IN_512_PARENT_403CoA_VRF_QOS_UPDATE
CiscoAVPair: ip:ip-unnumbered=loopback201 CiscoAVPair: ip:vrf-id=VPN_403_3002 CiscoAVPair: ip:addr-pool=PPPoE_POOL_403_2 CiscoAVPair: ip:inacl=ACL_IN_PARENT_403 CiscoAVPair: ip:inacl=ACL_IN_PARENT_403 CiscoAVPair: ip:sub-qos-policy-out=QOS_POLICY_OUT_512_PARENT_403 CiscoAVPair: ip:sub-qos-policy-in=QOS_POLICY_IN_512_PARENT_403SERVICE_403_INTERNET
CiscoAVPair: ip:traffic-class=in access-group name ACL_IN_INTERNET_403 priority 10 CiscoAVPair: ip:traffic-class=in default drop SERVICE INFO: QD;1024000;1024000 SERVICE INFO: QU;512000;512000 CiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_INTERNET_403 priority 10 CiscoAVPair: prepaid-config=PREPAID_RSIM CiscoAVPair: subscriber:accounting-list=BH_ACCNT_LIST CiscoAVPair: ip:traffic-class=out default dropSERVICE_403_Upgraded_Internet
CiscoAVPair: ip:traffic-class=in default drop SERVICE INFO: QD;2048000;2048000 CiscoAVPair: ip:traffic-class=in access-group name ACL_IN_UPGRADED_INTERNET_403 priority 6 CiscoAVPair: ip:traffic-class=out default drop CiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_UPGRADED_INTERNET_403 priority 6 SERVICE INFO: QU;1024000;1024000 CiscoAVPair: subscriber:accounting-list=BH_ACCNT_LISTSERVICE_403_PL4R: Periodic Layer 4 Redirect Service
CiscoAVPair: ip:traffic-class=in access-group name ACL_IN_PL4R_403 priority 5 CiscoAVPair: ip:traffic-class=out default drop CiscoAVPair: subscriber:accounting-list=BH_ACCNT_LIST CiscoAVPair: ip:l4redirect=redirect list 199 to group PERIODIC_L4R duration 60 frequency 120 CiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_PL4R_403 priority 5 CiscoAVPair: ip:traffic-class=in default dropCiscoAVPair: ip:traffic-class=in access-group name ACL_IN_L4R_TC_403 priority 5CiscoAVPair: ip:l4redirect=redirect to group BROADHOPCiscoAVPair: ip:traffic-class=out access-group name ACL_OUT_L4R_TC_403 priority 5Configuring Inbound and Outbound Access Lists for Model 3
Basic access lists are configured to govern subscribers' Internet access. In the following example, the access lists are referenced in the AAA subscriber, and service profiles govern incoming and outgoing Internet traffic.
ip access-list extended ACL_IN_INTERNET_403deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_IN_L4R_TC_403deny ip any host 172.16.5.45permit tcp any any eq wwwpermit tcp any any eq 8080deny ip any anyip access-list extended ACL_IN_OPEN_TC_403permit ip any host 172.16.5.45permit ip any host 172.16.5.49permit ip any host 172.16.5.57deny ip any anyip access-list extended ACL_IN_PARENT_403permit ip any anyip access-list extended ACL_IN_PL4R_403deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_IN_SPECIFIC_PORT_L4R_403deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit tcp any host 172.16.5.45 eq 443permit tcp any host 172.16.5.45 eq wwwpermit tcp any host 172.16.5.45 eq 8080permit tcp any host 172.16.5.49 eq 443permit tcp any host 172.16.5.49 eq wwwpermit tcp any host 172.16.5.49 eq 8080permit tcp any host 172.16.5.57 eq wwwpermit ip any host 172.16.101.1permit tcp any any eq 8080deny ip any anyip access-list extended ACL_IN_UPGRADED_INTERNET_403deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any host 5.5.201.1deny ip any anyip access-list extended ACL_OUT_INTERNET_403deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_OUT_L4R_TC_403permit ip any anyip access-list extended ACL_OUT_OPEN_TC_403permit ip host 172.16.5.45 anypermit ip host 172.16.5.49 anypermit ip host 172.16.5.57 anydeny ip any anyip access-list extended ACL_OUT_PARENT_403permit ip any anyip access-list extended ACL_OUT_PL4R_403deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_OUT_SPECIFIC_PORT_L4R_403deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyip access-list extended ACL_OUT_UPGRADED_INTERNET_403deny ip 10.0.0.0 0.255.255.255 anydeny ip 192.168.0.0 0.0.255.255 anypermit ip any anyConfiguring the Policy/Portal Server Interface for Model 3
This section provides the following configuration examples:
•
•
•
Configuring the CoA Interface in the ISG in Model 3
The following example defines the secret keys to be used for CoA communication between ISG and the policy/portal servers. The loopback address is in the ISG, which will be used by the policy/portal server while communicating in CoA with ISG.
aaa server radius dynamic-authorclient 172.16.5.45server-key ciscointerface Loopback0ip address 172.16.4.13 255.255.255.255Configuring the Policy/Portal Server for CoA in Model 3
The following commands configure the policy/portal servers as clients:
NAS-IP-Address = 172.16.4.13Dynamic-author Port number = 1700Shared Key = "cisco"Configuring ISG to Support Port-Bundle Host Key for Subscriber Access to the Portal in Model 3
When the Port-Bundle Host Key (PBHK) feature is enabled, matching TCP packets from subscribers are mapped to the configured local IP address of the ISG gateway and a range of ports. The mapping allows the policy/portal server to identify a subscriber session in ISG to do dynamic updates using the CoA interface. The PBHK ID consists of the ISG IP address used for the portbundle and a dynamically assigned port number by the ISG.
See "Configuring ISG Port-Bundle Host Key" in the Cisco IOS Intelligent Services Gateway Configuration Guide for more information.
ip portbundlematch access-list 198source Loopback0interface GigabitEthernet5/0/0mtu 1508ip address 172.16.9.13 255.255.255.0ip portbundle outsidenegotiation autompls label protocol ldpmpls ipcdp enable!! PBHK feature applied only to traffic destined to the portal IP 172.16.5.45!access-list 198 permit ip any host 172.16.5.45access-list 198 deny ip any anyConfiguring the Prepaid Server for Model 3
Enable the prepaid feature in the ISG by defining the following:
•
•
•
For detailed information about ISG prepaid billing feature, see "Configuring ISG Support for Prepaid Billing" in the Cisco IOS Intelligent Services Gateway Configuration Guide.
Following are the commands to enable the prepaid server feature for model 3:
subscriber feature prepaid PREPAID_RSIMthreshold time 120 secondsthreshold volume 20000 bytesinterim-interval 15 minutesmethod-list author PREPAID_AUTHOR_LISTmethod-list accounting PREPAID_ACCOUNT_LISTpassword ciscoConfiguring Layer 4 Redirect for Model 3
Define redirect server groups in ISG. These groups will be used by the Layer 4 Redirect services to redirect subscriber traffic.
redirect server-group BROADHOPserver ip 172.16.5.45 port 8091!redirect server-group PERIODIC_L4Rserver ip 172.16.5.57 port 80!redirect server-group SPECIFIC_PORT_L4Rserver ip 172.16.5.57 port 80!! ACL 197 is used by SERVICE_403_SPECIFIC_PORT_L4Raccess-list 197 deny tcp any host 172.16.5.45 eq wwwaccess-list 197 deny tcp any host 172.16.5.45 eq 8080access-list 197 permit tcp any any eq 8080!! ACL 199 is used by SERVICE_403_PL4Raccess-list 199 deny tcp any host 172.16.5.45 eq wwwaccess-list 199 deny tcp any host 172.16.5.45 eq 8080access-list 199 permit tcp any any eq wwwConfiguring ISG Control Policies for Model 3
Control policies define the actions that the system will take in response to specified events and conditions. For example, a control policy can be configured to authenticate specific subscribers and then provide them with access to specific services.
A control policy is made of one or more control policy rules. A control policy rule is an association of a control class and one or more actions. The control class defines the conditions that must be met before the actions will be executed. There are three steps involved in defining a control policy:
Step 1
A control class map specifies the conditions that must be met for a policy to be activated, and, optionally, the event that causes the class to be evaluated. A control class map may contain many conditions, each of which will be evaluated as either true or false. Match directives can be used to specify whether all, any, or none of the individual conditions must evaluate true in order for the class to evaluate true.
Step 2
A control policy map contains one or more control policy rules. A control policy rule associates a control class map with one or more actions. Actions are numbered and executed sequentially.
Step 3
The following example shows how to configure subscriber rule RULE-403a-1 for IP TAL sessions using NAS-port as the identifier, and then apply common services that are configured remotely on the AAA server, such as PBHK_SERVICE, INTERNET, and so on. The L4 Redirect service is applied for unauthenticated users in the subscriber rule.
! This command is enabled by default. It sets the number of rules that are displayed! in the show subscriber session detail command.subscriber policy recording rules limit 64subscriber authorization enable!class-map type control match-all SERVICE_403_SPECIFIC_PORT_L4Rmatch service-name SERVICE_403_SPECIFIC_PORT_L4R!class-map type control match-all SERVICE_403_INTERNETmatch service-name SERVICE_403_INTERNET!class-map type control match-all SERVICE_403_PL4Rmatch service-name SERVICE_403_PL4R!class-map type control match-all IP-UNAUTH-CONDmatch timer IP-UNAUTH-TIMERmatch authen-status unauthenticated!!policy-map type control RULE-403a-1class type control IP-UNAUTH-COND event timed-policy-expiry1 service disconnect!class type control SERVICE_403_PL4R event service-start1 service-policy type service unapply name SERVICE_403_INTERNET2 service-policy type service unapply name SERVICE_403_L4R_TC3 service-policy type service unapply name SERVICE_403_OPEN_GARDEN4 service-policy type service identifier service-name!class type control SERVICE_403_PL4R event service-stop1 service-policy type service unapply identifier service-name2 service-policy type service name SERVICE_403_INTERNET3 service-policy type service name SERVICE_403_OPEN_GARDEN!class type control SERVICE_403_SPECIFIC_PORT_L4R event service-start1 service-policy type service unapply name SERVICE_403_INTERNET2 service-policy type service unapply name SERVICE_403_L4R_TC3 service-policy type service unapply name SERVICE_403_OPEN_GARDEN4 service-policy type service identifier service-name!class type control SERVICE_403_SPECIFIC_PORT_L4R event service-stop1 service-policy type service unapply identifier service-name2 service-policy type service name SERVICE_403_INTERNET3 service-policy type service name SERVICE_403_OPEN_GARDEN!class type control always event session-start1 service-policy type service name PBHK_SERVICE2 service-policy type service name SERVICE_403_OPEN_GARDEN3 authorize aaa password lab123 identifier nas-port4 service-policy type service name L4_REDIRECT_SERVICE6 set-timer IP_UNAUTH_TIMER 5!class type control always event account-logon1 authenticate aaa list BH_WEB_LOGON2 service-policy type service unapply name L4_REDIRECT_SERVICE!class type control always event credit-exhausted1 service-policy type service name SERVICE_403_L4R_TC!class type control always event quota-depleted1 set-param drop-traffic FALSE!! After receiving the Account-Logoff request, allow the session to stay active for! another 10 seconds for graceful log-off.class type control always event account-logoff1 service-policy disconnect delay 10Configuring QoS Policies for Model 3
Here is how to configure the QoS policies:
class-map match-any QOS_CLASS_VOICE_403match ip dscp efpolicy-map QOS_POLICY_IN_VOICE_403class QOS_CLASS_VOICE_403police cir 128000exceed-action droppolicy-map QOS_POLICY_IN_512_PARENT_403class class-defaultpolice cir 512000exceed-action dropservice-policy QOS_POLICY_IN_VOICE_403policy-map QOS_POLICY_IN_256_PARENT_403class class-defaultpolice cir 256000exceed-action dropservice-policy QOS_POLICY_IN_VOICE_403policy-map QOS_POLICY_OUT_VOICE_403class QOS_CLASS_VOICE_403priority 128policy-map QOS_POLICY_OUT_512_PARENT_403class class-defaultshape average 512000service-policy QOS_POLICY_OUT_VOICE_403policy-map QOS_POLICY_OUT_256_PARENT_403class class-defaultshape average 256000service-policy QOS_POLICY_OUT_VOICE_403Configuring mBGP and VPNv4 for Model 3
The following example shows a typical configuration to enable routing in the network:
ip vrf VPN_403_1001rd 403:1001route-target export 403:1001route-target import 403:1001!ip vrf VPN_403_1002rd 403:1002route-target export 403:1002route-target import 403:1002!router ospf 100router-id 172.16.4.13log-adjacency-changesredistribute static metric-type 1 subnetsnetwork 172.16.3.0 0.0.0.255 area 102network 172.16.4.13 0.0.0.0 area 102network 172.16.9.0 0.0.255.255 area 102!router bgp 100no synchronizationbgp router-id 172.16.4.13bgp log-neighbor-changesneighbor 172.16.4.9 remote-as 100neighbor 172.16.4.9 update-source Loopback0no auto-summary!address-family vpnv4neighbor 172.16.4.9 activateneighbor 172.16.4.9 send-community bothexit-address-family!address-family ipv4 vrf VPN_403_1002redistribute connectedno auto-summaryno synchronizationexit-address-family!address-family ipv4 vrf VPN_403_1001redistribute connectedno auto-summaryno synchronizationexit-address-familyConfiguring the Remote PE Side for Model 3
The PE is configured to assign subscribers to a VRF and to allow subscribers to access the portal.
ip vrf VPN73-1rd 10:1route-target export 10:1route-target import 10:1!ip vrf VPN73-10rd 10:10route-target export 10:10route-target import 10:10!router bgp 100no synchronizationbgp router-id 172.16.4.9bgp log-neighbor-changesneighbor 172.16.4.13 remote-as 100neighbor 172.16.4.13 update-source Loopback0no auto-summary!address-family vpnv4neighbor 172.16.4.13 activateneighbor 172.16.4.13 send-community bothexit-address-family!address-family ipv4 vrf VPN_403_1002redistribute connectedredistribute staticno auto-summaryno synchronizationexit-address-family!address-family ipv4 vrf VPN_403_1001redistribute connectedredistribute staticno auto-summaryno synchronizationexit-address-family!Configuration Verification Commands
The following sections list the show and debug commands that are helpful for verifying and debugging the ISG network configurations:
•
Show Commands
Use the following show commands to verify subscriber configurations:
•
•
Use the following command to verify service configurations:
•
Use the following command to display address bindings on the DHCP server:
•
The show running-configuration command is also useful for verifying configurations.
Debug Commands
The following debug commands are commonly used for debugging problems for networks using the IP sessions used in the Model 1 and 2 networks:
•
•
•
•
•
•
•
1 Used mostly for DHCP sessions; also useful to verify for VRF transfer.The following debug commands are commonly used for debugging problems for networks using the PPP sessions used in the model 3 network:
•
•
•
•
•
•
Verification Command Examples
This section provides the following examples:
•
•
•
•
ISG Configuration Information Verification
Use the show running-configuration EXEC command with the interface number to check interface configuration.
GE-10008-BRAS1# show running interface gigE 1/0/0.111Building configuration...Current configuration : 244 bytes!interface GigabitEthernet1/0/0.111encapsulation dot1Q 4020 second-dot1q 4043ip address 172.16.1.1 255.255.255.0no snmp trap link-statusservice-policy type control RULE-401a-1ip subscriber l2-connectedinitiator dhcp class-awareendBasic ISG Operation Verification
Use the show subscriber session command to show a summary of the number of active sessions and their unique identifier, interface, state, service, NAS-port identifier, and up time.
GE-10008-BRAS1# show subscriber sessionCurrent Subscriber Information: Total sessions 1Uniq ID Interface State Service Identifier Up-time10 IP authen Local Term nas-port:1/0/0/4020. 00:00:4511 Traffic-Cl unauthen Ltm Internal 00:00:45Subscriber Service Verification
Use the show ip subscriber command with the VRF identifier and detailed keyword to verify that a subscriber belongs to a VRF as expected.
GE-10008-BRAS1# show ip subscriber vrf VPN_401_1001 detailedIP subscriber: 000e.0c4a.f197, type connected, status updisplay uid: 10, aaa uid: 21session initiator: dhcp discoveryaccess address: 172.16.6.2service address: vrf VPN_401_1001, 172.16.6.2conditional debug flag: 0x0control plane state: connected, start time: 00:00:57data plane state: connected, start time: 00:00:52arp entry: [vrf VPN_401_1001] 172.16.6.2, GigabitEthernet1/0/0.111midchain adj: 172.16.6.2 on multiservice1forwarding statistics:packets total: received 14, sent 2bytes total: received 1520, sent 656packets dropped: 1, bytes dropped: 98ISG Prepaid Service Verification
Use the show subscriber session uid command to verify the prepaid service status.
GE-10008-BRAS2# show subscriber session uid 60Unique Session ID: 60Identifier: nas-port:172.16.4.13:1/0/0/4020.4037SIP subscriber access type(s): Traffic-ClassCurrent SIP options: NoneSession Up-time: 00:01:29, Last Changed: 00:00:58Policy information:Authentication status: unauthenPrepaid context: PREPAID_RSIMthreshold time 100 secondsthreshold volume 500 bytesmethod-list author PREPAID_AUTHOR_LISTmethod-list accounting defaultpassword ciscoInterim 3 minutesState PREPAID_FEATURE_RUNNINGFlow idle at last re-author ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 120 (seconds)Feature: PolicingUpstream Params:Average rate = 512000, Normal burst = 512000, Excess burst = 0Config level = ServiceFeature: Prepaid Volume MonitorThreshold:500 - Quota:1000Usage(since last update):0 - Total:864Current states: StartSession outbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 120 (seconds)Feature: PolicingDnstream Params:Average rate = 1024000, Normal burst = 1024000, Excess burst = 0Config level = ServiceFeature: Prepaid Volume MonitorThreshold:500 - Quota:1000Usage(since last update):0 - Total:864Current states: StartConfiguration sources associated with this session:Service: SERVICE_403_INTERNET, Active Time = 00:01:30DHCP Server Address Bindings
The following example displays address bindings from all pools not associated with a VRF:
GE-10008-BRAS1# show ip dhcp bindingBindings from all pools not associated with VRF:IP address Client-ID/ Lease expiration TypeHardware address/User nameBindings from VRF pool VPN_401_1001:IP address Client-ID/ Lease expiration TypeHardware address/User name172.16.6.2 0100.0e0c.4af1.97 Aug 26 2006 11:10 AM AutomaticBindings from VRF pool VPN_401_1002:IP address Client-ID/ Lease expiration TypeHardware address/User nameBindings from VRF pool VPN_401_1003:IP address Client-ID/ Lease expiration TypeHardware address/User nameAdditional References
The following sections provide references related to configuring the ISG in an GE-based broadband network:
Related Documents
Broadband and DSL configuration
Cisco IOS Broadband and DSL Configuration Guide, Release 12.4
CAR configuration procedure
Cisco CNS Access Registrar Installation and Configuration Guide, 3.5
CNR configuration procedure
Cisco CNS Network Registrar User's Guide, 6.2, at http://www.cisco.com/en/US/partner/products/sw/netmgtsw/ps1982/tsd_products_support_series_home.html
ISG software configuration
Layer 2 Tunnel Protocol (L2TP) virtual private dialup network (VPDN) for dialin and dialout configuration
Cisco IOS VPDN Configuration Guide, Release 12.4
RADIUS attributes
RADIUS Attribute-Value Pairs and Dictionary Management
RADIUS Vendor-Proprietary Attributes
"RADIUS Service and User Profile Attributes" in the Cisco SSG-to-ISG DSL Broadband Migration Guide
Virtual template interface configuration
"Configuring Virtual Template Interfaces" in the Cisco IOS Dial Technologies Configuration Guide, Release 12.4
Standards
RFCs
Technical Assistance
Glossary
AAA—authentication, authorization, and accounting
AAL5/SNAP—ATM adaptation Layer 5/Subnetwork Access Protocol
ACL—access control list or access list
ADSL2—asymmetric dual-latency modem
ATU-R—ADSL Transmission Unit—remote
BRAS—Broadband Remote Access Server
CAR—Cisco Access Registrar
CE—customer edge
CNR—Cisco Network Registrar
CoA—Change of Authorization
CPE—customer premises equipment
DHCP—Dynamic Host Configuration Protocol
DNS—Domain Name System
DSL—digital subscriber line
DSLAM—Digital Subscriber Line Access Multiplexer
ISG—Intelligent Services Gateway
ISP—Internet service provider
IPCP—IP Control Protocol
L2TP—Layer 2 Tunnel Protocol
MAC—Media Access Control
MQC—Modular QoS CLI
MPLS—Multiprotocol Label Switching
PBHK—Port-Bundle Host Key
PE—provider edge
POP—point of presence
PPPoE—PPP over Ethernet
PVC—permanent virtual circuit
QoS—quality of service
SESM—Subscriber Edge Services Manager
SSG—Service Selection Gateway
TAL—Transparent Autologin
VoIP—Voice over IP
VPDN—virtual private dialup network
VLAN—virtual LAN
VPN—Virtual Private Network
VRF—VPN routing and forwarding instance
VSA—vendor-specific attribute
Note
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0910R)
Copyright © 2006-2009 Cisco Systems, Inc. All rights reserved.
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)