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 {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 aal5snap¹	Configures AAL5 with SNAP encapsulation.
Step 4	protocol protocol [protocol-address \| inarp] [[no] broadcast]	Maps a protocol address to the PVC.

¹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.

Examples

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

ATM Routed Bridge Encapsulation

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.

Figure 7-1: ATM Routed Bridge Encapsulation

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).

Benefits

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.

Restrictions

ATM routed bridge encapsulation does not support MAC-layer access lists. Only IP access lists are supported.

Configuration Tasks

Perform the following tasks to configure ATM routed bridge encapsulation. The first task is required; the remaining tasks are optional.

Configuring ATM Routed Bridge Encapsulation
Verifying ATM Routed Bridge Encapsulation

Configuring ATM Routed Bridge Encapsulation

Perform the following tasks to configure ATM routed bridge encapsulation on your Cisco 6400 NRP:

	Command	Purpose
Step 1	Router(config)# interface atm slot/0.subinterface-number point-to-point	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 [secondary]	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.

Configuration Examples

This section provides the following configuration examples:

ATM Routed Bridge Encapsulation Example
ATM Routed Bridge Encapsulation on an Unnumbered Interface Example
Concurrent Bridging and ATM Routed Bridge Encapsulation Example

ATM Routed Bridge Encapsulation Example

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

ATM Routed Bridge Encapsulation on an Unnumbered Interface Example

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

Concurrent Bridging and ATM Routed Bridge Encapsulation Example

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

Verifying ATM Routed Bridge Encapsulation

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

Routed Bridge Encapsulation for Cisco Express Forwarding

The ATM RBE feature routes IP over bridged RFC 1483 Ethernet traffic from a stub-bridged LAN.

RADIUS VC Logging

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.

Configuring RADIUS VC Logging

Perform the following tasks to configure RADIUS VC logging:

Configuring the NME Interface IP Address on the NSP
Verifying the NME Interface IP Address
Configuring RADIUS VC Logging on the NRP
Verifying RADIUS VC Logging
Selecting the IP Address for RADIUS Attribute 4 (NAS-IP Address)

Configuring the NME Interface IP Address on the NSP

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.

Verifying the NME Interface IP Address

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#

Configuring RADIUS VC Logging on the NRP

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.

Verifying RADIUS VC Logging

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."

Selecting the IP Address for RADIUS Attribute 4 (NAS-IP Address)

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.

Table 7-1: RADIUS Global Configuration Commands and Selected IP Addresses

Global Configuration Commands			Selected IP Address
ip radius source-interface <int x>	radius-server attribute nas-port format d	radius-server attribute 4 nrp	Selected IP Address
Enabled			NRP IP address ¹
	Enabled		NSP IP address
Enabled	Enabled		NSP IP address
Enabled	Enabled	Enabled	NRP IP address ¹
	Enabled	Enabled	NRP best-select IP address ²

¹NRP IP address of <int x>
²Automatic choice, 1st choice is loopback, etc.

Monitoring and Maintaining RADIUS VC Logging

Command	Purpose
Router> show atm ingress [all \| local-vc vpi/vci] [detailed]	Displays ingress VC information of local VCs.

IPCP Subnet Mask Support

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.

Configuring the Subnet Mask

Choose at least one of the following methods to configure the subnet mask that the NRP will pass to the CPE upon request:

Configuring the Subnet Mask in the RADIUS User Profile
Configuring the Subnet Mask on the NRP

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.

Configuring the Subnet Mask in the RADIUS User Profile

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

Verifying the Subnet Mask in the RADIUS User Profile

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

Configuring the Subnet Mask on the NRP

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).¹

¹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.

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
!

Verifying the Subnet Mask on the NRP

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.

Configuring IPCP Subnet Mask Support on the CPE

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:

Cisco Internetwork Operating System (Cisco IOS)

Cisco Broadband Operating System (CBOS)

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.

Cisco Internetwork Operating System (Cisco IOS)

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
!

Cisco Broadband Operating System (CBOS)

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

Verifying IPCP Subnet Mask Support on the CPE

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#

Troubleshooting Tips

To troubleshoot IPCP subnet mask support on the Cisco 6400 NRP, enter the following debug commands:

debug aaa authentication—displays the methods and results of authentication being used
debug aaa authorization—displays the methods and results of authorization being used
debug ppp negotiations—displays the details of PPP/IPCP subnet negotiations

IP Overlapping Address Pools

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.

Benefits

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.

Restrictions

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.

Configuring a Local Pool Group for IP Overlapping Address Pools

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 [end-IP] [group group-name] [cache-size size]	Configures a group of local IP address pools, gives this group a name, and specifies a cache size.

Example: IP Overlapping Address Pools

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.

Verifying Local Pool Groups for IP Overlapping Address Pools

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] pool-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#

ATM SNMP Trap and OAM Enhancements

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:

Generated when the operational state of a PVC changes from the DOWN to UP state.
Generated when OAM loopback fails. Additionally, when OAM loopback fails, the PVC will now remain in the UP state, rather than going DOWN.
Extended to include:
- VPI/VCI information
- The number of state transitions a PVC goes through in an interval
- The timestamp of the first and the last PVC state transition

The ATM SNMP Trap and OAM enhancements are described in the following sections:

ATM PVC UP Trap

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.

ATM PVC OAM Failure Trap

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.

Extended ATM PVC Traps

The ATM SNMP Trap and OAM enhancements introduce extended ATM PVC traps.

The extended traps include:

VPI/VCI information for affected PVCs
Number of UP-to-DOWN and DOWN-to-UP state transitions a PVC goes through in an interval

Timestamp of the first and the last PVC state transition

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:

Enable you to use SNMP to detect the recovery of PVCs that have gone DOWN.
Enable you to use SNMP to detect when OAM loopback for a PVC has failed.
Keep the PVC in the UP state when OAM loopback has failed, allowing for the continued flow of data.
Provide VPI/VCI information in the ATM PVC traps, so that you know which PVC has changed its operational state or has had an OAM loopback failure.
Provide statistics on the number of state transitions a PVC goes through.

Restrictions

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.

Prerequisites

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

Configuration Tasks

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.

Configuring Extended ATM PVC Trap Support (required)
Enabling OAM Management (required)
Verifying ATM PVC Traps (optional)

Configuring Extended ATM PVC Trap Support

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:

up—Enables ATM PVC UP traps, which are generated when a PVC changes from the DOWN to UP state.
down—Enables ATM PVC DOWN traps, which are generated when a PVC changes from the UP to DOWN state.
oam failure loopback—Enables ATM PVC OAM FAILURE traps, which are generated when OAM loopback fails.

Enabling OAM Management

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}]

Router(config)# interface atm 
slot/port-adapter/0[.subinterface-number {multipoint 
| point-to-point}]

Router(config)# interface atm 
number[.subinterface-number {multipoint | 
point-to-point}]

Specifies the ATM interface using the appropriate form of the interface atm command.¹

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.

¹To determine the correct form of the interface atm command, refer to your ATM network module, port adapter, or router documentation.

Verifying ATM PVC Traps

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.

Configuring Extended ATM PVC Trap Support Example

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

Monitoring and Maintaining ATM PVC Traps

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.

Table of Contents

Miscellaneous Features