I’ve been trying to figure out if Cisco is offering something similar to the “comeback” promotion they were offering for Cisco certified folks who have let their certs lapse.

So I called Vue yesterday to find out. I was happy to hear that they are indeed offering a similar promotion called “Second Chance”.

hi all,
I’m back! sorta.. I’ve been waiting to see if anyone was able to find any new info on this “second shot” thing. Unfortunately, the graces didn’t come. But like my wife always tells me, when she notices that I don’t particularly enjoy the meal she just made (yeah, believe it or not my superwoman has bad days too! ), “If you want something done a certain way, do it yourself.” LOL

So I finally called PearsonVue to find out what the dealio. As it turns out, the “comeback” promotion is indeed targeted towards those who have let their certification lapse.

But don’t fret my little bebes, the nice lady on the other line did mention that there is also a “Second Chance” promotion for those taking any Cisco test the first time. She didn’t know the actual web page to direct me to but doing a little reverse-engineering (or not) of the http:// vue.com/cisco/comeback page being thrown around in the last few posts, I was able to get to http://vue.com/cisco/secondchance/ and there it was.

The only discrepancy from the info on that page and what she told me is how to re-schedule. On that page it said “Free exams may only be scheduled via the web.” but according to her I have to call them directly and give them the magic word “second chance”. To save you the extra leg work, the number is (877) 404-3926.

If anyone received a different (or more thorough) explanation, please do share. Anyhow, now I’m considering moving my test date one or two weeks earlier.

Click here to find the complete discussion.

I’m really tempted to move my test date up a week or two from my original scheduled exam on 6/28. My thinking is, there’s nothing to lose if I take it earlier and fail. Then I can retake it again on the original date and I would that much “informed” because the former would have served as a practice test. And if I happened to pass the first, even the better. Hmmm… Maybe.

Cone Zone… This page is currently undergoing cosmetic reconstruction as I’m experimenting with the best layout for the contents. I didn’t like the “squished” format that the previous template (WordPress theme: Digg) limited me too. So far this is the best layout/design that I like, given the limited options I have with a free account.

I like the fact that the main column expands as you expand your browser. The previous one made the main column look too skinny when viewing on a fully expanded browser; giving me the impression of wasted space. This new one fills up all the spaces as you drag the browser size back and forth.

It’s kinda like how CIDR helps prevent the wasting of IP addresses by allocating just the right amount of addresses to fill the need.

Also, the spacing of the texts seems just right for my eyes. The only drawback I’ve seen so far is that it screws up some of the text alignment from how I’d like to see them laid out. It also mis-aligns my images. Also, I’m just not sure about the default size of the fonts. I’d like to see it a little bit bigger so I don’t have to squint when reading it. Maybe this one will let me tinker with the style sheet. We’ll see. I like it so far.

Static NAT Configuration

1. Configure interfaces on the inside part of the network using the ip nat inside interface subcommand.
2. Configure interfaces on the outside part of the network using the ip nat outside interface subcommand.
3. Configure stati mapping between the inside local address and the inside global address using the ip nat inside source static inside-local inside-global global configuratin command.

interface Ethernet0/0
ip address 10.1.1.3 255.255.255.0
ip nat inside

interface Serial0/0
ip address 200.1.1.251 255.255.255.0
ip nat outside

ip nat inside source static 10.1.1.2 200.1.1.2
ip nat inside source static 10.1.1.1 200.1.1.1

• The ip nat inside and ip nat outside interface subcommands tells the router which interface is in the “inside” part of the network and which one is “outside”.
• The ip nat inside source static command creates the mapping.
  • The keyword inside refers to hosts inside the network needs the mapping
  • The keyword source tells NAT to translate the source IP of packets hitting the inside interface.
  • The keyword static means the address entered in the command are to be statically created on the NAT table and will not be removed due to timeout expiration.
• In the example configuration above, there are two ip nat inside… commands because there are two hosts being mapped to two separate inside global addresses.

Dynamic NAT Configuration

• Dynamic NAT still requires you to configure the inside and outside interfaces, just like we do for static NAT.
• It uses IP ACLs to identify which private hosts need to be translated.
• It needs to create a pool of registered public IP addresses to allocate to the inside local addresses.

Guide to configuration:

1. Configure the ip nat inside interface.
2. Configure the ip nat outside interface.
3. Create the IP ACL to match packets coming into the inside interfaces for which NAT should be performed
4. Configure the pool of publicly registered IP addresses using the global configuration command:
   • ip nat pool name first-address last-address netmask subnet-mask
5. Enable dynamic NAT by referencing the ACL and pool with the global configuration command:
   • ip nat inside source list acl-number pool pool-name

interface Ethernet0/0
ip address 10.1.1.3 255.255.255.0
ip nat inside

interface Serial0/0
ip address 200.1.1.251 255.255.255.0
ip nat outside

ip nat pool fred 200.1.1.1 200.1.1.2 netmask 255.255.255.252
ip nat inside source list 1 pool fred

access-list 1 permit 10.1.1.2
access-list 1 permit 10.1.1.1

• In the above example, the ip nat pool command gives the name “fred” to the pool. It then defines the first and last ip address ranges, followed by the subnet mask – to check and make sure the address range is within the allowed range of numbers dictated by the subnet mask.
• The dynamic version of the ip nat inside source command references the ACL (list 1 command) that defines what inside local IP addresses is permitted for NATting and what pool (pool fred command) of numbers to use when matching inside local addresses to inside global addresses.
• Helpful troubleshooting and verification commands:
  • show ip nat statistics
  • show ip nat translations

NAT Overload (PAT) Configuration

• There are two variations of PAT configuration:
  1. Using a pool of inside global addresses for mapping the local hosts
  2. Using only one inside global IP address.
• Configuring PAT using a NAT pool:
  1. Use the same step as the dynamic NAT configuration, but appending the keyword overload at the end of the ip inside source list global command. For example:
     • ip nat inside source list 1 pool fred overload
• Configuring PAT using an an interface IP address as the sole inside global IP address:
  1. Configure the ip nat inside interface.
  2. Configure the ip nat outside interface.
  3. Configure the ACL to match the packets you want permitted to be NATted
  4. Configure the global configuration command:
     • ip nat source list acl-number interface interface-name/number overload

interface Ethernet 0/0
ip address 10.1.1.3 255.255.255.0
ip nat inside

interface Serial0/0
ip address 200.1.1.249 255.255.255.252
ip nat outside

ip nat inside source list 1 interface Serial0/0 overload

access-list 1 permit 10.1.1.2
access-list 1 permit 10.1.1.1

• The only thing that needs to be discussed in the example above is the ip nat inside source command. The list 1 parameter means the same thing as dynamic configuration – that is, it references the IP ACL previously defined in the configuration.
• interface serial 0/0 defines the only inside global IP address (the address configured on s0/0) that would be used to represent all the outgoing inside local addresses
• The overload parameter, the important part of this type of configuration, allows the router to perform the overload function.

Network Address Translation

• NAT is defined in RFC 3022. SImply put, it allows hosts with private IP addresses (RFC 1918 ) to be able to communicate with other hosts on the Internet. NAT “translates” these private addresses into a valid registered IP address that can communicate with the Internet. There is a lot more to be defined but for the purposes if CCNA, this will do for now.
• To setup NAT, you need a router the performs the NAT functions. When the packet from the private enterprise hits the NAT router, NAT changes the packet’s source IP address to a globally unique Internet address as it leaves the organization.
• NAT is just one of several solutions created for the purpose of preserving the IPv4 address space – to slow down the inevitable depletion of the number of available publicly assignable addresses. In brief, the following summarizes some of the other solutions:
  • Classless Interdomain Routing (CIDR) - This allows ISPs to reduce the amount of wasted IP addresses by assigning only a portion of a network number instead of assigning a whole network. CIDR’s main goals are:
    • Route aggregation for shorter routing tables – allows for easier route aggregation in the Internet. Instead of listing a whole bunch of classful networks on a router’s routing table, route aggregation can reduce the number of routes processed.
    • IPv4 Address Conservation - CIDR gives ISPs the ability to assign only a subset of a Class of network to customers. Example, instead of assigning the customer 198.8.3.16/30, instead of assigning the whole 198.8.3.0/24 network.
  • Private Addressing – RFC 1918, Address Allocation for Private Numbers defines a subset of network numbers that will never be assigned to the public as a registered network number. Any organization can use this subset of private addresses and implement it on their network. These numbers cannot be advertised to the Internet. But with the use of NAT, this can be made possible.
  • IPv6 – The ultimate goal is to implement this new addressing scheme. IPv6 uses a 128-bit address versus the 32-bit address used in IPv4. This will give us an address space of about 10³⁸ addresses.
  • NAT – this is of course what this whole chapter is about.

Terminologies

• Inside Local – The actual IP address assigned to the host of an enterprise network.
• Inside Global – Represents the inside host, within the enterprise, using the public address assigned by the ISP. The inside global IP address will be used to represent the private IP address of the host coming from the inside to the outside.
• Outside Local – The IP address that represent the host from outside the network
• Outside Global – Represents the outside host with a public IP address that can be used in the public Internett

The following diagrams help to illustrate the concepts and terminologies as pertains to NAT.

source:http://www.cisco.com/warp/public/556/8.html

Following is a summary of the main types of NAT

Static NAT

• Static NAT configures a one-to-one mapping of the private IP address to the publicly registered IP address. That is, the inside local address is statically mapped to the inside global address that represents it to the public.
• For instance, a company with assigned network 200.1.1.0 can use any valid IP (200.1.1.1, for example) to map to a private host on the enterprise (to 10.1.1.1 for example). When the host 10.1.1.1 hits the NAT router (with Source Address (SA) 10.1.1.1) to go out to the Internet, the router changes the SA to 200.1.1.1, which is a public address capable of routing through the internet.
• If you want a different host to go out to the internet as well, you’ll have to configure a second static one-to-one mapping. For example, 10.1.1.2 to 200.1.1.2.

Dynamic NAT

• Dynamic NAT is similar to Static Nat in that the NAT router creates a one-to-one mapping between the inside local and the inside global addresses. The difference is the mapping happens dynamically.
• To create the mapping, you have to configure a pool of inside global (registered IP) addresses that can be used to map existing inside local (private) addresses. To determine which inside local addresses will be allowed to be NATted, an IP access-list has to be configured to filter what can be translated and what doesn’t.
• As the host passes through the NAT router, the router maps the inside local address to an available address from the pool of inside global addresses.
  • The number of addresses that can be mapped depends on the number of inside global addresses are configured in the pool.
  • If more packet arrives than there are available inside global addresses in the pool, the packet gets discarded.
  • A timeout value can be configured to tell the router to remove a dynamic entry if it hasn’t translated any packet for the amount of timeout period.
• The dynamic mapping can be manually cleared using the clear ip translation command.

NAT Overload and PAT

• NAT Overload, also called Port Address Translation (PAT) allows NAT to map more private addresses with fewer public IP addresses to map to. This is done by the use of port (as in TCP/UDP) mapping.
• To create a dynamic mapping, PAT selects an inside global IP address to map with the inside local address, and additionally, it selects a unique port number to use with that address. Every unique combination of local inside addresses and port numbers are stored in a table and paired with the inside global address-port number combination.

Translating Overlapping Addresses

• Another variation of NAT allows the translation of both the source and destination addresses. Where this would be utilized is in a network setup where there are two networks that have overlapping IP addresses.
• This scenario happens when one network uses an IP addressing scheme that is registered to someone else. In other words, they are inappropriately using a registered IP address. When this is the case, the two networks will not be able to forward traffic to each other because every time they try to send a packet destined to an address in the same network, the packet will never be sent to the gateway to leave the network because the addressing assumes that the destination address is in the same network.
• Refer to the example given with the diagram below:
  • Host 170.1.1.10 in Company A tries to send a packet to a server outside its network with the destination IP of 170.1.1.1.
  • Without NAT, the packet obviously stays in the same network and not get forwarded to the gateway. The packet might go to another host in the network that has the IP address 170.1.1.1 or if it doesn’t exist, may just be discarded.
  • NAT can solve this problem by changing the destination address (as well as the source address as it passes the NAT router). This new destination address represents the local address of the server on the other network. Technically this is called the outside local address.
  • As it passes the NAT router, the source address is mapped to the inside global IP address (200.1.1.1) and the destination is also changed to the publicly registered IP address of the server on the other side. This is called the outside global address.
  • The NAT configuration includes a static mapping between the real IP address (outside global), 170.1.1.1 and the private IP address (outside local) used to represent it inside the private network (192.128.1.1)
  • This setup requires the use of a DNS server. When the client on the left network requests to reach cisco.com, the DNS server modifies its response as it passes the IP information to the requestor. As it passes the NAT router, NAT changes the DNS reply so that the requestor thinks that www.cisco.com’s IP is 192.168.1.1.

Well, the game got the best of me again last night. I promised myself before I left work that I’m only going to watch one quarter of the Lakers-Spurs game last night. I should’ve known better that that’s a promise I should never make because I know well enough it’s a promise I can’t keep.

Good thing = Lakers won by 2 points. (leads series 3-1)
Bad thing = I only put in 30 minutes of studying (a mindless session of CBT) before crashing to bed with a headache from the tenseful last 2 minutes the Lakers put me through.

But I’m still on track, so there.

I’ve finally decided to change the schedule for my last few chapter readings. In my study plan I’m supposed to be in the middle of chapter 14 right now. But I completed that over the Memorial day weekend. I’ve also finished chapter 15 and my first pass on chapter 16. Hopefully I can get done with the chapter 16 re-do tonight. I’m giving myself until tomorrow afteroon to finish the chapter 16 re-read/re-view/notes. Then from then until Sat, May 31st, I plan to go over IPv6. Not a lot of time but if I keep to the new schedule, I’ll have the rest of June to finish the extensive review.

By the way, I haven’t done any kind of labs on the last few chapters because of the squeezed timeframe I’ve setup for this last week. Of all the things, Frame Relay should be the one that could give me a lot of fun labbing up. I’ll get to it during my overall review phase.

VPN Fundamentals

VPNs try to provide secure features similar to what a leased line can do. For instance, a router on one end of a leased line knows with confidence the identity of the device on the other of the link.

Some of these feature that they provide are:

• Privacy – preventing anyone from the Internet from capturing transmitted data and reading them.
• Authentication – verfying that the sender of the packet is legitimate and not an impostor.
• Data Integrity – The packet that was sent arrives as intended and not altered.
• Antireplay – Prevents someone on the Internet to capture a packet, change it, and resend it to appear to be legitimate.

VPN tunnel
Two devices near the edge of the Internet are set up to create VPN connection. These devices add headers to the original packet with fields that allow the VPN devices to perform all the functions. The VPN devices also encrypt the original IP packet so that the contents of the original packets are undecipherable to anyone who captures it.

Types of VPN:

• Intranet – Connects two sites of the same organization
• Extranet – Connects two partner sites that are not necessarily the same organization.
• Access – Connects individual users to the enterprise users, typically mobile or home users.

Building a VPN network requires several devices that understand VPN standards and protocols at each site. Devices include software and hardware such as:

• Routers – perform VPN functions in addition to routing. Add-on cards can also help with more powerful encryption
• Adaptive Security Appliances (ASA) – Cisco appliance that does a lot of functions, including VPN, firewall, endpoint for VPN tunnel, etc.
• PIX firewalls – firewall and VPN. Replaced by ASA
• VPN Concentrators – act as endpoint of a VPN tunnel. Replaced by ASA
• VPN client – Client installed on a laptop to perform VPN functions.

IPsec VPN

IPsec is an IP networks’ security architecture or framework. It is defined by RFC 4301, Security Architecture for the Internet Protocol, more generally called IP security, or IPsec. It defines a set of functions such encryption and authentication.

As an architecture, it allows changes and additions to it over time as improvements in security are made.

The following components of IPsec are summarized in the next bullet points:

• IPsec Encryption
  • Uses mathematical algorithms to meet certain criteria. These are:
    • To hide (encrypt) the data
    • Re-create (decrypt) the original data from the encrypted version.
  • You will need an encryption key (a password) to decrypt the data. Also known as session key, shared key, or shared session key.
  • Even if an attacker is able to capture and decrypt one packet, he’ll have to decrypt the other packets that completes it to make any sense of the data.
  • A sample packet:
    

    IP Header

    VPN Header

    Encrypted Data

  • Encryption Algorithms:
    • Data Encryption Standard (DES) – 56-bit in length. Older and less secure than current options available.
    • Triple DES (3DES) – Key length is 56×3 bits. It applies three different 56-bit DES keys in succession, improving DES.
    • Advanced Encryption Standard (AES) – 128-bit or 256-bit in length. Current best practice, with strong encryption and less computation than 3DES.
• IPsec Key Exchange
  • To make the encryption work between to devices there needs to be some kind of exchange of common key (a shared common key value, also called symmetric keys) or password between the two. The inherent problem with that is how to send both keys to each other without it being intercepted over the line as clear text.
  • One solution is to use Pre-Shared Keys (PSK) – manually configuring the values on both devices. The common way to do it is calling the engineer on the other site and giving him the key to be configured, or sending it through the mail. The problem is that since it is manually configured, it is almost always never changed.
  • In a move to find a more secure process of using a dynamic key exchange, RFC 4306, Internet Key Exchange (IKE) calls for the use of a process called Diffie-Hellman (DH) key exchange – named after its inventors. It is an algorithm that allows the devices to make up and exchange keys securely. This key can then be used to encrypt subsequent data.
  • There are several options that can be configured for DH key exchange but they all depend on the length of the keys. The longer the encryption key that needs to be exchanged, the longer the DH key needs to be.
    • DH-1 is 768-bit long
    • DH-2 is 1024-bit long
    • DH-5 is 1536-bit long
• IPsec Authentication and Message Integrity
  • Authentication is generally a process by which a receiving VPN device can confirm that a received packet is really sent by a trusted VPN peer.
  • Message integrity confirms that the message received is really the original message sent.
  • Message Integrity checks are performed by the Authentication Header (AH) protocol with the use of a shared (symmetric) key concept. It is similar to the encryption process, except it uses a hash function, where the key is not actually sent over the Internet.
    • The hash process, called Hash-based Message Authentication Code (HMAC), calculates a hash value and sends the result in the VPN header
    • The receiver receives the hash and recomputes it (using the same key as the sender) and compares the result with the value listed in the VPN header.
    • The integrity check functions with HMAC typically use a secret key that needs to be at least twice as long as the encryption key that encrypts the message. For example, MD5 standard that uses a 128-bit key can support VPNs that use the 56-bit encryption key length.
  • The authentication process uses a public/private key concept similar to DH key exchange.
    • The idea is that the sender uses a private key to encrypt a value and the sender’s public key is used to decrypt it.
    • The sender calculates a value using the sender’s private key. The sender puts that value in the VPN header. The receiver then uses the sender’s public key to decrypt the transmitted value.
    • Specific protocols and tools available for IPsec authentication and message integrity
      • Message Integrity
        • HMAC-MD5 – uses 128-bit shared key, generating a 128-bit hash value
        • HMAC-SHA – HMAC-Secure Hash Algorithm defines different key sizes (for example, SHA-1[160], SHA-256[256], and SHA-512[512]) to support different encryption key sizes. This is considered better than MD5 but requires more compute time.
      • Authentication
        • Pre-shared Keys – Both VPN devices must be pre-configured with the same secret key
        • Digital signatures – aka Rivest, Shamir, and Adelman (RSA) signatures. The sender encrypts a value with its private key; the receiver decrypts with the sender’s public key and compares with the value listed by the sender in the header.

The ESP and AH Security Protocols

• There are two types of VPN headers that stores information for various VPN functions:
  • Encapsulating Security Payload (ESP) – Defines rules for performing the main four functions for VPN: supports authentication (weak), message integrity, encryption, and antireplay.
  • IP Authentication Header (AH) – supports strong authentication and message integrity.

IPsec Implementation Consideration

• IPsec VPNs provide secure connection through the Internet as if they are connected directly to the enterprise LAN. Site-to-site VPNs allow the users to see connect to applications and resources in the company as if it were local.
• Remote access VPNs allow the users to do the same thing as site-to-site VPN users. However the users require the use of a VPN client installed on their local machine.
• Cisco Easy VPN allows the installation and configuration of VPNs easier. A Cisco Easy VPN server, an ASA for example, is installed to dynamically inform the remote site devices as to their IPsec VPN configurations. The devices (routers or laptops with VPN clients) act as Easy VPN clients, connecting to the Easy VPN server and downloading the configuration settings.

SSL VPNs

• SSL, Secure Socket Layer, allows common browser to send data across the Internet securely. A similar standard called Transport Layer Security (TLS) does similar things
• SSL uses port 443. Data sent between the browser and the server is encrypted, the user is authenticated, then HTTP messages are sent over the SSL connection.
• Web VPN – similar to IPsec VPN, but typically only allows web traffic instead of general traffic to go through.
  • To use Web VPN, the user connects to a Cisco Web VPN server. The Web VPN server acts as a web server. The web page presented to the user contains a list of applications available to the user.
  • The Web VPN server can be implemented by various devices. For example, an ASA. The connection uses SSL.
• The drawback is that Web VPN needs to use a web browser to use an application. To circumvent this limitation, the users can load an SSL-based thin client that could connect to hte Web VPN and the Web VPN would simply pass traffic from the PC to the local LAN.

Some tips on what to look for when troubleshooting Frame Relay problems:

• LMI types must match or be autosensed.
• Layer 3 mapping has been learned or statically mapped.
• The right DLCI values have been associated with each subinterface.

Suggested Frame Relay Troubleshooting Process

Typically, the first step that should undertaken when experiencing problems on the network is to issue a ping command. First, try pinging a host on one LAN using and end device from another LAN. If that fails, ping from one router to the other router’s Frame Relay IP. If that works but the end users fail, the problem might lie on some Layer 3 configuration or proper functionality. If the router to router ping fails, there could be a problem on the Frame Relay itself.

Here’s a few steps to undertake:

1. Check Layer 1 problems on the access link (link between the routers and their corresponding Frame Relay switch)
2. Check Layer 2 problems. Most commonly, it is an encapsulation or LMI problem
3. Check for PVC problems based on the PVC status and subinterface status
4. Check for Layer 2/3 problems with both static and dynamic (Inverse ARP) mapping.
5. Check for Layer 2/3 problems related to a mismatch of end-to-end encapsulation (cisco or ietf)
6. Check for Layer 3 problems, such as mismatched subnets

Layer 1 Issues on the Access Link

• A Frame Relay access link is merely a leased line between a router and the Frame Relay switch from a Layer 1 perspective.
• Layer 1 issues will usually be indicated by a “down” interface line status.
• For Layer 1 troubleshooting, see Chapter 12 of the CCNA/ICND2 OECG, page 446

Layer 2 Issues on the Access Link

• If the interface is in “up/down”, the link typically has problems between the router and the FR switch.
• Problem is either on the encapsulation command or the Frame Relay LMI
• If the encapsulation frame-relay command is omitted on the serial interface of a router, while the physical interface is working, the interface goes on an “up/down” state.
  • To see the configuration for the encapsulation type, use the show interfaces command.
• LMI problems will also put the interface status on an up/down state.
  • To summarize again, LMI status messages has two main purposes:
    • DCE (FR switch) informs the DTE (router) about each VC’s DLCI and its status
    • To provide keepalive functions so that the DTE and DCE can easily tell when the access link can no longer pass traffic.
  • The normal purpose for the LMI keepalive function is to notice loss of messages received from the FR switch so that the router can bring down the interface that is problematic. This lets the router to choose an alternative route to pass data.
  • Configuration mistakes for LMI can also cause problems:
    • Disabling LMI on the router (using the no keepalive physical interface subcommand), but leaving LMI enabled on the switch, or vice versa.
    • Configuring mismatching LMI types on the router and the FR switch.
• Check both encapsulation and LMI configurations using the show frame-relay lmi command.
  • This will list output for interfaces that have the encapsulation frame-relay command
  • At the same time, you can also confirm if the encapsulation frame-relay command is appropriately configured on the right serial interfaces.
    • NOTE: DTEs receive Status Messages from DCEs and sends Status Inquiries to DCEs

PVC Problems and Status

In troubleshooting this area, we need to make sure that we find the correct DLCI of the PVC in question.

Follow the following list to determine the DLCI used to send frames to the failed destination:

• Using some show commands such as show interfaces and sh ip int brief, discover the ip address and mask of each Frame Relay interfaces and determine the connected subnets.
  • Anytime you ping the Frame Relay IP address of a neighboring router, the IP address should be in one of the subnets also connected to the local router.
  • To find the interface used on a local router when forwarding packets to the remote router, you just have to find that common connected subnet.
• Compare the ip address of the failed ping command to the interface with the same connected subnet
  • After finding the results of the show commands above, just find the interface on the local router with an IP address in the same subnet as the IP address of the neighboring router and note what interface it’s configured on.
• Use the command show frame-relay pvc to the discover the PVC assigned to that interface.
  • Once the interface/subinterface has been discovered on the previous steps, the show frame-relay pvc can tell you what DLCI is assigned to that interface.
• If more than one PVC is assigned to the interface, determine the PVC using show frame-relay map command.
  • This command can help discover the correct DLCI to IP address. Unfortunately, if the local router relies on Invers ARP to get its DLCI, it cannot learn the mapping information right now because it is the interface that is down – therefore it cannot learn. This is where outside documentation can be helpful
• PVC Status:
  • Active – PVC is currently useable. Learned through LMI status message
  • Inactive – PVC is down. Also learned through LMI status message
  • Static – Means DLCI is statically configured. If the LMI is disabled, the router doesn’t learn any information from the FR switch about PVC status. So the router lists all its configured DLCIs in the static state.
    • Implies that LMI is turned off.
    • The router can still send frames using those DLCIs but there is no way to tell if the frames can be delivered
  • Deleted – used when LMI is working but the switch’s LMI message does not mention anything about a particular DLCI value.
    • This state means that the router has configured the DLCI, but the switch has not
    • If the router has configurations for a DLCI (e.g frame-relay interface-dlci command), but the switch’s LMI message does not list the DLCI, the router lists that DLCI in a deleted state.
    • In real life, the deleted state may mean that the router or switch has been misconfigured, or that the Frame Relay switch has not yet been configured with the correct DLCI.
• Subinterface Status
  • Just like physical interfaces, they have line/protocol status.
  • However, they are virtual, thus their meanings are a bit different.
  • Frame Relay configs assocatiate one or more DLCIs with a subinterface using the following commands:
    • frame-relay interface-dlci
    • frame-relay map
  • IOS follows the following rules to determine status:
    • down/down – All the DLCIs associated wiht the subinterface are inactive or deleted, or the underlying physical interfaces is not in an up/up state.
    • up/up – at least one of the DLCIs associated wiht the subinterface is active or static.
  • Note that in a mulitipoint subinterface where one of the PVCs is inactive but another is “up and up”, IOS leaves the subinterface in an up/up state.

Checking for Layer 2/3 Problems: Frame Relay Mapping Issues

• On point-to-point subinterfaces:
  • Do not need Inverse ARP or static mapping, because IOS simply thinks that the subnet defined on the subinterface is reachable via the only DLCI on the subinterface.
  • the show frame-relay map command output still lists these subinterfaces, but with no next-hop ip address
• On physical interfaces and multipoint subinterfaces:
  • Need to use either Invers ARP or static mapping
  • The show frame-relay map command should show the remote router’s FR IP address and the local router’s local DLCI for each PVC associated with the inerface or subinterface
  • If using static mapping, the broadcast keyword is needed to support a routing protocol.

Checking for Layer 2/3 Problems Related to Encapsulation

• Make sure that the encapsulation used are matching.
• If one router is a Cisco router using cisco incapsulation, and the other router is a non-Cisco router, using ietf encapsulation, the ping may fail because of a mismatch.

Layer 3 Issues: Mismatched Subnet Number

• Confirm the IP addresses on each router, and the masks, and ensure that they connect to the same subnet.
• To confirm, use show ip interface brief and show interfaces commands

Some IOS default settings when configuring Frame Relay:

• LMI tyep is automatically sensed
• Encapsulation is Cisco (vs. IETF)
• DLCIs of the PVCs are learned via LMI status messages
• Inverse ARP is enabled

The most basic Frame Relay command that tells the routers to use Frame Relay dat-link protocols instead of the default HDLC:

#encapsulation frame-relay

If another router is not Cisco, you must use IETF encapsulation:

#encapsulation frame-relay ieft

The encapsulation command applies to all VCs on that interface.

If a change of LMI is necessary, configure the physical interface for the router as:

#frame-relay lmi-type ansi | q933a

Note: The LMI setting is a per-physical-interface setting, even if subinterfaces are used.

Frame Relay Address Mapping

• Frame Relay mapping “maps” a Layer 3 (IP) address and its corresponding Layer 2 (DLCI) address
• Inverse Arp
  • dynamically creates a mapping between the Layer 3 address and the Layer 2 address.
  • As soon as the LMI signals the VC is up, Inverse ARP learns the DLCI of its VCs, then it announces its own Layer 3 address.
  • To see the result of the inverse arp, use the following command to see the Frame Relay map table:

#show frame-relay map

• Static Frame Relay Mapping
  • Instead of using Inverse Arp, manually configuring static maps is possible:

#no frame-relay inverse-arp
#frame-relay map ip 199.1.1.2 52 broadcast

• • • The IP address 199.1.1.2 in the example is the IP address of the next-hop router
    • “52″ is the DLCI used to reach the router with the 199.1.1.2 ip address.
    • “broadcast” keyword allows the routers to send broadcasts or multicasts to neighboring router – for routing protocols such as RIP, OSPF, EIGRP, etc.
    • the “no frame-relay inverse arp” obviously means no frame-relay inverse arp!

Point-to-point Configuration

R1(config)#interface s0/0/0
R1(config-if)#encapsulation frame-relay

R1(config-if)#interface s0/0/0.1 point-to-point
R1(config-subif)#ip address 140.1.1.1 255.255.255.0
R1(config-subif)#frame-relay interface-dlci 52

R1(config-fr-dlci)#interface s0/0/0.2 point-to-point
R1(config-subif)#ip address 140.1.2.1 255.255.255.0
R1(config-subif)#frame-relay interface-dlci 53

R1(config-fr-dlci)#interface s0/0/0.3 point-to-point
R1(config-subif)#ip address 140.1.3.1 255.255.255.0
R1(config-subif)#frame-relay interface dlci 53

• The interface s0/0/0.1 point-to-point command creates logical subinterface number 1 under physical interface s0/0/0.
  • the subinterface numbers do not have to match on the router on the other end of the PVC, nor does the DLCI number.
• The frame-relay interface-dlci subinterface command tells the router which single DLCI is associated with that subinterface
  • associates the correct PVC with the subinterface
  • an alternative command to use in place of this is frame-relay map command. For example, frame-relay map ip 140.1.1.2 52 broadcast .
    • if frame-relay map command is used, Inverse ARP is disabled. Therefore the router on the other end of the VC will nor receive any Inverse ARP messages and may need to be configured with the frame-relay map command as well.

Global and Local Addressing (as pertains to the CCNA exam

• For three or more routers in a diagram, if it shows a main site with 3 PVCs, one to each remote site:
  • If only one DLCI is shown beside the main site router, it implies the use of global addressing.
  • If the diagram shows a DLCI for each PVC beside the main site router, it is using local DLCI
• If there are only 2 routers, you need to read into the question, answers, or any configuration.
  • On any given router, only local DLCI values are in the configuration or show commands.

Frame Relay Verification

• #show frame-relay pvc
  • lists useful management information such as:
    • packet counters for each VC
    • counters for FECN and BECN
    • shows PVC status
    • comparison of packets/bytes sent on one router vs. counters on packets received on the router on the other end of the VC.
• #show frame-relay map
  • lists mapping information:
    • for example, for fully meshed network in which the configuration did not use any subinterfaces, a Layer 3 address is listed with each DLCI
    • for instances where subinterfaces are used on a point-to-point network, there is no Layer 3 address shown.
      • subinterfaces require the use of frame-relay interface-dlci command.
      • Inverse ARP or static frame-relay map statements is needed only when more than two VCs terminate on the interface or subinterface, because those are instances in which confusion over which DLCI to use might occur.
• #debug frame-relay lmi
  • Lists information for the sending and receiving LMI inquiries.
  • The switch sends the status message.
  • The DTE (router) sends the status inquiry.
  • Cisco default is to send, and expect to receive theses status messages.
  • no keepalive command is used to disable the use of LMI status messages.
  • Unlike other interfaces, Cisco keepalive messages do not flow from router to router over Frame Relay. Instead, they are simply used to detect whether the router has connectivity to its local Frame Relay switch.

Hybrid Network

R1(config)#interface s0/0/0
R1(config-if)#encapsulation frame-relay

R1(config-if)#interface s0/0/0.1 multipoint
R1(config-subif)#ip address 140.1.1.1 255.255.255.0
R1(config-subif)#frame-relay interface-dlci 502
R1(config-subif)#frame-relay interface-dlci 503

R1(config-fr-dlci)#interface s0/0/0.2 point-to-point
R1(config-subif)#ip address 140.1.2.1 255.255.255.0
R1(config-subif)#frame-relay interface-dlci 504

R1(config-fr-dlci)#interface s0/0/0.3 point-to-point
R1(config-subif)#ip address 140.1.3.1 255.255.255.0
R1(config-subif)#frame-relay interface dlci 505

R2(config)#interface s0/0/0
R2(config-if)#encapsulation frame-relay

R2(config-if)#interface s0/0/0.1 multipoint
R2(config-subif)#ip address 140.1.1.2 255.255.255.0
R2(config-subif)#frame-relay interface-dlci 501
R2(config-subif)#frame-relay interface-dlci 503

R3(config)#interface s0/0/0
R3(config-if)#encapsulation frame-relay

R3(config-if)#interface s0/0/0.1 multipoint
R3(config-subif)#ip address 140.1.1.3 255.255.255.0
R3(config-subif)#frame-relay interface-dlci 501
R3(config-subif)#frame-relay interface-dlci 502

R4(config)#interface s0/0/0
R4(config-if)#encapsulation frame-relay

R4(config-if)#interface s0/0/0.1 point-to-point
R4(config-subif)#ip address 140.1.2.4 255.255.255.0
R4(config-subif)#frame-relay interface-dlci 501

R5(config)#interface s0/0/0
R5(config-if)#encapsulation frame-relay

R5(config-if)#interface s0/0/0.1 point-to-point
R5(config-subif)#ip address 140.1.3.5 255.255.255.0
R5(config-subif)#frame-relay interface-dlci 501

• Multipoint
  • Multipoint means there is more than one VC. That means you can send and receive to and from more than one VC on the subinterface.
  • Multipoint subinterfaces work best on a full mesh network.
  • Like point-to-point subinterfaces, you use the frame-relay interface-dlci x command to configure it.
  • On the diagram above, R1 configures s0/0/0.1 subinterface as a multipoint and lists DLCIs for R2 and R3.
    • Whereas on the point-to-point interfaces s0/0/0.2 and s0/0/0.3, only a single DLCI (for the one PVC connected to each) is configured.
    • In fact only one frame-relay interface-dlci command is allowed on a point-to-point subinterface because only one VC is allowed.
  • Mapping Statements:
    • Multipoint subinterfaces – non are required because Inverse ARP is enabled by default on multipoint subinterfaces.
    • Point-to-point – no mapping is ever needed because the only DLCI associated with the interface is statically configured with the frame-relay interface-dlci command.
  • show frame-relay map
    • The output of the show frame-relay map will show the mapping information learned by Inverse ARP on the multipoint subinterfaces.
    • The output will show Layer 3 information because there are more than one DLCI associated with a multipoint interface therefore the router needs the mapping information to match the next-hop IP address to the correct DLCI.

.. here I come. Woohoo! it looks like we might be getting an early start on the long weekend today. That’s exciting cause that means more study time for me. Hopefully we close shop by 1pm.

I was looking at my shhedule last night and seriously considering shortening the amount of time I allocate to finish the next few chapters – i.e. I’m thinking of allocating two days per chapter as opposed to the typical four days I’ve been alloting.

The reason is, I want to get all readings and notes done by the end of May and spend the whole month of June just reviewing (taking exam preps, re-watching CBTs, and re-viewing my comprehensive notes.) I also need to go back in depth to the switching part. It’s been two months since I’ve pore over the material and STP really kicked my burro.

Frame Relays is cool. Somehow it gives me a sense that I’m into the thick of things when I’m studying and looking over different Frame Relay diagrams or examining/interpreting show commands. Even though most of the materials are CCNA level, most of them do appear in the NP level. In fact, all of them do. It is also the fundamental basis for everything NP-level Frame Relay topics. Not that OSPF, EIGRp, IPv6 and the likes don’t matter in CCNP/CCIE. It’s just that somehow Frame Relay scratches the itch. Like, the feeling that I’m arriving.

I guess you can call that a milestone. It doesn’t matter if it really is or not. The important things is it feels like it for me. And that gives me the drive to keep going and see this whole thing through. It’s simple human behavior, really. Whatever gives a person a sense of accomplishment only gives him more fuel to keep going. That’s all I’m saying.

Anyway, this weekend should be good. My schedule this weekend somehow gives me the impression that I should take it easy. But I don’t feel like taking it easy. I might put in a good 4 hours on Sunday eventhough I marked it as “rest” day. If it feels like I’m exerting too much effort to get through my tasks on Sunday maybe I’ll scale back a little. But right now it doesnt feel like I will.

So tomorrow (Saturday) I plan to put in a good 8 hour day, 4 x 2-hour blocks. Sunday, I and the fam will go to Church early at 7am, sing my heart out to the Lord (did I mention I sing in a choir?), have a nice breakfast, put in 2 hours of studying in the morning, and another 2 at night. Monday, I plan to do another 8 hours.

Of course, If we go home early today, I can put in hour number 3 and 4 in addition to the 2 hours I did this morning.

The only thing I see getting in the way this weekend is… dun, dun, dun.. the playoffs. Lakers are playing tonight and on Sunday. That’s a good 3 hours each day. It does help that there’s nothing else good on TV so basketball is about the only thing I watch. Oh! and American Idol. That’s only because my wife “forces” me to watch. Even if I’m the only watching. Every now and then I practice karate too – in my head! But I digress…

Well, I’ve been excited about getting to the Frame Relay section of the book that I spent only one day on PPP chapter of the book and ran on over to this chapter. Don’t worry my bebes, I’lll go back to PPP for a more extensive review. In the meantime, let’s have some fun with Frame Relay.

I learned a little bit about the Frame Relay concepts in ICND1 but not enough to be able to set up a lab to tinker with. This time around I should be able to delve a little bit deeper (CCNA deep, not CCNP deep. At least not yet! ) into frame relay and setup a sweet lab setup. Is it just me or did i just hear an echo?

Notes to take note of, according to the book of Odom:

• In contrast to a point-to-point leased circuit, frame relay allows multiple remote routers to connect to each other using a single physical WAN circuit.
• The model is similar to LANs in which multiple devices can attach to each other like multiple computers can communicate with each other through a switch. But unlike LANs, data-link broadcasts does not happen over frame relay. That is frame relay networks are called nonbroadcast multiaccess (NBMA) networks.
• Routers are connected via leased line (called access link) and connected to the Frame Relay switch.
• Communication between the routers and the frame relay switch is governed by the LMI protocol.
• The routers on the customer side is called the DTE, while the frame relay switch is called the DCE.
• The logical connection between two DCEs is called a VC. The service provider provisions the details of the VC, and predefines the details. The predefined VCs are called permanent virtual circuits (PVC). 
• Each router on the frame relay uses the data-link connection identifier (DLCI) as it’s address; it identifies the VC over which the frame should travel. The frame relay header contains the correct DLCI.
• Important Terms:
  • Virtual Circuit (VC) – a logical concept that delivers data frames between DTEs based on packet switching technology, as opposed to circuit switched such as a leased physical circuit.
  • Permanent Virtual Circuit (PVC) - a predefined virtual circuit. As opposed to a switched virtual circuit, it is alwas connected. Therefore it provides a continuos and dedicated connection between two facilities. It is usually configured by the service provider
  • Switched Virtual Circuit (SVC) – a VC that is set-up on a per-call basis and connection terminates when it is done.
  • Data Terminal Equipment (DTE) – an equipment that usually sits on the customers site and connects to the frame relay service. It converts received signals to useable data. A router or modem would be considered a DTE.
  • Data Communications Equipment (DCE) – the device on the opposite end of the DTE. They normally sit on the service provider’s side and it is the device the usually provides the “clocking” signal where the DTE synchronizes it’s signal with.
  • Access Link – the leased line between a DTE and DCE
  • Access Rate – the clock speed of the access link. the physical line speed of the interface connecting to the frame relay. Example, access rate = 1.544 Mbps
  • Committed Information Rate (CIR) - also called the guaranteed rate, is the average bandwidth that the service provider sets and guarantees for the VC. Example, CIR = 128 kbps
  • Data-link Connection Identifier (DLCI) – the address used to identify a VC.
  • Nonbroadcast Multiaccess (NBMA) – a network where broadcasts do not occur, but more than two devices can be connected
  • LMI – Local Management Interface is a signaling standard used between routers and frame relay switches. Communication takes place between a router and the first frame relay switch it’s connected to. Information about keepalives, global addressing, IP Multicast and the status of virtual circuits is commonly exchanged using LMI. 
    • There are three standards for LMI: ANSI’s Annex D standard, T1.617; ITU-T’s Q.933 Annex A standard; and the “Gang of Four” standard, named for the four companies that developed it: Cisco, DEC, StrataCom and NorTel (Northern Telecom). (source: wikipedia)
  • Link Access Procedure Bearer Service (LAPF) – provides a framing for the Frame Relay header and trailer.
• Full Mesh Frame Relay – each pair of sites is configured with PVCs
• Partial Mesh - not all pairs have connected PVC. Typically when one remore router does not need to connect to another remote router becuase it only needs to connect to the main site.
  • an advantage of partial mesh is it’s cheaper; less VC to pay. The disadvantage is if the two remote routers need to exhance info, they have to go through the main site and have the info forwarded from there.
• LMI vs Encapsulation
  • LMI is between the DTE and DCE. Encapsulation is between DTE and another DTE.
  • Encapsulation defines the headers used by the DTE to communicate with another DTE
  • The switch and DTE care about using the same LMI. The switch does not care about the encapsulation
  • The endpoint routers (DTE) care about the encapsulation
• Important LMI message for CCNA-passing purposes:
  • LMI Status Inquiry Message. The status message perform two key functions:
    • Perfrom keepalive function between the DTE and DCE. No keep alive message means no link good. Might wanna check access link from problems then.
    • Tells you the status of a PVC; whether active or inactive.
• Three LMI protocol options:
  • Cisco
  • ITU
  • ANSI
• Each LMI option is different and incompatible. Just make sure DTE and DCE are using the same LMI standard and LMI is a happy camper and will provide good service with no extra charge.

• Link Access Procedure Frame Bearer Service (LAPF) specification, ITU Q.922-A defines the header and trailer for the Frame Relay encapsulation of Layer 3 packets. It provides error detection with an FCS in the trailer, as well as the DLCI, DE, FECN, and BECN fields in the header. New terms to be defined later.
• LAPF header and trailer does not have a protocol type field needed to define the type of packet contained in the frame. Therefore, DTEs cannot support multiprotocol traffic if the Frame Relay is using only the LAPF header.
• Two solutions to compensate for lack of Protocol Type field:
  • Cisco (and 3 other companies) created an additional header, which comes between the LAPF header and the Layer 3 packet. It includes a 2-byte Protocol Type field, with values similar to Cisco’s HDLC.
  • Multiprotocol Interfonnect over Frame Relay (RFC 1490, obsoleted by RFC 2427) was written to ensure multivendor interoperability between Frame Relay and DTEs. The new header is also placed between the LAPF header and the Layer 3 packet, which includes the Protocol type field including other options.
• Frame Relay switches ignore these two types of encapsulation. In other words, switches don’t care about the encapsulation and the DTEs on each side do have to agree on the encapsulation.

• The DLCI is the Frame Relay address.
• A Frame Relay header has a single DLCI field, in contrast to Ethernet that contains both a Source and Destination fields.

Local vs Global Addressing

• Local Addressing pertains to the fact that DLCIs are locally significant, meaning that the addresses need to be unique only on the local access link. 
  • Said another way: a single access link cannot use the same DLCI to represent multimple VCs on the same access link
• Frame Relay Global Addressing - a way of addressing to make it look like a LAN addressing concept.
  • It resembles addressing used in Layer 3 routers
  • With global addressing, a fixed DLCI is assigned to a specific DTE. A sending router, then, inserts the DLCI value of the destination router into its header (instead of using a DLCI value from the local pool of unused numbers).
  • When the Frame Relay switches receive the header, it changes the value of the DLCI with the DLCI of the sending router.

The sender treats the DLCI field as a destination address, using the destination’s global DLCI in the header

The receiver thinks of the DLCI field as the source address, becuase it contains the global DLCI of the frame’s sender.

Network Layer Concerns with Frame Relay

• Three diferrent options for assigning subnets and IP addresses on Frame Relay interfaces:
  1. One subnet containing all Frame Relay DTEs
     • works well for full mesh networks
     • conserves IP addresses
     • looks like LAN-type addressing that makes it easier to conceptualize
  2. One subnet per VC
     • this is the typical network setup for most organization
     • works better with partially meshed networksA hybrid of the first two options
     • each VC is in its own subnet
     • matches the logic behind a set of point-to-point links.
     • wastes some IP addresses, but overcomes some issues with distance vector routing protocols.
     • Subinterfaces allow a single interface to have multiple IP addresses associated with one physical interface. A router can treat each subinterface, and the VC associated with it, as if it were a point-to-point serial link.
  3. Hybrid of the first two options
     • point-to-point subinterfaces are used when a single VC is considered to be all that is in the group.
     • multipoint subinterfaces are used when more than two routers are considered to be in the same group. These interfaces logically terminate more than one VC.

Layer 3 Broadcast Handling

• Frame Relay DTEs cannot send broadcasts across multiple VCs to multiple destinations. At least not like LAN broadcasts
• Routers do, however need to send broadcasts or multicasts for features such as routing protocol updates.
• Two part solution:
  • If configured, Cisco IOS sends copies of the broadcasts across each VC. This is fine if there’s only a few VCs. It there’s hundreds of VCs terminating in one router, for each broadcast, hundreds of copies could be sent.
  • As a second part of the solution, the routers try to minimize the impact of the first part by placing the copies of the broadcast on a separate output queue than the user traffic.

Controlling Speed and Discards

When a customer with a Frame Relay access rate – the clock rate of the access link – that typically is higher than the CIR (e.g. a T1 access link with CIR of 128-kbps), there is a change that a router can send data that far exceeds the rate that the provider agreed with the customer. When that happens the provider can start discarding frames from the network.

Traffic Shaping allows the router to decrease the overall rate of sending bits to a speed slower than the access rate, and maybe even as low as the CIR of a VC.

• The Frame Relay header includes three single-bit flags that can be used to help control the network:
  1. Forward Explicit Congestion Notification ( FECN) – when this bit is set by the device, it means that there is congestion in the forward direction of the frame.
  2. Backward Explicit Congestion Notification (BECN) – the frame relay switch tells the sending router that a congestion occured in the direction opposite, or backward, of the direction of the frame.
  3. Discard Eligibility (DE) bit – if a provider’s switches need to discard frames because of congestion, the customer can set a DE bit for frames the are less important. The switches can then discard those frames with the DE bit set.