The Ultimate CCNA Study Package - ICND 1

Chris Bryant, CCIE #12933 http://www.thebryantadvantage.com Back To Index

Wide Area Networks (WANs)

Don't Miss The "Recommended Video Viewing" Section At The End Of This Section! Overview
The Physical Side Of WANs Directly Connecting Routers Via Serial Interfaces HDLC And PPP Introduction To Frame Relay RFC 1918 Private Addresses, NAT, and PAT Introduction To ATM Modems And DSL Variations

NOTE: As of July 1, 2009, it is strongly recommended to all CCENT testtakers that you study BOTH the Frame Relay material in the ICND1 and ICND2 sections of this course. The ICND1 material is in this section; the ICND2 material is in the "Point-to-Point And Frame Relay" section. Go get 'em! :) - Chris B.

Up to this point in the course, we've concentrated on the Local Area Network (LAN), and with good reason! Both your CCENT exam and the average network admin's duties focus on the local network. However, we should certainly know a little about the network that connects our LANs....the Wide Area Network (WAN).

I used a cloud to symbolize the WAN, and you'll hear that term more than once relating to WANs, as you'll see during the Frame Relay discussion later in this section. We're going to take a look at the physical connectivity of the WAN that we as network admins (and future CCENTs and CCNAs) need to know about, and follow that up with a discussion of different WAN protocols we can use to make the inter-LAN connections possible. The Physical Side Of WANs Going back to the previous illustration, one reason we refer to the WAN connection asa "cloud" is that we don't know exactly what hardware is in use in the WAN, and we're not responsible for it - that's up to the service provider, the company that sells WAN services such as Frame Relay. What we are responsible for are the routers you see in that diagram, and our routers are going to have to communicate with one of the service provider's devices. The service provider's half of this communication is an external channel service unit / data service unit, which thankfully is referred to as a CSU/DSU.

At some point, the responsibility for the physical devices passes from us as network admins to the service provider. This is the demarcation point, typically referred to as the demarc point. In theory, the demarc point is easy to define; when you're arguing with the service provider on a Friday afternoon when everyone wants to go home, the exact location of the demarc point suddenly becomes a huge point of contention. Theoretically, the demarc point is found at the CSU/DSU. The cable leading from the CSU/DSU to the router and the CSU/DSU itself is considered to be the customer's equipment and responsibility. That's us! All cabling on the "other side" of the CSU/DSU, along with the hardware in the WAN cloud, is the service provider's equipment. The CSU/DSU fills the router in on a very important piece of information, the clock rate. When the CSU/DSU does this, it's basically telling the router "here's how quickly you can send and receive data". Later in this section, we'll simulate a point-to-point link on a Cisco router and you'll see the command that allows a Cisco router to give another router this vital

information. When it comes to the clockrate:

The Data Communications Equipment (DCE) provides the clockrate The Data Terminal Equipment (DTE) receives the clockrate. By default, a Cisco router acts as a DTE.

We're going to discuss two common WAN protocols in just a moment, and I want you to see the show commands that verify these protocols. To do so, we're going to use a configuration that isn't common in real life, but is very common in home labs. We're going to use two Cisco routers that are directly connected at their Serial0 interfaces, which means that one must serve as the DCE. We also need a special cable, the aptly-named DTE/DCE cable. Connecting Two Cisco Router Serial Interfaces Directly For these demos, I've got R1 and R3 directly connected at their S0 (Serial0) interfaces via a DTE/DCE cable.

To tell the DTE end from the DCE end of the cable before connecting it, look for a small label wrapped around one or both of the cable ends. That label will indicate whether that is the DCE or DTE end. If there is no label, the connector itself may have DTE or DCE imprinted on it. Most newer DTE/DCE cables have the imprint rather than the label. After connecting the cable to the respective routers, use show controller serial x to ensure the router sees the cable as a DCE or DTE. You will see a great deal more output than this when you run this command, but the information that's important to us right now is at the very top.
R3#show controller serial 1 HD unit 1, idb = 0x1C44E8, driver structure at 0x1CBAC8 buffer size 1524 HD unit 1, V.35 DCE cable

It's the DCE end of the cable that must provide the clockrate. Here's what show interface serial 1 on R1 reveals before the clockrate command is configured:

R1#show interface serial 1 Serial1 is up, line protocol is down Hardware is HD64570 Internet address is 172.12.13.1/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set

When you see the physical interface upand the line protocol down, there's some kind of logical problem with the interface. In this case, the DTE side is not receiving the required clockrate. Once we do configure the clockrate on the DCE's Serial1 interface, the line protocol comes up and stays up. No reset or reload is needed.

R3(config)#interface serial1 R3(config-if)#clockrate 56000 13:06:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed stateto up

Verify with show interface serial1 on R1.

R1#show interface serial1 Serial1 is up, line protocol is up Hardware is HD64570 Internet address is 172.12.13.1/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set

I know I've mentioned this several times during the course, but this truly bears repeating as it's a fundamental rule of troubleshooting: If the interface shows asadministratively down, it's simply shut down manually and needs to be opened. If the interface shows as down, there's a physical problem, perhaps a loose cable If the interface is up but the line protocol is down, that means the interface is physically fine but there's a logical issue, generally an encapsulation mismatch or missing clockrate. When youre at your practice rack, youll find out that you cant put the clockrate on the DTE, because the router wont let you!
R1(config)#interface serial0 R1(config-if)#clock rate 56000 %Error: This command applies only to DCE interfaces

It's a good idea to have that memorized for the exam, though. :) Real-world hint: If you're troubleshooting a line protocol issue and you see the line protocol come up, make sure to stick around for a minute and make sure it stays up. Also, the line protocol may show as up for about 20 seconds or so after you first open a Serial interface, but stick around and make sure it stays up. A moment ago, I mentioned that an encapsulation mismatch can bring the line protocol down. Let's take a look at two popular encapsulation options and what happens when they're used together. HDLCand PPP

HDLC and PPP are the two data-link (Layer 2) protocols to consider when choosing an encapsulation method across a serial point-to-point link.

The version of HDLC that runs on Cisco routers is Cisco-proprietary, making it unsuitable for multivendor environments. If RouterA is a Cisco router running HDLC, the only way the line protocol can come up is if the remote router is also a Cisco router running HDLC.

There are major points of distinction between the two. First, HDLC is the default encapsulation for a Cisco serial interface. Here's the output of show interface serial 1 from the previous discussion. The encapsulation is defaulting to HDLC.
R1#show interface serial1 Serial1 is up, line protocol is up Hardware is HD64570 Internet address is 172.12.13.1/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set

PPP allows data compression to be configured, where HDLC does not. Compression is performed on data before it's sent across the WAN, and the data then uses less bandwidth to send the data across the WAN.

PPP multilink allows multiple physical channels to be bundled into a single logical channel. HDLC offers no multilink capability.

PPP allows the use of two authentication schemes for point-to-point links (PAP and CHAP), which HDLC does not support either of these.

To review: HDLC is the default encapsulation on a Cisco router's Serial

interface.

PPP has features that allow the use of authentication and data compression.

PPP also allows multilink bundling, where HDLC does not. HDLC is the default on a Cisco router's serial interface. Changing the encapsulation type to PPP is simple enough, but be prepared for the line protocol to go down when doing so.
R1(config)#interface serial1 R1(config-if)#encapsulation ppp

4d19h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state todown

The line protocol went down almost immediately, but there's no message about the physical interface going down. The issue is that the opposite end of the connection, interface Serial1 on R3, is still running HDLC. Mismatched encapsulation types will result in the line protocol going down and staying down.

Let's compare the output of show interface serial 1 on both R1 and R3 after PPP was configured on R1.
R1#show int serial1 Serial1 is up, line protocol is down Hardware is HD64570 Internet address is 172.12.13.1/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set R3#show interface serial 1 Serial1 is up, line protocol is down Hardware is HD64570 Internet address is 172.12.13.3/24 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set

Changing the encap type to PPP on R3 will result in the line protocol coming back up dynamically - no reload or resetting the interface is necessary. When troubleshooting a line protocol issue, make sure that the line protocol STAYS up after coming up!
R3#conf t

Enter configuration commands, one per line. End with CNTL/Z. R3(config)#int serial1 R3(config-if)#encap ppp 13:16:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed stateto up

An Introduction To Frame Relay Frame Relay has3 things going for it that endears it to network admins:

it's cheap it's reliable it's cheap and reliable

It also happens to be very prevalent in today's WANs, so it's a good idea to know about it for working with real-world production networks and your CCENT and CCNA exams! You'll learn all about configuring and fine-tuning Frame Relay during your CCNA studies, but let's get the fundamental conceptsdown now. Inthe following WAN, we have two routers that are hundreds of miles apart, and we need them to talk to each other. Simple enough! We know that we're going to use the Serial interfaces on the routers for a WAN connection... now what?

In the case of Frame Relay, we call our friendly Frame Relay Service Provider and tell him where our routers are, and how much bandwidth we're willing to pay for. The provider then configures some of his frame relay switches, gives us a few numbers to add to our router configuration, and we're all set! The frame relay service provider guarantees a certain amount of bandwidth will be available to a given user at any time. The more guaranteed bandwidth desired, the more it costs, but its still cheaper than

a dedicated point-to-point link. This guaranteed bandwidth is referred to as the committed information rate (CIR). Naturally, the more guaranteed bandwidth we need, the more money we have to give the frame provider! The frame provider's collection of frame relay switches has a curious name - frame relay cloud. You'll often see the frame provider's switches represented with a cloud drawing in network diagrams, much like this:

Again, the frame switches that make up that cloud belong to the frame provider. We don't configure them, and we don't want to - we've got enough to do! All of the frame switches in that cloud are DCEs, and the routers are DTEs.The frame switch that's actually connected to the router on each end of the connection will supply clockrate to the router - otherwise, the line protocol will come down, as discussed in another section.

Now, those two frame switches shown in that diagram are not going to be the only switches in that cloud. Quite the contrary, there can be hundreds of them! For simplicity's sake, the following diagram will have less than that.

Don't worry, we don't need to list or even know every possible path in that cloud! The key here is to know that not only will there be multiple paths through that cloud from Router A to Router B, but dataprobably willtake

different paths through that cloud. That's why we call this connection between the routers a virtual circuit - we can send data over it anytime we get ready, but data will not necessarily take the same path through the provider's switches every time. Frame relay is a packet-switching protocol. The packets may take different physical paths to the remote devices, at which point they will be reassembled and will take the form of the original message. In contrast, circuit-switching protocols have dedicated paths for data to travel from one point to another. There are two types of virtual circuits, one much morepopular than the other. A permanent virtual circuit (PVC) is available at all times, where a switched virtual circuit (SVC) is up only when certain criteria are met. You're going to see PVCs in most of today's networks, and we'll build some during your CCNA studies. You're not responsible for configuring SVCs on the CCENT or CCNA exams. RFC 1918 Private Addresses, NAT, And PAT You were introduced to the three RFC 1918 private address ranges in the IP Addressing section, but let's review them here:

Class A: 10.0.0.0 - 10.255.255.255 (10.0.0.0 /8) Class B: 172.16.0.0 - 172.31.255.255 (172.16.0.0 /12) Class C: 192.168.0.0 - 192.168.255.255 (192.168.0.0 /16)

You also learned that these addresses are not routable - without any additional help, hosts with these addresses will not be able to communicate with any other hosts outside their private network. That means no internet access and no communication with other hosts across the LAN! In the following example, a host attempts to send packets out to the WAN. The router will see the source IP address of 10.2.2.2, realizes that this address is a private address, and does not attempt to send the packet to its destination.

We have two options that will allow this host to communicate with WANbased hosts, Network Address Translation (NAT) and Port Address Translation (PAT). The words address translation are the key here, since the host's private address will be translated to an IP address that can be routed.

You'll see the actual CLI configurations and some options for both NAT and PAT in your CCNA studies, but for now let's take an overview of these vital network services. A common NAT deployment method is to set aside a pool of routable IP addresses, and when hosts with private addresses attempt to send packets to WAN-based hosts, their private IP address is translated to one of those routable addresses.

The router will keep a NAT table that maps the private addresses to the assigned NAT address, so when packets come back in with the NAT address, the router translates that particular address back to the appropriate private address.

NAT works beautifully, but there's one drawback - many organizations don't have enough routable IP addresses to set aside for NAT users. Port Address Translation allows a company to use a single routable IP address for multiple hosts. The routable IP address will be the same, but the port number will be different, and it's the port number that the router will use to keep the different translations straight.

We have two translations here, and the source IP address for both translations is the same, 210.1.1.2. It's the port number that's different. The router will keep a PAT table much like the NAT table mentioned earlier, with the port numbers mapped to the appropriate private address. When the WAN-based hosts respond to a particular IP address and port number, the router will translate it back to the correct private IP address.

Whether you choose NAT or PAT, the entire process is transparent to the hosts with the private addresses and the WAN-based hosts they're communicating with. The only device that even knows that NAT or PAT is in use is the router itself. The actual NAT and PAT translation table can be viewed with the command show ip nat translation. Even if you're running PAT, the commands will still reference NAT.
R3#show ip nat translations Pro Inside global Inside local Outside local Outside global --- 210.1.1.2 10.5.5.5 --- ----- 210.1.1.3 10.5.5.6 --- ----- 210.1.1.4 10.5.5.7 --- ---

Notice those four terms in the translation table - "inside global", "inside local", and so forth? Here's what they mean: Inside local addresses are used by hosts on the inside network to communicate with other hosts on that same network. These are the addresses that are actually configured on the hosts, and generally they are RFC 1918 private addresses. These inside local addresses are translated into inside global addresses. Inside global addresses are routable addresses. In the following example, 10.2.2.2 is the inside local address and 210.1.1.2 is the inside global address.

Outside global addresses are the addresses that are configured on the outside hosts. These are fully routable addresses used by Internet-based hosts. Finally, outside local addresses are the actual addresses ofremote hosts.These can be (and probably are)RFC 1918 addresses as well. These terms can take a little getting used to, but just remember - the inside addresses are the ones used by your network, and the outside addresses are the ones used by the hosts at the remote end of the communication (assuming they're using NAT as well). Most of the NAT and PAT deployments currently in use were configured at the CLI, and you'll learn how to do that in your CCNA studies. In the following lab, we're going to use the Security Device Manager (SDM) to configure a router for PAT. We'll then test the translation as well! You will not be tested on SDM in the CCENT or CCNA exam, but it's good for you to see a Cisco GUI in action. Here's the network topology:

Our PC needs to connect to that web server, but there's a problem. The PC has a Class A RFC 1918 private address, which is not a routable address. We'll use SDM to configure PAT to allow that PC connectivity to the web server, plus I'll sneak in an extra point about pings and PAT. (Try saying that three times really fast!) In another section, we use SDM to configure DHCP, and that was found

under "Additional Tasks" at the very bottom of the screen. For PAT, we just click on "Configure" and then "Interfaces And Connections" to bring this screen up.

We'll select the second radio button and click "Create New Connection".

We're going to assign a staticIP address of 172.20.21.1 /16 to the Fast Ethernet 0/1 interface. Note that this is the interface facing the Internet, as Fast Ethernet 0/0 has an RFC 1918 private address as well.

The next screen gives us a chance to configure Advanced Options, and it's here that we'll enable PAT on this interface by checking the "Port Address Translation" box.

When doing so, make sure to choose the correct interface. The first choice here is Fast Ethernet 0/0, but that's the inside interface.

I simply clicked on the drop-down box and chose Fast Ethernet 0/1.

Finally, SDM shows you a summary of what you've chosen. Note the PAT inside interface is Fast Ethernet 0/0 and the outside interface is Fast 0/1, just what we want.

By clicking "Finish" at the bottom of the screen, you'll see a Command Delivery Status window that verifies the configuration has been written to the router. Note that it takes 13 commands to configure what we've chosen!

SDM verifies that FastEthernet 0/1 has been configured with an IP address of 172.20.21.1 and that the interface is the outside NAT interface.

This all looks good, but we better test it! Let's revisit the network topology:

Let's send a ping from the router to the web server to verify connectivity, and then check the NAT translation table.
RouterA#ping 172.20.21.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.20.21.254, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms RouterA#show ip nat translation < nothing shows up and we're taken back to the prompt > RouterA#

When you run a show command and you get nothing in return, that means there's nothing to show you. In this case, there have been no NAT translations. Why? Because we sent the ping from the router, and by

default the source IP address of the ping will be the exit interface's IP address. The source IP address of the ping from the router is 172.20.21.1, and that address requires no translation. To truly test PAT, we need to do one of two things:

Send an extended ping from the router and specify a source IP address for the ping of 10.1.1.11 Go to the PC and send a ping from there

Since it's the PC that needs connectivity to the web server, let's send a ping from the PC to that server and then check the NAT translation table.
C:\>ping 172.20.21.254 Pinging 172.20.21.254 with 32 bytes of data: Reply Reply Reply Reply from from from from 172.20.21.254: 172.20.21.254: 172.20.21.254: 172.20.21.254: bytes=32 bytes=32 bytes=32 bytes=32 time=4ms time=1ms time=1ms time=1ms TTL=127 TTL=127 TTL=127 TTL=127

The ping from the PC is successful. Let's check the translation table:
RouterA#show ip nat translation Pro Inside global Inside local Outside local Outside global icmp 172.20.21.1:512 10.1.1.1:512 172.20.21.254:512 172.20.21.254:512

Not all NAT tables list the protocol, but this one does, and you can see that it's an ICMP translation since that's what ping packets are. You can see the port translation as well, and the inside global address of 172.20.21.1 is the PAT interface on the router! That's just what we expected to see. Other WAN Technologies What follows is strictly an overview of some other WAN communication methods, and with ATM, it's really an overview! Configuration of ATM is far beyond the scope of the CCENT and CCNA exams, but it's a good idea to know the basics. The Asynchronous Transfer Mode (ATM) is unique in that it does not handle frames, as Frame Relay does. ATM places data into cells, and all ATM cells are exactly the same size, 53 bytes - 48 bytes of data and a 5byte header. Remember the Frame Relay switches that made up the Frame Relay cloud? ATM works along the same lines in that the service provider maintains ATM switches. ATM networks are much faster than Frame Relay networks, but are more expensive to build and maintain. That includes the need for specialized hardware. You can't just sit down and configure ATM on a Cisco serial interface as you could Frame Relay you'll need special interfaces to use ATM. Some ATM documentation says that ATM is a packet-switching service like Frame Relay, and technically that's true, but more commonly you'll

hear ATM referred to as cell-switching. After all, that's what ATM switches! Modems On the other end of the speed spectrum, we've got modems - and yes, they're still out there! In the previous CSU/DSU illustrations, a modem could and sometimes does take the place of the CSU/DSU. The word "modem" actually comes from the two operations they carry out:

Modulation, the process of translating digital signals into analog signals that can be carried over a phone line Demodulation, the process of translating those analog signals back into digital signals that the receiving device can understand

In this simple network setup, there are two points where such a translation is needed.

When data leaves Host A, it's in digital format - a stream of ones and zeroes. Remember, it's all ones and zeroes!

Why do we need the modem? We're going to use a telephone line to get this signal to Host B, and the telco's phone lines don't know what to do witha digital signal. That signal's got to be translated into an analog signal, and that's part of what the modem does.

When the analog signal arrives at the destination, the modem now has to demodulate the signal by translating it back to the original digital signal. This is necessary because Host B has no idea how to handle an analog signal. Host B only understands - say it with me - ones and zeroes!

The two real drawbacks of modems are:

They're not as fast as other methods They tie up the phone line, and other calls cannot be made while the modem is using the line

And what are those other methods? Glad you asked! Many of you downloaded this course on a Digital Subscriber Line (DSL) connection. Or an ADSL line. Or an SDSL line. Or... Well, you get the idea. There are multipleDSL variations, and here's a look at just a few. Asymmetrical DSL works under the assumption that the user will download more information than they send, and for the average Internet user, that's a safe assumption.The connection speed from the provider to the user is going to be 3 - 4 times faster than the speed from the user to the provider. A typical ADSL connection of 512 kbps will give the user384kbps download capabilities, but only 128kbps uploading capability. ADSL allows a telephone call and internet access simultaneously.

ADSL uses several different modulation methods, but the most wellknown is G.lite (also known as G.922.2), which requires no splitter at the customer location. The customer simply hooks up a G.lite modem in the same way an old-fashioned analog modem would be installed. G.lite's limitation is speed - where standard ADSL can offer 8 MBPS download speed and 1.5 upload speed, G.lite's maximum capability is 1.5 MBPS downloading and 512 KBPS uploading. The key is that while G.lite is slower than true ADSL, it's still faster than the dialup options available to today's home users. The distance limitation of ADSL must be taken into account as well.

Officially, there's an 18,000-foot limitation on ADSL services, but most ISPs put a lower limit on ADSL to avoidpoor quality servicefor those near the end of the cable. Of course, that limitation is for data transmission, not voice. Sincewe have asymmetric DSL, it makes sense that we'd have symmetric DSL (SDSL) as well. The term "symmetric" refers to the fact that the sending and receiving speed are the same. The drawback is that the phone cannot be used while SDSL is in use.

Two less-common DSL flavors: Very High Bit-Rate DSL (VDSL) has the capability to deliver speed up to 52 MBPS.That's am amazing speed to deliver over copper wire, but there's a drawback - VDSLover copper has a maximum distance of 4000 feet.As morefiber-optic cable isinstalled by the telephone companies, VDSL is becoming available in more communities as the distance issue is resolved by the use of fiber. Rate-Adaptive DSL (RADSL) is just what it sounds like - the software calculates the maximum download and upload speeds on the customer's preexisting phone line and dynamically adjusts those rates.

Recommended Video Viewing: CCNA Video Boot Camp on OSPF (Hosted By Udemy.com - free course) http://www.udemy.com/ccna-boot-camp/ My Full CCNA Video Boot Camp - Over 22 Hours Of Video - And A Secret Discount Link! See the course here, and watch an hour of the OSPF section for free! http://www.udemy.com/ccna-on-demand-video-boot-camp/

Get a $10 discount by enrolling at the following link - it's like getting this ebook for free! http://www.thebryantadvantage.com/CCNAStudyPackageUpgrade.htm Frame Relay Video Practice Exam: http://www.youtube.com/watch?v=HDZM5_7Ik24 Direct Connections and PPP/HDLC Video Practice Exam: http://www.youtube.com/watch?v=i07ArRQJV9U PPP and HDLC Video Practice Exam (early video, not the best resolution, but it's well worth watching and you can't beat the cost!) http://www.youtube.com/watch?v=W14hIQ55bGc Main YouTube Channel page - subscribe today and never miss a new video! http://www.youtube.com/user/ccie12933

Back To Index

Copyright 2012 The Bryant Advantage. All Rights Reserved.