|
|
This chapter describes the following features:
The following common routing and bridging protocols are detailed in the examples in this section:
For more information about routing and bridging, refer to the Cisco IOS Network Protocols Configuration Guide, Part 1 and the Bridging and IBM Networking Configuration Guide.
The Cisco 6400 NRP also offers routed bridging, which encapsulates bridged traffic in RFC 1483 routed packets. ATM routed bridging takes advantage of the characteristics of a stub LAN topology commonly used for digital subscriber line (DSL) access. For more information, see the "Configuring Broadband Access: PPP and Routed Bridge Encapsulation" chapter of the Cisco IOS Wide-Area Networking Configuration Guide.
To configure an interface or subinterface for routing or bridging, perform the following tasks starting in global configuration mode:
|
| 1 AAL5 with SNAP encapsulation is defined by default for all PVCs. This command must be used to override a different encapsulation type at the interface or subinterface level. |
The following example shows how to configure RFC 1483 bridging on a multipoint interface. Arrows indicate subscriber bridging steps:
The following example shows how to configure RFC1483 bridging on a point-to-point interface. Arrows indicate integrated routing and bridging steps:
The following example shows how to configure RFC 1483 IP routing. When configuring IP on a PVC, you must either enable inverse ARP (InARP) or enter a static map:
The DHCP relay agent information option (option 82) enables a Dynamic Host Configuration Protocol (DHCP) relay agent to include information about itself when forwarding client-originated DHCP packets to a DHCP server. The DHCP server can use this information to implement IP address or other parameter-assignment policies.
The DHCP Option 82 Support for Routed Bridge Encapsulation feature provides support for the DHCP relay agent information option when ATM routed bridge encapsulation (RBE) is used. Figure 6-1 shows a typical network topology in which ATM RBE and DHCP are used. The aggregation router that is using ATM RBE is also serving as the DHCP relay agent.
This feature communicates information to the DHCP server by using a suboption of the DHCP relay agent information option called agent remote ID. The information that is sent in the agent remote ID includes an IP address identifying the relay agent and information about the ATM interface and the PVC over which the DHCP request came in. The DHCP server can use this information to make IP address assignments and security policy decisions.
 |
Note For the Cisco 6400 as the DHCP relay agent, the IP address used in the agent remote ID is always the network management Ethernet (NME) interface of the NSP. |
Figure 6-2 shows the format of the agent remote ID suboption.
Table 6-1 describes the agent remote ID suboption fields displayed in Figure 6-2.
Table 6-1 Agent Remote ID Suboption Field Descriptions
|
Figure 6-3 shows the format of the network access server (NAS) port field in the agent remote ID suboption.
|
Note For soft PVCs, the NAS port field contains the egress VPI/VCI values. Otherwise, the ingress VPI/VCI values are used. |
Figure 6-4 shows the format of the interface field. If there is no module, the value of the module bit is 0.
|
Note For soft PVCs, the interface field uses the egress slot/subslot/port information. |
Service providers are increasingly using ATM routed bridge encapsulation to configure digital subscriber line (DSL) access. The DHCP Option 82 Support for Routed Bridge Encapsulation feature enables those service providers to use DHCP to assign IP addresses and DHCP option 82 to implement security and IP address assignment policies.
To configure DHCP option 82 support for RBE, use the following command in global configuration mode:
|
To verify that the DHCP Option 82 Support for Routed Bridge Encapsulation feature is configured correctly, use the following command in privileged EXEC mode:
In the following example, DHCP option 82 support is enabled on a DHCP relay agent that uses a soft PVC to connect to the DSLAM:
In this configuration example, the value (in hexadecimal) of the agent remote ID suboption would be 010100009c13233940010032. Table 6-2 shows the value of each field within the agent remote ID suboption.
Table 6-2 Agent Remote ID Suboption Field Descriptions—Soft PVC
|
| 1 Because a soft PVC connects the DHCP relay agent to the DSLAM, the NAS port field uses the egress port information. |
In the following example, DHCP option 82 support is enabled on a DHCP relay agent that uses a PVC to connect to the DSLAM:
In this configuration example, the value (in hexadecimal) of the agent remote ID suboption would be 010100009c13233970010035. Table 6-3 shows the value of each field within the agent remote ID suboption.
Table 6-3 Agent Remote ID Suboption Field Descriptions—PVC
|
| 1 Because a PVC connects the DHCP relay agent to the DSLAM, the NAS port field uses the ingress port information. |
RADIUS virtual circuit (VC) logging allows the Cisco 6400 to accurately record the virtual path interface (VPI) and virtual circuit interface (VCI) of an incoming subscriber session.
|
Note For soft PVCs, the Cisco 6400 returns the egress slot/subslot/port and VPI/VCI information. |
With RADIUS VC logging enabled, the RADIUS network access server (NAS) port field is extended and modified to carry VPI/VCI information. This information is logged in the RADIUS accounting record that was created at session startup.
To display the VPI/VCI information that can be used by the RADIUS VC Logging feature, use the show atm ingress command in EXEC mode.
RADIUS VC Logging feature configuration consists of these tasks:
The NAS-IP-Address field in the RADIUS accounting packet contains the IP address of the Network Management Ethernet (NME) port on the NSP, even if the NME is shutdown.
On an NSP that is preloaded with the Cisco IOS Release 12.0(5)DB or later software image, the combined NME interface is included in the default configuration. If your NRP does not use a DHCP server to obtain an IP address, you must configure a static IP address.
|
Note You must configure the NME IP address before configuring PVCs on the NRP. Otherwise, the NAS-IP-Address field in the RADIUS accounting packet will contain an incorrect IP address. |
To configure a static combined NME IP address, enter the following commands beginning in global configuration mode:
Instead of the combined NME interface, you can choose to use the Ethernet port as a separate NME interface. To configure the NME IP address, enter the following commands beginning in global configuration mode:
|
To verify the NME IP address, enter the show interface bvi1 or show interface e0/0/0 EXEC command on the NSP. Check the Internet address statement (indicated with an arrow).
To enable RADIUS VC logging on the Cisco 6400 NRP, enter the following command in global configuration mode:
To verify RADIUS VC Logging on the RADIUS server, examine a RADIUS accounting packet. If RADIUS VC logging is enabled on the Cisco 6400, the RADIUS accounting packet will appear similar to the following example:
The NAS-Port line shows that RADIUS VC logging is enabled. If this line does not appear in the display, then RADIUS VC logging is not enabled on the Cisco 6400.
The Acct-Session-Id line should also identify the incoming NSP interface and VPI/VCI information, in this format:
|
Note For soft PVCs, the Cisco 6400 returns the egress slot/subslot/port and VPI/VCI information in the Acct-Session-Id line. |
|
Note The NAS-IP-Address line in the RADIUS accounting packet contains the IP address of the NME port on the NSP, even if the NME is shutdown. If the NME on the NSP does not have an IP address, this NAS-IP-Address field will contain "0.0.0.0." |
To select an IP address to be used as the source IP address for all outgoing RADIUS packets, enter the following commands in global configuration mode:
The ip radius source-interface command specifies an interface to use for outgoing RADIUS packets. That interface must have an IP address configured in order for that IP address to be used as the source address for all outgoing RADIUS packets. The radius-server attribute 4 nrp command is used in combination with the commands in Table 6-4 to configure an IP address for that interface.
Table 6-4 RADIUS Global Configuration Commands and Selected IP Addresses
|
|||||||||||||||||||||||||||
|
1 NRP IP address of <int x> 2 Automatic choice, 1st choice is loopback, etc. |
IPCP subnet mask support allows customer premises equipment (CPE) to connect to the Cisco 6400 node route processor (NRP) and obtain IP addresses and subnet mask ranges that the CPE can use to populate the Dynamic Host Configuration Protocol (DHCP) server database.
The Cisco 6400 brings up PPP sessions with the CPE and authenticates each CPE as a separate user. An extension of the normal IPCP negotiations enables the CPE to obtain an IP subnet mask associated with the returned IP address. The Cisco 6400 adds a static route for the IP address with the subnet mask specified.
If the subnet mask is specified by the Framed-IP-netmask attribute in the RADIUS user profile, the Cisco 6400 passes the mask and IP address to the CPE during IPCP negotiation. If the Framed-IP-netmask is not specified in the RADIUS user profile, the Cisco 6400 passes the subnet mask specified with the ppp ipcp mask command in the NRP configuration. If the subnet mask is not available from either the NRP configuration or the RADIUS user profile, the NRP rejects IPCP subnet mask negotiation from the CPE.
|
Note The subnet mask in the RADIUS user profile overrides the mask configured on the NRP. |
The CPE uses the subnet mask to calculate an IP address pool from which IP addresses are assigned to PCs using the access link. Some CPE is hard-coded to request the subnet mask from the peer. If, however, the CPE uses Cisco IOS or CBOS, you must configure the CPE to support and initiate IPCP subnet mask negotiation.
|
Note Make sure you check and follow the documentation for your CPE software release. This section provides typical configuration guidelines for enabling CPE to support subnet mask negotiation. |
IPCP subnet mask support configuration consists of the following tasks:
To configure the subnet mask in the RADIUS user profile, use the Framed-IP-netmask RADIUS IETF attribute.
In the following example, the RADIUS user profile contains the netmask 255.255.255.248:
To verify the RADIUS user profile, refer to the user documentation for your RADIUS server.
You can also examine a RADIUS accounting packet and verify that the Framed-IP-netmask attribute is included in the packet:
You can configure a subnet mask on the NRP to send to the requesting peer, in case the RADIUS user profile does not include the Framed-IP-netmask attribute. On the NRP, the subnet mask is typically configured on a virtual template. Virtual templates are used to apply properties to PPP sessions.
To configure a subnet mask on the Cisco 6400 NRP, enter the following commands, beginning in global configuration mode:
|
| 1 The subnet mask configured with the ppp ipcp mask command is passed to the requesting CPE only if the RADIUS user profile does not contain a subnet mask in the form of the Framed-IP-netmask attribute. If a subnet mask is not available from either the NRP configuration or the RADIUS user profile, the request is rejected. |
In the following example, the PPP sessions in PVC 1/43 are configured to support IPCP subnet negotiation. If the RADIUS user profile does not contain the Framed-IP-netmask attribute, the NRP returns 255.255.255.224 to the requesting CPE.
To verify that you successfully configured the subnet mask on the NRP, enter the more system:running-config EXEC command to display the current running configuration. Check that the ppp ipcp mask subnet-mask interface configuration command is applied to the appropriate virtual template.
To configure the CPE to support and initiate IPCP subnet mask negotiation, complete the following steps, beginning in global configuration mode:
|
In the following example, the CPE is configured to initiate IPCP subnet mask negotiation:
To configure the CPE to support and initiate IPCP subnet mask negotiation, enter the following commands in enable mode:
|
In the following example, the CPE is configured to initiate IPCP subnet mask negotiation:
To verify that your CPE is hard-coded to request the subnet mask from the peer, refer to the user documentation for your CPE.
To verify that you successfully configured IPCP subnet mask support, enter the more system:running-config EXEC command to display the current running configuration. Check that the ppp ipcp mask request interface configuration command is applied to the appropriate interface.
To verify that you successfully configured IPCP subnet mask support, enter the show dhcp server pool number enable command. After negotiation, this command displays the IP address, subnet mask, pool start IP address and the pool size.
To troubleshoot IPCP subnet mask support on the Cisco 6400 NRP, enter the following debug commands:
IPCP IP pool processing implements all IP addresses as belonging to a single IP address space, and a given IP address should not be assigned multiple times. IP developments, such as VPDN and NAT implement the concept of multiple IP address spaces where it can be meaningful to reuse IP addresses, although such usage must ensure that these duplicate address are not placed in the same IP address space. This release introduces the concept of an IP address group to support multiple IP address spaces and still allow the verification of nonoverlapping IP address pools within a pool group. Pool names must be unique within the router. The pool name carries an implicit group identifier because that pool name can only be associated with one group. Pools without an explicit group name are considered members of the base system group and are processed in the same manner as the original IP pool implementation.
Existing configurations are not affected by the new pool feature. The "group" concept is an extension of the existing ip local pool command. Processing of pools that are not specified as a member of a group is unchanged from the existing implementation.
This feature gives greater flexibility in assigning IP addresses dynamically. It allows you to configure overlapping IP address pool groups to create different address spaces and concurrently use the same IP addresses in different address spaces.
The software checks for duplicate addresses on a per-group basis. This means that you can configure pools in multiple groups that could have possible duplicate addresses. This feature should only be used in cases where Overlapping IP address pools make sense, such as MPLS VPN environments where multiple IP address spaces are supported.
To configure a local pool group, enter the following command in global configuration mode:
|
This example shows the configuration of two pool groups and includes pools in the base system group.
The example specifies pool group "grp1" consisting of pools "p1_g1", "p2_g1" and "p3_g1"; pool group "grp2" consisting of pools "p1_g2", "p2_g2"; and pools "lp1" and "lp2" which are members of the base system group. Note the overlap addresses: IP address 1.1.1.1 is in all of them ("grp1" group, "grp2" group and the base system group). Also note that there is no overlap within any group (including the base system group, which is unnamed).
The example shows pool names that provide an easy way to associate a pool name with a group (when the pool name stands alone). While this may be an operational convenience, there is no required relationship between the names used to define a pool and the name of the group.
To verify that the new pool groups exist, enter the following command in privileged EXEC mode:
The following example displays all pools:
The following example displays the pools in the group named "mygroup":
The ATM SNMP Trap and OAM Enhancements feature introduces the following enhancements to the Simple Network Management Protocol (SNMP) notifications for ATM permanent virtual circuits (PVCs) and to operation, administration, and maintenance (OAM) functionality.
The ATM SNMP Trap and OAM enhancements are described in the following sections:
Before the introduction of the ATM SNMP Trap and OAM enhancements, the only SNMP notifications for ATM PVCs were the ATM PVC DOWN traps, which were generated when a PVC failed or left the UP operational state. The ATM SNMP Trap and OAM enhancements introduce ATM PVC UP traps, which are generated when a PVC changes from the DOWN to UP state.
The ATM SNMP Trap and OAM enhancements also introduce the ATM PVC OAM failure trap. OAM loopback is a mechanism that detects whether a connection is UP or DOWN by sending OAM end-to-end loopback command/response cells. An OAM loopback failure indicates that the PVC has lost connectivity. The ATM PVC OAM failure trap is generated when OAM loopback for a PVC fails and is sent at the end of the notification interval.
When OAM loopback for a PVC fails, the PVC is included in the atmStatusChangePVclRangeTable or atmCurrentStatusChangePVclTable and in the ATM PVC OAM failure trap.
Before the introduction of this feature, if OAM loopback failed, the PVC would be placed in the DOWN state. When the ATM PVC OAM failure trap is enabled, the PVC remains UP when OAM loopback fails so that the flow of data is still possible.
|
Note ATM PVC traps are generated at the end of the notification interval. It is possible to generate all three types of ATM PVC traps (the ATM PVC DOWN trap, ATM PVC UP trap, and ATM PVC OAM failure trap) at the end of the same notification interval. |
The ATM SNMP Trap and OAM enhancements introduce extended ATM PVC traps.
|
Note You cannot use extended ATM PVC traps at the same time as the legacy ATM PVC trap. You must disable the legacy ATM PVC trap by using the no snmp-server enable traps atm pvc command before configuring extended ATM PVC traps. |
The ATM SNMP Trap and OAM enhancements:
|
Note You cannot use extended ATM PVC traps at the same time as the legacy ATM PVC trap. You must disable the legacy ATM PVC trap by using the no snmp-server enable traps atm pvc command before configuring extended ATM PVC traps. |
ATM PVC UP traps are not generated for newly created PVCs. They are only generated for PVCs that go from the DOWN to the UP state.
Before you enable ATM PVC trap support, you must configure SNMP support and an IP routing protocol on your router. For more information about configuring SNMP support, refer to the chapter "Configuring SNMP Support" in the Cisco IOS Configuration Fundamentals Configuration Guide. For information about configuring IP routing protocols, refer to the section "IP Routing Protocols" in the Cisco IOS IP Configuration Guide.
To receive PVC failure notification and access to PVC status tables on your router, you must compile the Cisco extended ATM PVC trap MIB called CISCO-IETF-ATM2-PVCTRAP-MIB-EXTN.my in your NMS application. You can find this MIB on the Web at Cisco's MIB website:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
See the following sections for configuration tasks for the ATM SNMP Trap and OAM enhancements. Each task in the list is identified as either optional or required.
To configure extended ATM PVC trap support, use the following command in global configuration mode:
When you configure PVC trap support, you must also enable OAM management on the PVC. To enable OAM management, use the following commands beginning in global configuration mode:
|
| 1 To determine the correct form of the interface atm command, refer to your ATM network module, port adapter, or router documentation. |
To verify the configuration of ATM PVC traps, use the show running-config command. To view the status of ATM VCs, use the show atm vc command.
The following example shows all three extended ATM PVC traps enabled on a router. If PVC 0/1 leaves the UP or DOWN state, or has an OAM loopback failure, host 172.16.61.90 receives the SNMP notifications:
To monitor ATM PVC trap performance, use the following commands in EXEC mode:
Posted: Thu Sep 11 09:54:48 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
