|
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:
Command | Purpose | |
---|---|---|
Step 1 | interface atm 0/0/0 [.subinterface-number
{multipoint | point-to-point}]
| Specifies the ATM interface and optional subinterface. |
Step 2 | pvc [name] vpi/vci
| Configures a new ATM PVC by assigning a name (optional) and VPI/VCI numbers. |
Step 3 | encapsulation aal5snap1
| Configures AAL5 with SNAP encapsulation. |
Step 4 | protocol protocol [protocol-address | inarp] [[no]
broadcast]
| Maps a protocol address to the PVC. |
1AAL5 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:
Router(config)# interface atm 0/0/0.10 multipoint
Router(config-if)# no ip address
Router(config-if)# bridge-group 1
Router(config-if)# pvc 1 32
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol bridge broadcast
Router(config-if-atm-vc)# exit
Router(config-if)# pvc 1 33
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol bridge broadcast
Router(config-if-atm-vc)# exit
Router(config-if)# exit
Router(config)# bridge 1 protocol ieee
Router(config)# bridge 1 subscriber-policy 5
Router(config)# subscriber-policy 5 no ipx permit
The following example shows how to configure RFC1483 bridging on a point-to-point interface. Arrows indicate integrated routing and bridging steps:
Router(config)# interface atm 0/0/0.20 point-to-point
Router(config-if)# no ip address
Router(config-if)# bridge-group 2
Router(config-if)# pvc 2 32
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol bridge broadcast
Router(config-if-atm-vc)# exit
Router(config-if)# exit
Router(config)# interface atm 0/0/0.21 point-to-point
Router(config-if)# no ip address
Router(config-if)# bridge-group 2
Router(config-if)# pvc 2 33
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol bridge broadcast
Router(config-if-atm-vc)# exit
Router(config-if)# exit
Router(config)# bridge irb
Router(config)# interface bvi 2
Router(config-if)# ip address 172.26.13.49
Router(config-if)# exit
Router(config)# bridge 2 protocol ieee
Router(config)# bridge 2 route ip
Router(config)# bridge 2 bridge ipx
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:
Router(config)# interface atm 0/0/0.40 multipoint
Router(config-if)# ip address 172.25.210.97 255.255.0.0
Router(config-if)# pvc 4 32
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol ip inarp broadcast
Router(config-if-atm-vc)# exit
Router(config-if)# pvc 4 33
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol ip 10.3.45.156 broadcast
Router(config-if-atm-vc)# exit
Router(config-if)# exit
Router(config)# interface atm 0/0/0.41 point-to-point
Router(config-if)# ip unnumbered fastethernet 0/0/0
Router(config-if)# pvc 4 34
Router(config-if-atm-vc)# encapsulation aal5snap
Router(config-if-atm-vc)# protocol ip inarp broadcast
Router(config-if-atm-vc)# exit
Router(config-if)# exit
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.
Field | Description |
---|---|
Port Type | Port type. The value 0x01 indicates RBE (1 byte). |
Version | Option 82 version. The value 0x01 specifies the RBE version of Option 82 (1 byte). |
Reserved | Reserved (2 bytes). |
NAS IP Address | IP address of the NSP NME interface. |
RBE-enabled virtual circuit on which the DHCP request has come in. See Figure 6-3 for the format of this field (4 bytes). |
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:
Command | Purpose |
---|---|
Router(config)#ip dhcp relay information
option
| Enables the system to insert the DHCP relay agent information option in forwarded BOOT REQUEST messages to a Cisco IOS DHCP server. |
To verify that the DHCP Option 82 Support for Routed Bridge Encapsulation feature is configured correctly, use the following command in privileged EXEC mode:
Command | Purpose |
---|---|
Router#more system:running-config
| Displays the running configuration. |
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:
ip dhcp relay information option
!
interface Loopback0
ip address 10.40.40.1 255.255.255.0
!
interface Loopback1
ip address 10.40.50.1 255.255.255.0
!
interface ATM0/0/0
no ip address
no atm ilmi-keepalive
hold-queue 1000 in
!
interface ATM0/0/0.3 point-to-point
ip unnumbered Loopback0
ip helper-address 10.60.60.2
atm route-bridged ip
pvc 1/50
encapsulation aal5snap
!
!
interface FastEthernet0/0/0
ip address 10.60.60.1 255.255.255.0
no keepalive
full-duplex
!
router rip
network 10.0.0.0
!
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.
Agent Remote ID Suboption Field | Value |
---|---|
Port Type | 0x01 |
Version | 0x01 |
Reserved | undefined |
NAS IP Address | 0x9c132339 (hexadecimal value of 172.19.35.57) |
NAS Port
| egress port information1
|
1Because 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:
ip dhcp relay information option
!
interface Loopback0
ip address 10.40.40.1 255.255.255.0
!
interface Loopback1
ip address 10.40.50.1 255.255.255.0
!
interface ATM0/0/0
no ip address
no atm ilmi-keepalive
hold-queue 1000 in
!
interface ATM0/0/0.4 point-to-point
ip unnumbered Loopback0
ip helper-address 10.60.60.2
atm route-bridged ip
pvc 1/51
encapsulation aal5snap
!
!
interface FastEthernet0/0/0
ip address 10.60.60.1 255.255.255.0
no keepalive
full-duplex
!
router rip
network 10.0.0.0
!
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.
Agent Remote ID Suboption Field | Value |
---|---|
Port Type | 0x01 |
Version | 0x01 |
Reserved | undefined |
NAS IP Address | 0x9c132339 (hexadecimal value of 172.19.35.57) |
NAS Port
| ingress port information1
|
1Because 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:
Command | Purpose |
---|---|
Switch(config)# interface BVI1
| Selects the combined NME interface. |
Switch(config-if)# ip address address subnet
| Configures a static IP and subnetwork address. |
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:
Command | Purpose |
---|---|
Switch(config)# interface ethernet 0/0/0
| Selects the NME interface. |
Switch(config-if)# ip address address subnet
or Switch(config-if)# ip address negotiated
| Configures a static IP and subnetwork address. Allows the interface to obtain an IP address, subnet mask, router address, and static routes from a DHCP server. |
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).
Switch# show interface bvi1
BVI1 is up, line protocol is up
Hardware is BVI, address is 0010.7ba9.c783 (bia 0000.0000.0000)
Internet address is 10.1.1.33/16
MTU 1500 bytes, BW 10000 Kbit, DLY 5000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
ARP type:ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Queueing strategy:fifo
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1540 packets input, 302775 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
545 packets output, 35694 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Switch#
To enable RADIUS VC logging on the Cisco 6400 NRP, enter the following command in global configuration mode:
Command | Purpose |
---|---|
Router(config)# radius-server attribute nas-port format d
| Selects the ATM VC extended format for the NAS port field. |
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:
Wed Jun 16 13:57:31 1999
NAS-IP-Address = 192.168.100.192
NAS-Port = 268566560
NAS-Port-Type = Virtual
User-Name = "cisco"
Acct-Status-Type = Start
Service-Type = Framed
Acct-Session-Id = "1/0/0/2.32_00000009"
Framed-Protocol = PPP
Framed-IP-Address = 172.16.7.254
Acct-Delay-Time = 0
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:
Acct-Session-Id = "slot/subslot/port/VPI.VCI_acct-session-id"
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.
Global Configuration Commands | Selected IP Address | ||
---|---|---|---|
ip radius source-interface <int x> | radius-server attribute nas-port format d | radius-server attribute 4 nrp | |
Enabled |
|
| NRP IP address 1 |
| Enabled |
| NSP IP address |
Enabled | Enabled |
| NSP IP address |
Enabled | Enabled | Enabled | NRP IP address 1 |
| Enabled | Enabled | NRP best-select IP address 2 |
1NRP IP address of <int x> 2Automatic choice, 1st choice is loopback, etc. |
Command | Purpose |
---|---|
Router> show atm ingress [all | local-vc vpi/vci] [detailed]
|
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:
CPE1 Password = "cisco"
Service-Type = Framed,
Framed-Protocol = PPP,
Framed-IP-Address=10.0.0.1
Framed-IP-netmask=255.255.255.248
Framed-MTU = 1500
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:
Wed Jun 16 13:57:31 1999
NAS-IP-Address = 10.168.100.192
NAS-Port = 268566560
NAS-Port-Type = Virtual
User-Name = "cisco"
Acct-Status-Type = Start
Service-Type = Framed
Acct-Session-Id = "1/0/0/2.32_00000009"
Framed-Protocol = PPP
Framed-IP-Address = 10.16.7.254
Framed-IP-netmask = 255.255.255.248
Acct-Delay-Time = 0
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:
Command | Purpose | |
---|---|---|
Step 1 | Router(config)#interface virtual template number
| Creates or specifies the virtual template interface. Enters interface configuration mode. |
Step 2 | Router(config-if)#ppp ipcp mask subnet-mask
| Assigns the subnet mask to pass to a requesting peer (CPE).1 |
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.
!
interface ATM0/0/0.30 multipoint
pvc 1/43
encapsulation aal5ciscoppp Virtual-Template 2
!
!
interface Virtual-Template2
ip unnumbered FastEthernet0/0/0
no peer default ip address
ppp authentication pap chap
ppp ipcp mask 255.255.255.224
!
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:
Command | Purpose | |
---|---|---|
Step 1 | CPE(config)# interface type number
| Selects the interface and interface type. Enters interface configuration mode. |
Step 2 | CPE(config-if)# ppp ipcp mask request
| Specifies to request the subnet mask from the peer. |
In the following example, the CPE is configured to initiate IPCP subnet mask negotiation:
!
interface Dialer 0
ppp ipcp mask request
!
To configure the CPE to support and initiate IPCP subnet mask negotiation, enter the following commands in enable mode:
Command | Purpose |
---|---|
cbos# set dhcp client enabled
| Enables the DHCP client. |
cbos# set dhcp server enabled
| Enables the DHCP server functionality. |
cbos# set dhcp server learn enabled
| Forces the server to use the IPCP negotiated address as the base IP address of its pool. |
cbos# set ppp wan0-0 subnet 0.0.0.0
| Enables the CPE to negotiate a subnet mask through IPCP during PPP negotiation. |
cbos# set ppp wan0-0 ipcp 0.0.0.0
| Enables the CPE to negotiate an IP address through IPCP during PPP negotiation. |
In the following example, the CPE is configured to initiate IPCP subnet mask negotiation:
set dhcp client enabled
set dhcp server enabled
set dhcp server learn enabled
set nat disabled
set ppp wan0-0 login aladdin
set ppp wan0-0 password simsim
set ppp wan0-0 subnet 0.0.0.0
set ppp wan0-0 ipcp 0.0.0.0
write
set interface wan0 retrain
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.
cbos# show dhcp server pool 0
DHCP Server is currently disabled
First pool will not learn IP address from IPCP
Pool 0 currently enabled Size 5
IP Address: 10.1.1.9 Netmask: 255.255.255.248
DNS Server: 0.0.0.0 Secondary DNS: 0.0.0.0
WINS Server:0.0.0.0 Secondary WINS: 0.0.0.0
Gateway : 10.1.1.8 IRC Server: 0.0.0.0
NNTP Server:0.0.0.0 Web Server: 0.0.0.0
SMTP Server:0.0.0.0 POP3 Server:0.0.0.0
Lease: 1080 seconds
cbos#
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:
Command | Purpose |
---|---|
Router(config)#ip local pool pool-name start-IP | Configures a group of local IP address pools. Optionally, this command names the group and specifies a cache size. |
This example shows the configuration of two pool groups and includes pools in the base system group.
ip local pool p1_g1 10.1.1.1 10.1.1.50 group grp1
ip local pool p2_g1 10.1.1.100 10.1.1.110 group grp1
ip local pool p1_g2 10.1.1.1 10.1.1.40 group grp2
ip local pool lp1 10.1.1.1 10.1.1.10
ip local pool p3_g1 10.1.2.1 10.1.2.30 group grp1
ip local pool p2_g2 10.1.1.50 10.1.1.70 group grp2
ip local pool lp2 10.1.2.1 10.1.2.10
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:
Command | Purpose |
---|---|
Router#show ip local pool [[group group-name] pool-name]
| Displays local IP address pools. |
The following example displays all pools:
router# show ip local pool
Pool Begin End Free In use
** pool <p1> is in group <g1>
p1 10.1.1.1 10.1.1.10 10 0
10.1.1.21 10.1.1.30 10 0
** pool <p2> is in group <g2>
p2 10.1.1.1 10.1.1.10 10 0
lcl1 20.2.2.1 20.2.2.10 10 0
20.2.2.21 20.2.2.30 10 0
20.2.2.41 20.2.2.50 10 0
** pool <mypool> is in group <mygroup>
mypool 172.18.184.223 172.18.184.224 2 0
172.18.184.218 172.18.184.222 5 0
** pool <ccc> is in group <grp-c>
ccc 172.18.184.218 172.18.184.220 3 0
** pool <bbb> is in group <grp-b>
bbb 172.18.184.218 172.18.184.220 3 0
** pool <ddd> is in group <grp-d>
ddd 172.18.184.218 172.18.184.220 3 0
** pool <pp1> is in group <grp-pp>
pp1 172.18.184.218 172.18.184.220 2 1
router#
The following example displays the pools in the group named "mygroup":
router# show ip local pool group mygroup
Pool Begin End Free In use
** pool <mypool> is in group <mygroup>
mypool 172.18.184.223 172.18.184.224 2 0
172.18.184.218 172.18.184.222 5 0
router#
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.
ATM PVC traps are now:
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.
The extended traps include:
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:
Command | Purpose |
---|---|
Router(config)# snmp-server enable traps atm pvc extension | Enables the sending of extended ATM PVC traps. The keywords are as follows:
|
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:
Command | Purpose | |
---|---|---|
Step 3 | Router(config)# interface atm
slot/0[.subinterface-number or Router(config)# interface atm
slot/port-adapter/0[.subinterface-number or Router(config)# interface atm
number[.subinterface-number | Specifies the ATM interface using the appropriate form of the interface atm command.1 |
Step 4 | Router(config-if)# pvc [name] vpi/vci
| Enables the PVC. |
Step 5 | Router(config-if-atm-vc)#
oam-pvc manage
| Enables end-to-end OAM management for an ATM PVC. |
1To 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:
! Configure SNMP support and an IP routing protocol on your router:
Router(config)# snmp-server community public ro
Router(config)# snmp-server host 172.16.61.90 public
Router(config)# ip routing
Router(config)# router igrp 109
Router(config-router)# network 172.16.0.0
!
! Enable extended ATM PVC trap support and OAM management:
Router(config)# snmp-server enable traps atm pvc extension down
Router(config)# snmp-server enable traps atm pvc extension up
Router(config)# snmp-server enable traps atm pvc extension oam failure loopback
Router(config)# interface atm 1/0.1
Router(config-if)# pvc 0/1
Router(config-if-atm-vc)# oam-pvc manage
To monitor ATM PVC trap performance, use the following commands in EXEC mode:
Command | Purpose |
---|---|
Router#debug atm errors
| Displays ATM errors. |
Router#debug atm oam
| Displays information about ATM OAM events. |
Router#debug snmp packets
| Displays information about every SNMP packet sent or received by the router. |
Posted: Sun Nov 24 14:05:40 PST 2002
Copyright 1989-2000©Cisco Systems Inc.