The designer can use three different methods to test remote connectivity designs:
- · Simulation software
- · Prototype testing using simulated links
- · Pilot testing in the actual environment
Simulating a DSL or Cable Connection
To simulate a DSL or cable WAN connection, an Ethernet connection can be used. Most Ethernet interfaces can be set to provide a 10-Mb connection, which is similar to the type of connectivity provided over DSL or cable.
The routers are connected using an Ethernet crossover cable. Routing protocol metrics can be adjusted to simulate the metrics of a lower-speed link by using the bandwidth command on the interface. Static route preference can be manually configured by adjusting the administrative distance assigned to the route.
Simulating Serial Connectivity
There are two common methods used to simulate serial connectivity:
CSU/DSUs or serial modems
V.35 cables
Every Frame Relay link has at least three components:
The local point-to-point circuit that connects the local CPE router to the TSP Frame Relay switch
The TSP packet-switched network
The remote point-to-point circuit that connects the remote site into the TSP network
The Local Loop
The proposed connection between the stadium CPE router and the Frame Relay switch at the TSP is a T1 circuit. This connection is referred to as a local loop. The local loop connects the provider Frame Relay switch to the CSU/DSU on the stadium premises. The connection then terminates on the serial port of the CPE router. The clock speed (port speed) of the local loop connection to the Frame Relay cloud is known as the local access rate. The local access rate defines the rate at which data can travel into or out of the provider packet-switched network, regardless of other settings.
Data-link Connection Identifier
Each virtual circuit endpoint is identified by a data-link connection identifier (DLCI). A DLCI is usually significant only on the local loop. In other words, DLCI numbers are unique within a single Frame Relay switch. However, because there can be many Frame Relay switches within the network, DLCI numbers can be duplicated on other switches.
8.2.3
Guaranteed Data Rates
Frame Relay providers offer services with guaranteed average data transfer rates through the provider packet-switched network. This committed information rate (CIR) specifies the maximum average data rate that the network delivers under normal conditions. The CIR is less than or equal to the local access rate. A CIR is assigned to each DLCI that is carried on the local loop. If the stadium attempts to send data at a faster rate than the CIR, the provider network flags some frames with a discard eligible (DE) bit in the frame address header. The network attempts to deliver all frames. However, if there is congestion, it discards any frames marked with the DE bit.
Zero CIR
Many inexpensive Frame Relay services are based on a CIR of zero. A zero CIR means that every frame is a DE frame, and the network can throw any frame away when there is congestion. There is no guarantee of service with a CIR set to zero, so these services are not good choices for mission-critical data.
Local Management Interface
Local Management Interface (LMI) is a signaling standard between the router (DTE device) and the local Frame Relay switch (DCE device). LMI is responsible for managing the connection and maintaining status between the router and the Frame Relay switch. For example, LMI uses keepalive messages to monitor the status of network connections. LMI Frame Relay adds a set of enhancements, referred to as extensions, to basic Frame Relay. One important LMI extension is the ability to report the status of the virtual circuit as well as the status of the physical connection. LMI standards can differ between networks. Cisco routers support three LMI types: Cisco, ANSI Annex D, and ITU-T Q.933 Annex A.
Congestion Control
To help manage traffic flows in the network, Frame Relay implements two mechanisms:
Forward-explicit congestion notification (FECN)
Backward-explicit congestion notification (BECN)
FECNs and BECNs are controlled by a single bit contained in the Frame Relay frame header.
FECN
FECN informs the destination device about congestion on the network path. The FECN bit is part of the Address field in the Frame Relay frame header. The FECN mechanism works in the following way:
1. A DTE device sends Frame Relay frames into the network.
2. If the network is congested, the DCE devices (switches) set the value of the FECN bit to 1.
3. The frames reach the remote destination DTE device.
4. The DTE device reads the Address field with the FECN bit set to 1.
5. This setting indicates that the frame experienced congestion in the path from source to destination.
BECN
BECN informs the source device about congestion on the network path. The BECN bit is also part of the Address field in the Frame Relay frame header. A BECN works in the following way:
1. A Frame Relay switch detects congestion in the network.
2. It sets the BECN bit to 1 in frames headed in the opposite direction from the frames marked with the FECN bit.
3. This setting informs the source DTE device that a particular path through the network is congested.
The two possible Frame Relay encapsulations are ietf and cisco
Inverse ARP and Frame Relay Maps
Inverse Address Resolution Protocol (Inverse ARP) provides a mechanism to create dynamic DLCI-to-Layer 3 address maps. Inverse ARP works similarly to ARP on an Ethernet local network. With ARP, the sending device knows the Layer 3 IP address. It sends broadcasts to learn the remote data link MAC address. With Inverse ARP, the router learns the Layer 2 address, which is the DLCI. It sends requests for the remote Layer 3 IP address.
When an interface on a Cisco router is configured to use Frame Relay encapsulation, Inverse ARP is on by default. It is possible to manually configure a static mapping for a specific DLCI. Static mapping is used if the router at the other end does not support Inverse ARP.
To avoid the problems caused by split horizon, the physical interface is divided into logical subinterfaces. The two types of Frame Relay subinterfaces are point to-point and multipoint.
Point-to-point
With point-to-point subinterfaces, a single subinterface is used to establish one permanent virtual circuit (PVC) connection to another physical interface or subinterface on a remote router. Each pair of interfaces is in its own subnet, and each interface has a single DLCI. Broadcasts are not a problem in this environment because the routers are connected in a point-to-point manner and act like leased lines.
Multipoint
With multipoint subinterfaces, a single subinterface is used to establish multiple PVC connections to multiple physical interfaces or subinterfaces on remote routers. This configuration does not solve the problems with split horizon. Split horizon must be turned off for distance vector routing protocols to work with multipoint links.
Split horizon stops routing table updates from going out of the same interface on which they were received.
8.2.5
A floating static route is a static route that has an administrative distance greater than the administrative distance of the corresponding dynamic routes.
show interface serial
use the show frame-relay pvc command: A PVC status of DELETED can indicate that the DLCI configured on the CPE device does not match the DLCI assigned to the circuit.
Verify LMI Operation
Use the show frame-relay lmi command and look for a non-zero value in any of the Invalid counters. Also make sure that the LMI type is correct for the circuit.
Out=sent in=received
The common values of the DLCI status field are:
0×0: Added and inactive – the switch has this DLCI programmed but it is not usable.
0×2: Added and active – the Frame Relay switch has the DLCI and everything is operational.
0×4: Deleted – the Frame Relay switch does not have this DLCI programmed for the router. This status can happen if the DLCIs are reversed on the router or if the PVC was deleted in the Frame Relay cloud.
A type 0 message is a full LMI status message.
A type 1 message indicates a keepalive LMI exchange.
The Cisco EasyVPN Solution
To ensure that the VPN can support the mobile team scouts, ease of deployment is important. There are two components of Cisco EasyVPN:
Cisco EasyVPN Server – This server can be a router or a dedicated VPN gateway, such as a PIX firewall or a VPN concentrator. A VPN gateway using Cisco EasyVPN Server software can terminate remote access VPNs and site-to-site VPN connections.
Cisco EasyVPN Remote – Cisco EasyVPN Remote enables remote devices to receive security policies from a Cisco EasyVPN Server. This minimizes configuration requirements at the remote VPN location. Cisco EasyVPN Remote allows the VPN parameters to be pushed from the server to the remote device. VPN parameters include internal IP addresses, internal subnet masks, and DHCP server addresses.
The Diffie-Hellman (DH) key agreement is a public key exchange method. It provides a way for two peers to establish a shared secret key, which only they recognize, while communicating over an unsecured channel. Diffie-Hellman groups specify the type of cryptography to be used:
l DH GROUP 1 – Uses 768-bit cryptography.
l DH GROUP 2 - Cisco IOS, PIX Firewall, and Cisco Adaptive Security Appliances (ASA) devices only. Specifies to use 1024-bit cryptography.
l DH GROUP 5 – Supported if the software system requirements are met. Specifies to use 1536-bit cryptography.
VPNs have two important components:
l Tunneling to create the virtual network
l Encryption to enable privacy and security
Virtual Network
To build a virtual network, a tunnel is created between the two endpoints. In a site-to-site VPN, hosts send and receive normal TCP/IP traffic through a VPN gateway. A gateway can be a router, firewall, VPN concentrator, or security appliance. The gateway is responsible for encapsulating outbound traffic from one site and sending it through a tunnel over a network to a peer gateway at the remote site. A tunnel by itself may not guarantee security. The tunnel simply creates an extension of the local network across the WAN or public network. Tunnels can carry either encrypted or unencrypted content. Upon receipt, the remote peer gateway strips the headers, decrypts the packet, and relays it toward the target host inside its private network. In a remote-access VPN, the VPN client on the user computer contacts the gateway to set up the tunnel.
The most common encryption methods used for VPNs are:
Data Encryption Standard (DES), Triple DES (3DES), Advanced Encryption Standard (AES), and Rivest, Shamir, and Adleman (RSA).
Keyed Hashed Message Authentication Code (HMAC) is a data integrity algorithm that guarantees the integrity of the message. There are two common HMAC algorithms:
l HMAC-Message Digest 5 (MD5) – This algorithm uses a 128-bit shared secret key. The variable length message and 128-bit shared secret key are combined and run through the HMAC-MD5 hash algorithm. The output is a 128-bit hash. The hash is appended to the original message and forwarded to the remote end.
l HMAC-Secure Hash Algorithm 1 (HMAC-SHA-1) – This algorithm uses a 160-bit secret key. The variable length message and the 160-bit shared secret key are combined and run through the HMAC-SHA-1 hash algorithm. The output is a 160-bit hash. The hash is appended to the original message and forwarded to the remote end.
IPSec
IPSec is a framework of open standards. It provides data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at Layer 3.
IPSec relies on existing algorithms to implement the encryption, authentication, and key exchange. When configuring the VPN server, the following settings must be configured:
l An IPSec protocol – The choices are Encapsulating Security Payload (ESP), Authentication Header (AH), or ESP with AH.
l An encryption algorithm that is appropriate for the desired level of security – The choices are DES, 3DES, or AES.
l An authentication algorithm to provide data integrity – The choices are MD5 or SHA.
l A Diffie-Hellman group – The choices are DH1, DH2, and DH5, if supported.
IPSec can use Internet Key Exchange (IKE) to handle negotiation of protocols and algorithms. IKE can also generate the encryption and authentication keys that IPSec uses.
Encryption algorithms
Data Encryption Standard (DES) algorithm- DES was developed by IBM. DES uses a 56-bit key, ensuring high-performance encryption. 3DES is a symmetric key cryptosystem.
Triple DES (3DES) algorithm- 3DES is a variant of the 56-bit DES. 3DES operates similarly to DES, in that data is broken into 64-bit blocks. 3DES then processes each block three times, each time with an independent 56-bit key. 3DES provides significant encryption strength over 56-bit DES. DES is a symmetric key cryptosystem.
Advanced Encryption Standard (AES) : The National Institute of Standards and Technology (NIST) have recently adopted AES to replace the existing DES encryption in cryptographic devices. AES provides stronger security than DES. It is computationally more efficient than 3DES. AES offers three different key lengths: 128-, 192-, and 256-bit keys.
Rivest, Shamir, and Adleman (RSA) : RSA is an asymmetrical key cryptosystem. It uses a key length of 512, 768, 1024, or larger. IPSec does not use RSA for data encryption. IKE only uses RSA encryption during the peer authentication phase.
VPN Tunnel Protocols
Generic Routing Encapsulation (GRE) tunnels provide a specific pathway across the shared WAN. They encapsulate traffic with new packet headers to ensure delivery to specific destinations. The network is private. This is because traffic can enter a tunnel only at an endpoint and can leave only at the other endpoint. Tunnels do not provide true confidentiality (like encryption does) but can carry encrypted traffic.
IP Security (IPSec) acts at the Network Layer, protecting and authenticating IP packets between participating IPSec devices (peers). IPSec is not bound to any specific encryption, authentication, security algorithms, or keying technology. IPSec is a framework of open standards.
Layer 2 Forwarding Protocol (L2F) is a protocol developed by Cisco that supports the creation of secure virtual private dialup networks over the Internet by tunneling Layer 2 frames.
Point-to-Point Tunneling Protocol (PPTP) was developed by Microsoft. It is described in RFC2637. PPTP is widely deployed in Windows client software to create VPNs across TCP/IP networks.
Layer 2 Tunneling Protocol (L2TP) is an IETF standard that incorporates the best attributes of PPTP and L2F. L2TP is used to tunnel Point-Point Protocol (PPP) through a public network, such as the Internet, using IP. Since the tunnel occurs on Layer 2, the upper layer protocols are unaware of the tunnel. Like GRE, L2TP can also encapsulate any Layer 3 protocol.
Split tunneling allows users to send only the traffic that is destined for the corporate network across the tunnel. All other traffic is sent out to the Internet via the local LAN of the VPN client. Examples of other traffic include instant messaging, email, and casual web browsing. If split tunneling is configured on the VPN server, Cisco VPN client software can be configured for split tunnels by enabling the Allow Local LAN Access option. Split tunneling increases security risks, because an attack can come from the Internet side of the client into the secured network.
VPN Server Placement
Often, VPN servers are placed at the WAN edge of a network. In these cases, firewalls or ACLs are used to ensure that VPN users have access only to appropriate network resources.
If the stadium management chooses to install a local VPN server, the designer recommends placing the VPN server on the same device that is providing firewall filtering for servers. The remote user traffic can be decrypted and filtered before being sent to the server.