Home > Articles > Cisco Network Technology > General Networking > End-to-End DSL Architectures

End-to-End DSL Architectures

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Apr 4, 2003.

Chapter Description

Explore the configurations of the four basic TCP/IP architectures for DSL, including three architectures based on RFC 2684, Routed Bridge Encapsulation (RBE), and Point-to-Point Protocol over ATM (PPPoA). You will go through configurations for the Cisco 827 CPE router, the Cisco 6000 series of IP/DSL Switches, and the Cisco 6400 Universal Access Concentrator (UAC).

This chapter presents the configurations of the four basic TCP/IP architectures for DSL that were described in Chapter 3, "TCP/IP Over ATM." These include three architectures based on RFC 2684 (which made obsolete RFC 1483): Integrated Routing and Bridging (IRB), Routed Bridge Encapsulation (RBE), and Point-to-Point Protocol over ATM (PPPoA). Additionally, both Chapter 3 and this chapter explain Point-to-Point Protocol over Ethernet (PPPoE, RFC 2516). Virtual Private Networks (VPNs) are also described in this chapter, but they are configured beyond the actual DSL network.

In DSL networking, PPPoE is the most popular, although exact market shares of these architectures have not been defined. IRB was the first common architecture in the DSL world and is generally considered obsolescent, although it is still present in legacy networks around the world. RBE is more secure and scalable than IRB while still allowing for the simple, low-cost equipment found in legacy networks. PPPoA is the author's favorite, enabling optimal scalability for provider network expansion and increased end-user sophistication, combined with better security for all parties. All these architectures are encountered in today's DSL networks, and all are covered on the Cisco certification examinations.

This chapter starts with configurations for the Cisco 827 CPE router and then describes the configurations for the Cisco 6000 series of IP/DSL Switches. It finishes with the configurations for the Cisco 6400 Universal Access Concentrator (UAC). You might need to refer to Appendix B, "ATM Overview," to review the details of ATM.

Cisco 827 DSL Configurations

Setting up voice service on the Cisco 827 router is more demanding than just enabling the port(s). Voice activation actually includes two configurations: one for data and one for voice. When you have completed the configuration for the data scenario, you can add voice by configuring the voice ports and dial peers for both analog voice service and Voice over IP (VoIP). The first part of this chapter shows the configuration for data traffic only. Each architecture configuration is explained in its own section. Voice configurations for the 827 are shown in the second half of this chapter.

The data configurations section first lists the configuration commands that are common to all the TCP/IP architectures, such as interface configuration commands. If you understand and can apply those common commands, you can see more quickly the specific commands for each type of architecture. These architecture-specific commands are described in a different section for each type. Beyond learning the commonalities of all the architectures, you only need to learn the architecture-specific commands for Cisco certification testing, because no DSL service provider would combine all four types simultaneously. Therefore, in the real world, you probably would read about a certain architecture and its configurations, (optimally) try out that configuration or evaluate it for your own network needs, and return to read about alternatives at your convenience.

Interface Commands Common to All DSL Architectures

These configuration commands apply to the ATM and Ethernet interfaces of the Cisco 827, where the ATM interface is also the DSL interface facing the DSL network itself. ATM commands are listed and explained, followed by the Ethernet commands, including enabling basic Network Address Translation (NAT) and Port Address Translation (PAT). After the interface commands, Challenge Handshake Authentication Protocol (CHAP) security commands are listed and explained. Finally in this section of common Cisco 827 commands, basic IP routing commands are listed and explained.

ATM Interface Commands

On the Cisco 827 ADSL router, here are the ATM interface configuration commands you will use most frequently, regardless of the type of TCP/IP architecture:

  • interface ATM0—Begins interface configuration mode on the main ATM interface, the ADSL port.

  • no shut—For new routers, the only configuration that is necessary to activate the ADSL port (the ATM interface) is to perform a no shut on the ATM interface. If the ADSL trainup is successful, you see the ATM interface line and line protocol become active. If not, use the debug command to debug the trainup sequence, as explained throughout other Cisco documentation but not repeated here.

  • no ip address—Conserves IP addresses by not assigning an address to this main ATM interface.

  • dsl operating-mode auto—This value might be the default, depending on your version of Cisco IOS Software. Cisco recommends using this command if you are unsure what discrete multitone (DMT) technology the ISP is using. It provides for automatic analysis and synchronization for either of the ITU-defined DMT standards (G.992.1 and G.992.2). If the DSLAM/IP-DSL Switch is using a Cisco 4xDMT ADI-based card with the ANSI-defined DMT2 standard, you should enter the command dsl operating-mode ansi-dmt.

  • Depending on the version of Cisco IOS Software, you might or might not see the command no atm ilmi-keepalive in the configuration, because this is now a default value. When you enable Integrated Local Management Interface (ILMI) keepalives on a dual ATM module, periodic ILMI keepalive messages are sent to the ATM switch on the active. The ATM switch responds to the ILMI keepalives. If the ATM switch fails to respond to four consecutive keepalives, the dual switches from the active to the backup. The ILMI keepalives feature is useful only if the module is connected to two different ATM switches.

  • bundle-enable—ATM Permanent Virtual Circuit (PVC) bundles allow you to configure multiple PVCs that have different quality of service (QoS) characteristics between two devices. The purpose is to bind a PVC from the bundle to one or more precedence values. To determine which VC in the bundle will be used to forward specific traffic, the ATM VC bundle management software matches precedence levels between packets and VCs.

    The ATM virtual bundle acts as a single routing link to the destination router. The Operation and Maintenance (OAM) polling mechanism monitors each circuit's integrity individually. For more information, see Appendix B.

  • hold-queue—Each network interface, including this ATM interface, has a hold-queue limit. This limit is the number of data packets that the interface can store in its hold queue before rejecting new packets. When the interface empties the hold queue by one or more packets, the interface can accept new packets again.

    The command no hold-queue with the appropriate keyword restores an interface's default values. The keyword in specifies the input queue, and the keyword out specifies the output queue. The default input hold queue is 75 packets. The default output hold-queue limit is 100 packets. A queue size has no fixed upper limit. The input hold queue prevents a single interface from flooding the network server with too many input packets. Further input packets are discarded if the interface has too many input packets outstanding in the system. This limit prevents a malfunctioning interface from consuming an excessive amount of memory. For slow links, use a small output hold-queue limit. This approach prevents storing packets at a rate that exceeds the link's transmission capability. For fast links, use a large output hold-queue limit. A fast link might be busy for a short time (and thus require the hold queue), but it can empty the output hold queue quickly when capacity returns.

  • interface ATM0.1 point-to-point—Configures a virtual ATM subinterface and defines it as a point-to-point type; this command opens subinterface configuration mode. Subinterfaces are handy for differentiating virtual connections by DSL QoS and/or ATM class of service. For instance, priority business DSL subscribers' virtual connections might be configured on one subinterface, and standard residential DSL subscribers' virtual connections would be configured on another subinterface. There might be hundreds, or even thousands, of subinterfaces, so there might be two, three, or more digits after the ATM0. prefix. In practice, good DSL network design limits the number of subinterfaces, just as different service-level agreements are limited to a reasonable number that can be easily marketed and configured. Last but not least regarding subinterfaces, an enormous number of subinterfaces would eventually hamper CPU performance.

  • pvc 1/32—Begins to configure this PVC, as assigned by the DSL network provider, as virtual circuit 32 on virtual path 1 (or any other valid combination) on this interface or subinterface; this command opens PVC configuration mode.

  • If NAT is used, the command ip nat outside enables external network address translation and establishes this subinterface (the ADSL interface on the 827) as the outside interface.

Ethernet Interface Commands

  • On the Cisco 827 ADSL router, the Ethernet interface is the one facing the user network. Here are the Ethernet interface configuration commands you will see and use most frequently. They apply to most types of TCP/IP architectures.

  • If NAT is used, the command ip nat inside establishes the Ethernet interface as the inside interface for translation direction.

  • The command ip address negotiated indicates that Internet Protocol Control Protocol (IPCP, RFC 1332) is being used rather than a static IP address. IPCP is an efficient way to obtain the baseline IP address for the Ethernet interface. It is frequently used to enable distribution of IP addresses to the user's LAN devices through Dynamic Host Configuration Protocol (DHCP), where IPCP provides a valid starting address to acquire the range of DHCP addresses.

  • Alternatively, a command such as ip address 192.168.1.1 255.255.255.0 assigns an IP address and subnet to the Ethernet interface.

  • The command mtu size applies to the Maximum Transmission Unit (MTU). Each interface has a default maximum packet size or MTU size. This number generally defaults to the largest size possible for that type of interface. The default MTU size is 1500 on the Ethernet interface. As you will learn later in this chapter, the PPPoE configuration requires changing this Ethernet default. Other architectures and interfaces might require specific MTU configuration as well.

Challenge Handshake Authentication Protocol (CHAP) Commands

The command ppp authentication chap callin is one of three commands in typical configurations that together specify CHAP parameters for multiple scenarios. Normally, when two devices use CHAP, each side sends a challenge to which the other side responds, and it is authenticated by the challenger. Each side authenticates the other independently. If you want to operate with non-Cisco routers that do not support authentication by the calling router or device, you must use the command ppp authentication chap callin.

When you use the ppp authentication command with the callin keyword, the access server authenticates the remote device only if the remote device initiated the call—that is, if it is the remote device that is calling in. In this case, authentication is specified on incoming (received) calls only.

The second and third CHAP commands configure the central site with a single username and shared secret. These values can be used to authenticate multiple dial-in clients.

For example, consider a situation in which multiple remote devices dial into a central site. Using normal CHAP authentication, the username (which would be the host name) of each remote device and a shared secret must be configured on the central router. In this scenario, the configuration of the central router can get lengthy and cumbersome to manage; however, if the remote devices use a username that is different from their host name, this can be avoided. The username configuration command is ppp chap hostname username1.

The third CHAP command is ppp chap password password. It lets the 827 call one or more routers that do not support CHAP as it is defined in up-to-date Cisco IOS Software versions on the 827 router. This configures a common CHAP secret password to use in response to challenges from an unknown peer.

For example, your Cisco 827 might call a rotary of routers (either from another vendor, or running an older version of the Cisco IOS Software) to which a new (that is, unknown) router has been added. The ppp chap password command allows you to replace several username and password configuration commands with a single copy of this command on any dialer interface or asynchronous group interface. This command is used for remote CHAP authentication only (when routers authenticate to the peer). It does not affect local CHAP authentication.

Additional Common Commands

The command ip route 0.0.0.0 0.0.0.0 192.168.2.254 configures the default gateway, pointing the way through the interface address 192.168.2.254 to the rest of the networked world. The commands discussed previously, starting with the interface configuration commands and including NAT, CHAP, and other common commands, are the basis of the following sections concerning architecture-specific commands.

PPPoA Configuration

Figure 6-1 shows the role of a Cisco 827 router configured with PPPoA.

Figure 6-1Figure 6-1 Cisco 827 Using PPPoA with Dialer Interface, IPCP Negotiation, and NAT Overload


The following configuration output enables the functionality shown in Figure 6-1. In this configuration, first the Ethernet interface is configured with its IP address and subnet mask. Then the ATM interface (ATM0) is configured, as explained earlier in the "ATM Interface Commands" section, and an ATM subinterface is defined on which PVC 1/32 is configured. The PPPoA-specific commands begin after the PVC definition. Those commands are explained following this configuration listing:

version 12.2
!
interface Ethernet0
  ip address 192.168.1.1 255.255.255.0!
interface ATM0
!(lines omitted)
  interface ATM0.1 point-to-point
   pvc 1/32
     encapsulation aal5mux ppp dialer
     dialer pool-member 1
  interface Dialer1
    ip address negotiated
    ip nat outside
    encapsulation ppp
    dialer pool 1
!
 ip route 0.0.0.0 0.0.0.0 Dialer1
!
hold-queue 224 in

  ppp authentication chap callin
  ppp chap hostname <username1>
  ppp chap password <password1>
!

Here are descriptions of the commands:

  • encapsulation aal5mux ppp dialer—Specifies the encapsulation type for the PVC as aal5mux with Point-to-Point Protocol (PPP) characteristics. It also points back to the dialer interface, which is the ADSL interface on the Cisco 827.

  • dialer pool-member 1—Specifies that this PVC is a member of dialer pool 1. There can be more than one dialer pool on the physical dialer interface, which is the ADSL interface. Each dialer pool connects to a specific destination subnetwork. That subnetwork usually represents the Cisco IP/DSL Switch.

  • interface Dialer1—A dialer interface assigns PPP features (such as authentication and IP address assignment method) to a PVC. Dialer interfaces are used when configuring PPP over ATM. This value can be any number in the range 0 through 255. No dialer rotary groups are predefined. This command also opens interface configuration mode for the ADSL interface, which is designated the dialer interface. A dialer interface is not a physical interface, but a logical grouping of physical interfaces with the same configuration. Dialer interfaces allow you to apply a single interface configuration, such as an access control list, to one or more physical interfaces. This standardizes the configuration on those interfaces and reduces configuration labor.

  • ip address negotiated—Rather than assigning an IP address to this dialer interface, IPCP is used to obtain an IP address as needed upon startup.

  • ip nat outside—This dialer interface (the ADSL interface, also the ATM interface) is the interface that translates external IP addresses through NAT.

  • encapsulation ppp—Associates the PPP encapsulation with this dialer (ADSL) interface.

  • dialer pool 1—Specifies on the dialer (ADSL) interface which dialer pool number to use to connect to a specific destination subnetwork. The number can be any number from 1 to 255. There is no default. This number must match the number used in the dialer pool-member 1 under the physical interface.

  • ip route 0.0.0.0 0.0.0.0 Dialer1—Configures the default route available through this dialer (ADSL) interface.

Now suppose that the provider has assigned a single, external IP address. In addition to the configuration shown previously, you can proceed to add the commands for NAT overload, also called PAT, as shown in the following:

interface Ethernet0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
interface Dialer1
  ip address negotiated
  encapsulation ppp
  dialer pool 1
!  (lines omitted)
  ip nat outside
!

ip route 0.0.0.0 0.0.0.0 Dialer0

access-list 1 permit 192.168.1.0 0.0.0.255
!
ip nat inside source list 1 interface Dialer1 overload
  • ip nat outside establishes the interface Dialer1, the ADSL interface, as the NAT outside interface.

  • access-list 1 permit 192.168.1.0 0.0.0.255 defines a standard access list, matching the number 1 of the list 1 in the next command, permitting addresses that need translation.

  • ip nat inside source list 1 interface Dialer1 overload enables PAT using the Dialer1 IP address as the inside global address for source addresses that match access-list 1 in the previous command.

The final set of modifications to the original, simple PPPoA configuration lets the 827 deliver IP addresses to the user workstations and other client devices using DHCP:

interface Ethernet0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
interface Dialer0
   ip address negotiated
   encapsulation ppp
   dialer pool 1
!  (lines omitted)
   ip nat outside

!(lines omitted)

ip dhcp pool POOL-DHCP
    network 192.168.1.0 255.255.255.0
    domain-name cisco.com
    dns-server 192.168.3.1
    default-router 192.168.1.1

In this configuration, the command ip dhcp pool POOL-DHCP defines the range of IP addresses that can be assigned to the DHCP clients. Note that rather than specify a beginning address and an ending address in the pool, subnetting is used for the entire subnet 192.168.1.0.

The command domain-name cisco.com simply configures the domain name—in this case, with the variable cisco.com. The command dns-server 192.168.3.1 defines the DNS server with that IP address. The command default-router 192.168.1.1 designates the 827 router as the default router and specifies an IP address.

RFC 2684 Bridging (Formerly RFC 1483 Bridging)

Figure 6-2 shows the role of the 827 device in a bridged network.

Figure 6-2Figure 6-2 Cisco 827 Using RFC 2684 Bridging (IRB) with NAT

RFC 2684 bridging is possible on the Cisco 827, as shown in this section's configuration and explanations. The 827 is capable of more-sophisticated configurations than bridging. Therefore, its use in bridging would probably be as an interim solution for a DSL provider who is migrating to a more-sophisticated model, such as PPPoE or PPPoA. When the 827 router is in bridge mode, the Ethernet and ATM interfaces can have the same IP address. That would be the MAC address of interface ethernet0, displayed with the Cisco IOS Software command show interface ethernet 0. Following is the configuration for RFC 2684 bridging:

bridge irb
!
interface Ethernet0
 ip address 192.168.1.1 255.255.255.0
!
interface ATM0
 (lines omitted)
 bundle-enable
!
interface ATM0.1 point-to-point
 pvc 1/32
!
 encapsulation aal5snap
!
 bridge-group 1
!
interface BVI1
!
 ip address 192.168.2.1 255.255.255.0
 no ip directed-broadcast
!
ip route 0.0.0.0 0.0.0.0 192.168.2.254
!
bridge 1 protocol ieee
 bridge 1 route ip

Here are the explanations for the pertinent commands in this configuration:

  • bridge irb enables IRB as opposed to the Cisco 827 default of routing.

  • encapsulation aal5snap specifies the encapsulation type for this particular PVC. aal5snap means ATM Adaptation Layer 5 Subnetwork Access Protocol, the standard for RFC 2684-based bridging.

  • bridge-group 1 specifies the bridge-group number to which the point-to-point ATM0.1 interface belongs. This corresponds to the bridge protocol command.

  • interface BVI1 defines a bridge group virtual interface (BVI) on the existing routed interface from the WAN bridge group to the nonbridged LAN interface—that is, from the DSL provider to the internal LAN. Each bridge group can have only one corresponding BVI. When you configure the BVI and enable routing on it, as shown in the preceding command, packets that come in on a routed interface destined for a host on a segment that is in a bridge group are transferred from Layer 3 routing to Layer 2 bridging across this interface.

  • ip address 192.168.2.1 255.255.255.0 assigns an IP address and subnet to the BVI within interface configuration mode on BVI 1.

  • bridge 1 protocol ieee enables the Cisco 827 router's bridging engine, identifies the bridging process with a bridge-group number, and specifies the particular spanning tree algorithm used to avoid bridging loops. All routers on the network that expect to bridge between each other need to share the same bridge-group number. The selected spanning-tree protocol must also be consistent on each router. In this example, the IEEE spanning-tree algorithm is specified (as it invariably is) rather than the DEC option.

  • bridge 1 route ip enables IP routing to and from bridge group 1.

RFC 2684 Bridging with PAT

Beyond the simplest configuration for RFC 2684 bridging, you can also configure the Cisco 827 to include NAT and PAT. As described previously for the basic IRB configuration, the Cisco 827 might be used as a bridging device in a legacy DSL network situation. In this scenario, only one registered IP address might be assigned by the service provider, indicating the benefit of PAT, which translates one-to-many IP addresses. This is shown in the following configuration:

bridge irb
! (lines omitted)
interface Ethernet0
  ip address 192.168.1.1 255.255.255.0
  ip nat inside
! (lines omitted)
interface BVI1
 ip address 192.168.2.1 255.255.255.0
  ip nat outside
!
ip nat inside source list 1 interface BVI1 overload
!
! (lines omitted)
access-list 1 permit 192.168.1.0 0.0.0.255

The explanations for the new commands, enabling PAT, are as follows:

  • Together, the following three lines in sequence open interface configuration mode for the primary Ethernet interface, assign an IP address to it, and establish the Ethernet interface as the inside (customer-facing) interface:

    interface Ethernet0
     ip address 192.168.1.1 255.255.255.0
     ip nat inside
  • Together, the following three lines in sequence open interface configuration mode for the BVI, assign an IP address to it, and establish the BVI interface as the outside (DSL network-facing) interface:

    interface BVI1
     ip address 192.168.2.1 255.255.255.0
      ip nat outside
  • ip nat inside source list 1 interface BVI1 overload enables dynamic translation of addresses permitted by the access list to the address specified in the BVI.

  • access-list 1 permit 192.168.1.0 0.0.0.255 defines a standard access list permitting addresses that need translation with PAT.

RFC 2684 Bridging with NAT

Continuing the scenario of the Cisco 827 in bridging mode, suppose that the DSL provider has assigned a block of IP addresses instead of a single address as defined previously. For multiple IP addresses, NAT can be used to translate many-to-many IP addresses. Like PAT, NAT provides privacy for the internal, client-side IP addresses on the internal LAN. These additions are shown in the following configuration snippet. The pertinent commands are followed by the explanations for the commands that amplify the original RFC 2684 bridging configuration.

bridge irb
! (lines omitted)
interface Ethernet0
  ip address 192.168.1.1 255.255.255.0
  ip nat inside
!
interface ATM0
! (lines omitted)

!
interface ATM0.1 point-to-point
  pvc 1/35
!
ip address 192.168.2.1 255.255.255.0
  ip nat outside
!
ip nat pool POOL-A 192.168.2.2 192.168.2.10 netmask 255.255.255.0
!
ip nat inside source list 1 pool POOL-A overload
!
access-list 1 permit 192.168.1.0 0.0.0.255

Following are the explanations that add to the original RFC 2684 bridging configuration to permit NAT:

  • Together, the following three BVI-related commands open configuration mode for this BVI, assign an IP address and subnet to it, and then establish the BVI as the outside (DSL network-facing) interface:

    interface BVI1
      ip address 192.168.2.1 255.255.255.0
      ip nat outside
  • ip nat pool POOL-A 192.168.2.2 192.168.2.10 netmask 255.255.255.0 creates a pool named POOL-A of global (registered) IP addresses for NAT, from addresses 192.168.2.2 through 192.168.2.10, with appropriate subnet masks.

  • ip nat inside source list 1 pool POOL-A overload enables dynamic translation of addresses permitted by the access list numbered 1 to one of the addresses specified in the pool.

  • access-list 1 permit 192.168.1.0 0.0.0.255 defines a standard access list permitting addresses that need translation.

RBE Configuration

RBE is set up on the Cisco 827 router exactly like its more-basic cousin, IRB. Remember from the descriptions of the TCP/IP architectures in Chapter 3 that RBE is a more-efficient implementation of RFC 2684 bridging than simple IRB. For RBE, the difference consists of only a few different commands configured on the IP DSL Switch, Cisco 6400, or a comparable Layer 3 device. In the DSL environment, RBE actually routes IP over bridged RFC 2684 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. These interfaces on the IP/DSL Switch or a similarly-capable device offer increased performance and flexibility over IRB. In addition, RBE reduces the security risk associated with IRB by reducing the size of the unsecured network. By using a single virtual circuit (VC) allocated to a subnet (which could be as small as a single IP address), ATM RBE limits the "trust environment" to a single customer premises using IP addresses in the subnet.

PPPoE Configuration

The PPPoE feature allows a PPP session to be initiated on a simple bridging Ethernet-connected client. The session is transported over the ATM link via encapsulated Ethernet-bridged frames. With PPPoE, multiple PCs can be installed behind the Cisco 827. As with PPPoA, traffic from these clients can be filtered, NAT can be run, and so on.

In Cisco IOS Software Release 12.1(3)XG, a PPPoE client feature was introduced for the Cisco 827, allowing the PPPoE client functionality to be moved to the router.

When the Cisco 827 itself is the PPPoE client, the 827 PPPoE configuration uses Virtual Private Dialup Networking (VPDN). The following configurations show this scenario. This requires Cisco IOS Software version 12.1(3)XG or later. Multiple PCs can be installed behind the Cisco 827. The Cisco 827 performs routing in this case, and it can be set up as the DHCP server and can perform NAT/PAT, as in the PPPoA configuration example.

The following is the configuration of the PPPoE client on the 827. It is followed by detailed explanations of the important commands.

vpdn enable
!
vpdn-group pppoe
    request-dialin
    protocol pppoe
!
interface Ethernet0
    ip address 10.92.1.182 255.255.255.0
    ip nat inside

! 

interface ATM0
!(lines omitted)
! 

interface ATM0.1 point-to-point
    pvc 1/32
       pppoe-client dial-pool-number 1

interface Dialer1
    ip address negotiated
    mtu 1492
    ip nat outside
    encapsulation ppp 

   dialer pool 1
    ppp authentication chap callin
    ppp chap hostname client1
    ppp chap password 7 020508520E081B70


ip nat inside source list 1 interface Dialer1 overload
ip classless
ip route 0.0.0.0 0.0.0.0 dialer1
no ip http server
!
access-list 1 permit any

The command vpdn enable turns on VPDN on the router. PPPoE runs on top of AAL5SNAP, but the encap aal5snap command is not used on the interface, as it is with simple RFC 2684 bridging.

The command vpdn-group pppoe associates a VPDN group with a VPDN profile. Then the command request-dialin means that this endpoint, the 827, represents the PPPoE client requesting to establish a PPPoE session with the aggregation unit (6400 UAC).

The third command in this group, protocol pppoe, characterizes this VPDN group as a PPPoE protocol type.

After the ATM subinterface command and the PVC definition, the command pppoe-client dial-pool-number 1 indicates that the PPPoE client is linked to a dialer interface upon which a virtual-access interface is cloned.

The command mtu 1492 applies to the MTU, as introduced at the start of this chapter in the Ethernet interface commands. The default MTU size is 1500 on the dialer interface. Because the PPPoE header is 8 bytes long, you must lower the maximum MTU size to 1492 bytes (1500 minus 8) to allow the 8 bytes of PPPoE header overhead.

If an 82X router terminates the PPPoE traffic, a computer connected to the Ethernet interface might have problems accessing web sites, because the default MTU configured on the PC(s) might be too high. The default MTU on the computer is 1460. The solution is to let the router automatically reduce the value of the Maximum Segment Size (MSS) inside the Transmission Control Protocol (TCP) Synchronization (SYN) packets transmitted by the PCs by entering the following command on the router's Ethernet interface:

ip adjust-mss mss

where mss must be 1452 or less to fix the computer-82X PPPoE MTU problem. This command works only if NAT is configured.

NOTE

It is vital to note that all devices on a physical medium must have the same protocol MTU to operate.

The command encapsulation ppp is self-explanatory. The PPP encapsulation provides for multiplexing of different network-layer protocols simultaneously over the same link. The PPP encapsulation has been carefully designed to retain compatibility with the most commonly used supporting hardware.

To support high-speed implementations, the default encapsulation uses only simple fields, only one of which needs to be examined for demultiplexing. The default header and information fields fall on 32-bit boundaries, and the trailer may be padded to an arbitrary boundary. The packets to be encapsulated consist of a protocol field, followed by the payload and optionally followed by padding.

The command ip nat inside source list 1 interface Dialer1 overload enables dynamic translation of addresses permitted by the access list to the address specified in the Dialer interface.

The command ip route 0.0.0.0 0.0.0.0 Dialer1 configures the default route. For NAT you can overload on the Dialer1 interface and add a default route out to the Dialer1 interface, because the dialer's IP address can change.

The command access-list 1 permit any permits any source address to be translated.

When a packet leaves via this Ethernet interface for a multicast routing table entry, the packet is process level-switched for this interface but may be fast-switched for other interfaces in the outgoing interface list. When fast switching is enabled (such as in unicast routing), debug messages are not logged. If you want to log debug messages, you must disable fast switching, as was done in this configuration.

VPN Configuration

A VPN carries private data over a public network, extending remote access to users over a shared infrastructure. VPNs maintain the same security and management policies as a private network. They are the most cost-effective method of establishing a point-to-point connection between remote users and a central network.

A benefit of access VPNs is the way they delegate responsibilities for the network. The customer outsources the responsibility for the IT infrastructure to an Internet service provider (ISP). The ISP maintains the modem pools into which the remote users dial, the access servers, and the internetworking expertise. The customer is then responsible only for authenticating users and maintaining its network. VPNs also allow separate and autonomous protocol domains to share common access infrastructure, including modems and access servers, enabling service provider resource sharing among clients.

Instead of connecting directly to the network by using the expensive Public Switched Telephone Network (PSTN), access VPN users only need to use the PSTN to connect to the ISP local point of presence (POP), constituting a VPDN. The ISP then uses the Internet to forward users from the POP to the customer network.

Forwarding a user call over the Internet provides dramatic cost savings for the customer. Access VPNs use Layer 2 tunneling technologies such as Layer 2 Tunneling Protocol (L2TP) to create virtual point-to-point connections between users and the customer network. These tunneling technologies provide the same direct connectivity as the expensive PSTN by using the Internet. This means that users anywhere in the world have the same connectivity as they would have at customer headquarters.

Using L2TP tunneling, an ISP or other access service can create a virtual tunnel to link a customer with remote sites or remote users with corporate home networks. In particular, a network access server (NAS) at the ISP POP exchanges PPP messages with the remote users and communicates through L2TP requests and responses with the customer tunnel server to set up tunnels.

L2TP passes routed protocol packets through the virtual tunnel between endpoints of a point-to-point connection. Frames from the remote users are accepted by the ISP POP, stripped of any linked framing or transparency bytes, encapsulated in L2TP, and forwarded over the appropriate tunnel. The customer tunnel server accepts these L2TP frames, strips the Layer 2 encapsulation, and processes the incoming frames for the appropriate interface.

2. Cisco 827 Configurations for Voice Service | Next Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020