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 ATM0Begins interface configuration mode on the main ATM interface, the ADSL port.
no shutFor 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 addressConserves IP addresses by not assigning an address to this main ATM interface.
dsl operating-mode autoThis 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-enableATM 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-queueEach 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-pointConfigures 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/32Begins 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 callthat 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.
Figure 6-1 shows the role of a Cisco 827 router configured with PPPoA.
Figure 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 dialerSpecifies 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 1Specifies 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 Dialer1A 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 negotiatedRather than assigning an IP address to this dialer interface, IPCP is used to obtain an IP address as needed upon startup.
ip nat outsideThis dialer interface (the ADSL interface, also the ATM interface) is the interface that translates external IP addresses through NAT.
encapsulation pppAssociates the PPP encapsulation with this dialer (ADSL) interface.
dialer pool 1Specifies 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 Dialer1Configures 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 namein 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-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 interfacethat 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 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.
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.
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.
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.