|
|
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. See the "ATM Routed Bridge Encapsulation" section for routed bridging configuration tasks.
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 | 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] | 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 ATM routed bridge encapsulation feature on the Cisco 6400 node route processor (NRP) is used to route IP over bridged RFC 1483 Ethernet traffic from a stub-bridged LAN.
Bridged IP packets received on an ATM interface configured in route-bridged mode are routed through the IP header. Such interfaces take advantage of the characteristics of a stub LAN topology commonly used for digital subscriber line (DSL) access and offer increased performance and flexibility over integrated routing and bridging (IRB).
ATM routed bridge encapsulation reduces the security risk associated with normal bridging or IRB by reducing the size of the non-secured network. By using a single virtual circuit (VC) allocated to a subnet (which could be as small as a single IP address), ATM routed bridge encapsulation limits the "trust environment" to a single customer premises using IP addresses in the subnet.
ATM routed bridge encapsulation does not support MAC-layer access lists. Only IP access lists are supported.
Perform the following tasks to configure ATM routed bridge encapsulation. The first task is required; the remaining tasks are optional.
Perform the following tasks to configure ATM routed bridge encapsulation on your Cisco 6400 NRP:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# interface atm | Specifies an ATM point-to-point interface. |
Step 2 | Router(config-if)# pvc VPI/VCI
| Configures a VC to carry the routed bridge traffic. |
Step 3 | Router(config-if)# atm route-bridge ip
| Enables ATM routed bridge encapsulation for IP. |
Step 4 | Router(config-if)# ip address ip-address mask | Provides an IP address on the same subnetwork as the remote network. |
Step 5 | Router(config-if)# ^Z
| Exits to EXEC mode. |
Only the specified network layer (IP) will be routed. Any remaining protocols can be passed on to bridging or other protocols. In this manner, ATM routed bridge encapsulation can be used to route IP while other protocols (such as IPX) are bridged normally.
This section provides the following configuration examples:
The following example shows a typical ATM routed bridge encapsulation configuration:
interface atm 4/0.100 point-to-point
ip address 172.69.5.9 255.255.255.0
pvc 0/32
atm route-bridged ip
The following ATM routed bridge encapsulation example uses a static route to point to an unnumbered interface:
interface atm 4/0.100 point-to-point
ip unnumbered ethernet 1/0
pvc 0/32
atm route-bridged ip
ip route 172.69.5.9 255.255.255.0 interface atm 4/0.100
The following example shows concurrent use of ATM routed bridge encapsulation with normal bridging. IP datagrams are route-bridged, while other protocols (such as IPX or AppleTalk) are bridged.
bridge 1 protocol ieee
interface atm 4/0.100 point-to-point
ip address 172.69.5.9 255.255.255.0
pvc 0/32
bridge-group 1
atm route-bridged ip
Enter the show ip cache command to confirm that ATM routed bridge encapsulation is enabled:
Router# show ip cache
IP routing cache version 4490, 141 entries, 20772 bytes, 0 hash overflows
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last 7 seconds, 0 in last 3 seconds
Last full cache invalidation occurred 0:06:31 ago
Prefix/Length Age Interface MAC Header
131.108.1.1/32 0:01:09 Ethernet0/0 AA000400013400000C0357430800
131.108.1.7/32 0:04:32 Ethernet0/0 00000C01281200000C0357430800
131.108.1.12/32 0:02:53 Ethernet0/0 00000C029FD000000C0357430800
131.108.2.13/32 0:06:22 Fddi2/0 00000C05A3E000000C035753AAAA0300
00000800
131.108.2.160/32 0:06:12 Fddi2/0 00000C05A3E000000C035753AAAA0300
00000800
131.108.3.0/24 0:00:21 Ethernet1/2 00000C026BC600000C03574D0800
131.108.4.0/24 0:02:00 Ethernet1/2 00000C026BC600000C03574D0800
131.108.5.0/24 0:00:00 Ethernet1/2 00000C04520800000C03574D0800
131.108.10.15/32 0:05:17 Ethernet0/2 00000C025FF500000C0357450800
131.108.11.7/32 0:04:08 Ethernet1/2 00000C010E3A00000C03574D0800
131.108.11.12/32 0:05:10 Ethernet0/0 00000C01281200000C0357430800
131.108.11.57/32 0:06:29 Ethernet0/0 00000C01281200000C0357430800
The ATM RBE feature routes IP over bridged RFC 1483 Ethernet traffic from a stub-bridged LAN.
RADIUS Virtual Circuit (VC) Logging allows the Cisco 6400 Universal Access Concentrator to accurately record the virtual path interface (VPI) and virtual circuit interface (VCI) of an incoming subscriber session.
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.
A new command to display the VPI/VCI information that can be used by the RADIUS VC Logging feature has been added.
Perform the following tasks to configure RADIUS VC logging:
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 pre-loaded 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. To configure a static combined NME IP address, enter the following commands beginning in global configuration mode:
 |
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. |
| 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 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:
| Command | Purpose |
|---|---|
Router(config)# ip radius
source-interface int x
| Forces RADIUS to use the IP address of a specified interface for all outgoing RADIUS packets |
Router(config)# radius-server attribute
4 nrp
| Allows the default-selected IP address to be changed. This command can only be enabled if "format d" is already configured. |
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 7-1 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]
| Displays ingress VC information of local VCs. |
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. The CPE uses the subnet mask to calculate an IP address pool from which IP addresses are assigned to PCs using the access link.
Choose at least one of the following methods to configure the subnet mask that the NRP will pass to the CPE upon request:
|
Note The subnet mask in the RADIUS user profile overrides the mask configured on the NRP. |
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.
To configure the subnet mask in the RADIUS user profile, use the Framed-IP-netmask RADIUS IETF attribute.
Example
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 |
Example
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.
Some CPE is hard-coded to request the subnet mask from the peer. If, however, the CPE uses one of the following operating systems, 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. The following sections provide typical configuration guidelines for enabling CPE to support subnet mask negotiation. |
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. |
|
Note The ppp ipcp mask request command is currently supported in Cisco IOS Release 12.1(3)DC, and will be supported in Cisco IOS Release 12.1(5)T. |
Example
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. |
Example
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
Hard-Coded
To verify that your CPE is hard-coded to request the subnet mask from the peer, refer to the user documentation for your CPE.
Cisco IOS
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.
CBOS
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 ip local pool command in global configuration mode:
| Command | Purpose |
|---|---|
Router(config)#ip local pool pool-name start-IP | Configures a group of local IP address pools, gives this group a name, 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
This 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).
This 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 show ip local pool group command and check for the pool group name in the output.
This new command acts exactly like the existing command if the new group keyword is not present.
| Command | Purpose |
|---|---|
Router(config)#show ip local pool [[group group-name] | Configures a group of local IP address pools and gives this group a name. |
The forms of this show command allow the following:
show ip local pool - displays all pools
show ip local pool poolname - displays only pool poolname
show ip local pool group - displays all pools in base system group
show ip local pool group group-name - displays all pools in a group
The following example displays all pools:
router#sh 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#sh 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. |
Benefits
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 {up
| down | oam failure loopback}
| 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 {multipoint |
point-to-point}]
or Router(config)# interface atm
slot/port-adapter/0[.subinterface-number {multipoint
| point-to-point}]
or Router(config)# interface atm
number[.subinterface-number {multipoint |
point-to-point}]
| 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: Tue Feb 26 14:22:53 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.