viernes, 9 de agosto de 2013

10 competitors Cisco couldn’t kill off

 
10 competitors Cisco couldn’t kill off
Cisco CEO John Chambers loves to talk about the companies that have tried to compete with Cisco and failed. He refers to companies like 3com, Nortel, Synoptics, etc — and he's right. However, here are 10 companies that have managed to thrive in this era of Cisco dominance and have stood the test of time.



F5 Networks
Load balancing was once considered a market that would rapidly be commoditized, but F5 has managed to create sustainable differentiation as the "L4-7" market has evolved into "Application Delivery Controllers" (ADCs). F5 today has the broadest and deepest application relevancy and can significantly reduce the deployment time and improve the performance of applications, such as SharePoint and Exchange. F5's strategy has worked so well that it caused Cisco to dump its own product in favor of partnering with the No. 2 vendor, Citrix.



Riverbed
One can argue the technical merits of Riverbed's Steelhead versus Cisco's WAAS. From people I have interviewed who have tested the two products, Riverbed can accelerate the performance of a broader range of applications than Cisco, but for many of the core enterprise applications, WAAS is close. However, the real reason many customers buy Riverbed is that it's fast to deploy and easy to manage. I also think Riverbed has done a great job of creating sustainable differentiation, after adding application optimization features over the years.



Juniper
One might look at this and scratch his head, particularly enterprise network managers. While I agree that Juniper's enterprise initiatives have floundered over the years, the company is the de facto No. 2 vendor in the service provider routing space. Cisco and Juniper tend to leap-frog one another in technical superiority. But Juniper's latest releases include the T4000, MX and PTX lines, which are great products and should fuel the Cisco-versus-Juniper SP wars into the foreseeable future.



Arista
How's this for respect? Just a couple of years old and joining the ranks of some long-time Cisco competitors. But Arista seems to have the right mindset to create sustainable differentiation against Cisco in the data center. I had a chance to sit down with Doug Gourlay at Interop and he talked a lot about the value of staying focused. Arista will not venture into markets like ADCs or Metro Ethernet, and will remain laser-focused on data center networking. In fact, he said Arista wants to be to the data center what Juniper is to SP routing, and that's the industry’s de facto No. 2.

 
Polycom
There's arguably no company that did more good for Polycom than Cisco. Cisco's acquisition of Tandberg was supposed to kill off the niche video vendor, correct? That didn't happen, and Cisco's incidentally created a rising tide for both companies. Initially, Polycom wasn't able to do much with the opportunity created by Cisco. In 2010, though, Polycom gutted its management team and CEO Andy Miller re-tooled the company to compete. Some smart people and good execution on Polycom's part, combined with some slow product cycles on Cisco’s part, allowed Polycom to grab some market share.




Aruba Networks
Over the past five years, Aruba's share in Wi-Fi has more than doubled and is now in the high teens. While this hasn't all been at Cisco's expense (Aruba has taken share from Motorola as well), Aruba did implement a "Trojan Horse" strategy with its Airwave management tools a number of years ago. Aruba accepted that Cisco customers buy Cisco hardware, and sold Airwave into those environments to manage the solution. Then the company jumped all over the 802.11n upgrade cycle and used the Airwave footprint to grab some share.

 
Brocade
Brocade has been the market and technology leader in Fibre Channel switching for years now. It was first to have 8 Gig FC, 16 and will likely get to 32 Gig first as well. Despite much of the hype around FCoE, Brocade has kept its focus on delivering faster and more feature-rich FC and now owns about two-thirds of the market. The company appears to have a real shot now, as the shift to fabrics and software defined networks (SDNs) require data networks to be more efficient, resilient and reliable — like a storage fabric.



HP
Under John McHugh, HP Networking came out of nowhere and went from relative obscurity to the No. 2 share vendor almost overnight. HP caught Cisco sleeping and managed to grab some share with value buyers at the access edge. Since then, Cisco has countered with purpose-built products that are more in line with HP pricing. HP then countered by acquiring 3Com to refresh its portfolio and challenge Cisco in the data center. Both companies are building integrated data center "stacks," so we should expect to see the once-great partners remain bitter rivals as the battle for the data center rages on.



Microsoft
There's no vendor that I can remember in recent history that has been more problematic for Cisco than Microsoft. Lync, Microsoft's UC solution, introduced new buyers into the mix that have the same level of loyalty to Redmond as network engineers have to Cisco. Cisco has spent countless hours trying to prove that its solution is not only more reliable than Lync, but cheaper and broader. This may be true, but customers buy Lync because of Microsoft familiarity, and that's a tough value proposition to compete with.



Avaya
Before there was a Cisco-versus-Microsoft battle, there was Cisco versus Avaya. Most people don't realize this, but through its acquisition of Nortel, Avaya actually has over 20% share in voice (not VoIP, but all voice) meaning they control 1 out of every 5 business phones. Under Kevin Kennedy the company has streamlined much of its business, making it more agile than it was in the past, and it will continue to be a threat in the UC space.


 

CCNA 640-802 Lab - Connect, configure, and verify operation status of a device interface

Exam: 640-802

Exam Objective: Connect, configure, and verify operation status of a device interface



Contents

  • Introduction
  • Technology Background
  • Lab Scenario
  • Lab Objectives
  • Lab Solution

Introduction

Two types of interfaces are supported on Cisco Routers: Physical and Virtual interfaces. The types of physical interfaces on a device depend on its interface processors or port adapters. The virtual interfaces that Cisco routers support include subinterfaces and IP tunnels.
Some of the interface types supported by Cisco routers are:
  • Asynchronous serial
  • ATM
  • Dialer
  • Ethernet
  • Fast Ethernet
  • FDDI
  • High-Speed Serial Interface (HSSI)
  • ISDN BRI
  • ISDN PRI
  • Loopback
  • Null
  • Synchronous serial
  • Token Ring
  • Tunnel

Technology Background

Interface configuration is one of the most important parts of configuring a router because without correct configuration the router will not communicate with the network and would not be able to perform any of its function. You can configure Network Layer Address, Layer 2 Protocol, bandwidth and other various things on the interface.
Different routers number their interfaces differently. Some older routers such as the 2500 series number their interfaces as <type><number>. For example: ethernet0 or serial1. New modular routers number their interface as <type> <slot>/<port>. For example: Serial 0/0 or Fastethernet 1/0. This is because they have slots where modules containing interfaces can be added.
To know what interfaces exist on a router; you can use the "show interface" or "show ip interface brief" command. This is what you would see:
Router#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES manual administratively down down    
FastEthernet0/1            unassigned      YES manual administratively down down    
This tells us that this Router has to FastEthernet interfaces in slot0.
To enter the interface configuration mode use the "interface <type> <slot>/<number>" global configuration command. In the Router mentioned above we have to use the "interface Fastethernet0/0" or "interface fa0/0" command.
By default all interfaces are in "administratively down" status. This means that the interface has been shutdown by configuration. You can bring up the interface using the "no shutdown" interface command.
At this stage the interface is ready for Layer 2 and Layer 3 configuration. Some interfaces like the Serial interface support multiple Layer 2 protocols. On Cisco Routers Serial interfaces support HDLC (default), PPP and Frame Replay protocols at Layer 2. Layer 2 protocol can be changed using the "encapsulation <protocol>" command at the interface level.
Most interfaces support multiple Layer 3 protocols such as IPv4, IPv6, IPX, AppleTalk etc depending on the Layer 2 protocol. IP is the most used Layer 3 protocol and that is what Cisco requires you to know for CCNA.
IP address can be configured on an interface using the "ip address <address> <subnet mask>" command. An interface can have two IP addresses belonging to different subnets. The second IP address can be used using the "ip address <address> <subnet mask> secondary" command. Without the secondary keyword, the command will override previously configured address. If you want to the interface to get an IP address using DHCP then the "ip address dhcp" command can be used.
Special care must be taken with Serial Interfaces because by default these interfaces are configured for Data Terminal Equipment (DTE). This means that they receive clocking from a DCE connected via a CSU/DSU. In the lab when you connect two Routers back-to-back using a Serial cable, you will need to configure one of the interfaces to provide clocking as a DCE. This can be done using the "clock rate <speed in bits>" command.
On all interfaces you can add a description so that you remember where the link connects to in future. This can be done using the "description <text>" command.
Another important interface command is the bandwidth command. It has nothing to do with how data is transferred but the configured bandwidth is used by routing protocols such as EIGRP to calculate the best path to a destination. The significance of it can be realized by understanding that by default the bandwidth of a Serial Interface is 1.544MBps. If you have a 128Kbps connection terminating on the Serial link then the Routing protocol is miscalculating the metrics of the path by using 1.544Mpbs instead of 128Kbps. In such situations correcting the bandwidth is essential. Bandwidth is specified in Kilobits.

Lab Scenario

We need help in initial configuration of routers in our network. Your task is to configure the following in the network shown in Figure 1:
  • Configure the Interface with IP information shown. Fa0/0 of RouterA must belong to both the networks
  • RouterA's s0/0 interface should be configured such that any Cisco Router can connect to it back-to-back using a serial interface. No additional configuration apart from IP address should be required on any device connecting to RouterA's s0/0 interface in such manner.
  • EIGRP should always take the bandwidth of RouterA's s0/0 interface as 512KBps

Figure 1


Lab Objectives


  • Configure IP Addresses on the shown interfaces. RouterA's fa0/0 interface will have a secondary address also
  • Clock rate needs to be configured on Serial1/0 interface of RouterA
  • Bandwidth needs to be configured on Serial1/0 interface of RouterA

Lab Solution


IP address configuration on all the Routers will be done using the following commands:
RouterA(config)#interface s1/0
RouterA(config-if)#ip address 192.168.3.1 255.255.255.0
RouterA(config-if)#no shut
RouterA(config)#interface fa0/0
RouterA(config-if)#ip address 192.168.1.1 255.255.255.0
RouterA(config-if)#ip address 192.168.2.1 255.255.255.0 secondary
RouterA(config-if)#no shut
RouterB(config)#interface fa0/0
RouterB(config-if)#ip address 192.168.1.2 255.255.255.0
RouterB(config-if)#no shut
RouterB(config)#interface fa0/0
RouterB(config-if)#ip address 192.168.2.2 255.255.255.0
RouterB(config-if)#no shut
We need to configure the clock rate on RotuerA's s0/0 interface since it would be connecting back-to-back with other Cisco Routers which will be in DTE mode:
RouterA(config)#interface s1/0
RouterA(config-if)#clock rate 512000

Finally we need to configure the bandwidth on RouterA's s0/0 interface so that EIGRP uses 512Kbps to calculate the route metrics:
RouterA(config)#interface s1/0
RouterA(config-if)#bandwidth 512

We can verify the configuration using the "show ip interface brief" command:
RouterA#show ip interface brief
Interface                  IP-Address      OK? Method Status Protocol
FastEthernet0/0    192.168.1.1      YES manual up        up
Serial1/0               192.168.3.1      YES manual up        up
RouterB#show ip interface brief
Interface                  IP-Address      OK? Method Status Protocol
FastEthernet0/0    192.168.1.2      YES manual up        up
RouterC#show ip interface brief
Interface                  IP-Address      OK? Method Status Protocol
FastEthernet0/0    192.168.2.2      YES manual up        up
References:

Cisco IOS Interface Configuration�Guide - Configuring LAN Interfaces
http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/icflanin.html#wp1012559

CCNA 640-802 Lab - Configure, verify, and troubleshoot RSTP operation

Exam: 640-802

Exam Objective: Configure, verify, and troubleshoot RSTP operation



Contents

  • Introduction
  • Technology Background
  • Lab Scenario
  • Lab Objectives
  • Lab Solution

Introduction

Loops on a layer 2 network can be very dangerous. Spanning Tree Protocol (STP) is used to make the layer 2 network loop free. There are two STP standards defined by IEEE - 802.1d (STP) and 802.1w (Rapid STP). As per IEEE standards, a switch can run one STP instance only. Cisco implements a changed to this by allowing one STP instance per VLAN. 802.1w on Cisco Switches is also known as Per VLAN Rapid Spanning Tree Protocol (PVRST).

Technology Background

STP works by identifying all the links in the network and then blocking all redundant links. To do this STP first elects a Root Bridge. Root bridge is the bridge with the best Bridge ID. Bridge ID is a combination of priority and the base MAC address of the switch. Priority is a configurable value between 0 to 61440 in increments of 4096. The default priority on Cisco switches is 32768. The lower the priority and MAC address the better.
The root bridge is the center of the network. All decisions are taken from the prespective of the root bridge. Switches send Bridge Protocol Data Unit (BPDU) out every port. The BPDUs contain amongst other information the BridgeID. By comparing the BridgeIDs the root bridge is selected.
Once the root bridge is elected the rest of the switches in the network (called Non-root Bridge) will select one port which is their lowest cost way to the Root bridge - This port is called the root port.. The cost is determined by the bandwidth. Then port cost is used to find the lowest cost port connecting a network segement to the switch - This port is called the designated port. Root ports, designated ports and all port on the root bridge are in Forwarding mode. Rest of the ports go into a blocked or alternate mode.
Ports in Forwarding mode will send and receive data and BPDUs. Blocked ports will not send or receive data but will receive BPDUs. Alternate ports are redundant root ports which can be used as soon as the root port goes down.
In Figure 1, if bridge priorities are left at default then, Switch1 will become the root bridge because of the lowest base MAC address. Switch2's root port will be fa0/2 due to lower path cost. Switch3's root port will be fa0/1. Switch2's fa0/1 and Switch3's fa0/2 ports will be the alternate ports.

 

Figure 1
If we need to get Switch2 elected as the root bridge then we will need to lower its priority.
If a host is connected to a host then STP can be disabled on that port by enabling Portfast mode on it. This will ensure that the port goes into forwarding as soon as it comes up.
By default IEEE 802.1d is enabled on most Cisco switches. It can be changed to RSTP with the following global configuration mode command:
spanning-tree mode rapid-pvst
The priority of a Switch can be changed for a VLAN to make it the root bridge of the VLAN using the following command:
spanning-tree vlan <vlan#> priority <priority>
The cost of port can also be modified by using the following interface command:
spanning-tree cost <cost>

To enable portfast on a port use the spanning-tree portfast command on the interface mode.
Spanning tree operation can be verified using the show spanning-tree vlan <vlan#> command

Lab Scenario

We have a network running 802.1D. We need to make the following changes in the network:
  • Use 802.1w instead of 802.1d
  • Make SwitchC the root bridge for VLAN 2
  • There will be a host connect to SwitchB on port fa0/10. Disable STP on this port.
The network is shown in Figure 2.


 

Figure 2

Lab Objectives

  • Enable Rapid PVSTP on all switches
  • Change the priority of SwitchC for VLAN 2
  • Enable Portfast on fa0/10 on SwitchB

Lab Solution

First STP mode needs to be changed on all switches:
SwitchA(config)#spanning-tree mode rapid-pvst
SwitchB(config)#spanning-tree mode rapid-pvst
SwitchC(config)#spanning-tree mode rapid-pvst
SwitchD(config)#spanning-tree mode rapid-pvst
To make SwitchC the root bridge let's change its priority to 4096
SwitchC(config)#spanning-tree vlan 2 priority 4096
Since the rest of the switches are at default priority (32768) SwitchC will become the root bridge for VLAN 2.
To disable STP on fa0/10 on SwitchB, we will need to enable Portfast on it:
SwitchB(config)#interface fa0/10
SwitchB(config-if)#spanning-tree portfast
Let's verify the spanning-tree operations on SwitchC and SwitchA:
SwitchC#show spanning-tree vlan 2
VLAN0002
  Spanning tree enabled protocol rstp
  Root ID    Priority    4098
             Address     0014.a93f.8380
             This bridge is the root
             Hello Time   2 sec Max Age 20 sec Forward Delay 15 sec
  Bridge ID Priority    4098   (priority 4096 sys-id-ext 2)
             Address     0014.a93f.8380
             Hello Time   2 sec Max Age 20 sec Forward Delay 15 sec
             Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1               Desg FWD 19        128.17   P2p
Fa0/2              Desg FWD 19         128.20   P2p
SwitchA#show spanning-tree vlan 2
VLAN0002
  Spanning tree enabled protocol rstp
  Root ID    Priority    4098
             Address     0014.a93f.8380
             Cost        23
             Port        1 (FastEthernet0/1)
             Hello Time   2 sec Max Age 20 sec Forward Delay 15 sec
  Bridge ID Priority    32770 (priority 32768 sys-id-ext 2)
             Address     0013.c3e8.2500
             Hello Time   2 sec Max Age 20 sec Forward Delay 15 sec
             Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1              Root FWD 19         128.15   P2p
Fa0/2              Altn BLK 100        128.19   P2p
Note in the output that SwitchC is the root bridge and SwitchA's fa0/1 is the root port since its cost is lower that fa0/2's cost.


References:
Catalyst 2950 and Catalyst 2955 Switch Software Configuration Guide - Configuring STP
http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22_ea5/configuration/guide/swstp.html

miércoles, 10 de julio de 2013

CCNA 640-802 Lab - Configure and apply ACLs based on network filtering requirements

Exam: 640-802

Exam Objective: Configure and apply ACLs based on network filtering requirements



Contents

  • Introduction
  • Technology Background
  • Lab Scenario
  • Lab Objectives
  • Lab Solution

Introduction

Access lists (ACLs) filter network traffic by controlling whether routed packets are forwarded or blocked at the router's interfaces. The router examines each packet to determine whether to forward or drop the packet, based on the criteria you specified within the access lists.
Access list criteria could be the source address of the traffic, the destination address of the traffic, the upper-layer protocol, or other information.
Access lists are used in many other situations which do not deal with blocking packets. An example would be using Access List to determine which route will be advertised by a routing protocol.


Technology Background

Access lists are created using a series of statements called Access Control Entries (ACEs). Each ACE is a condition describing a network, or a host, or a protocol or a port or a combination of any of them.
Before we get into types of Access Lists and their creation, there are some ground rules we need to know well about what happens when a packet arrives at an interface or is about to leave an interface and an ACL is applied to it:
  • The Packet will be checked against the ACEs sequentially starting from the top.
  • It will be compared with ACEs until a match is found. The action specified with the first ACE which matches will be taken and no further ACEs will be checked
  • There is an implicit deny any the end. This means if the packet does not match any of the ACEs then it will be discarded.
There are 2 types are Access Lists supported by IOS:
  • Standard Access Lists: These use only the source IP address in an IP packet as the condition to match a packet. This means that standard access lists will permit or deny all traffic from any host/network. They do not differentiate between type of traffic.
  • Extended Access Lists: Extended access lists can evaluate many of the other fields in the layer 3 and layer 4 headers of an IP packet. They can evaluate source and destination IP addresses, the protocol field in the Network layer header, and the port number at the Transport layer header. This gives us more control more what kind of traffic is permitted or denied.
Access Lists do not do anything unless they are applied to the interface. Each interface can have one Access List per direction per layer 3 protocol. So it most of today's IP networks we can have one ACL in each direction each interface. The direction mentioned here refers to the direction of the traffic. When an Access List is applied to an inbound direction it will filter traffic coming from the network into the router. When it is applied in outbound direction it will filter traffic going from the router to the network.
Access Lists are created using the following syntax:
  • Standard Access List : access-list <1-99|1300-1999> <permit|deny> <address|host|any> <wildcard-mask>
Numbers are used to identify ACLs. Standard access list use the 1-99 and 1300-1999 range.
permit or deny states the action to take if a packet matches the condition
We can permit or deny based on an address/mask (example 1), or a single IP address (host) (example 2) or any traffic (example 3).
We will discuss wildcard masks shortly.
Example 1:
access-list 1 permit 192.168.1.0 0.0.0.255
Example 2:
access-list 2 deny host 192.168.1.1
Example 3:
access-list 3 permit any
  • Extended Access List: access-list <100-199 | 2000-2699> <permit|deny> <protocol> <source address> <source mask> < source port> <destination address> <destination mask> <destination port>
Extended ACLs use the numbers 100-199 and 2000-2699. In addition to the standard ACL options, we have the option to specify the destination address, Layer 4 protocol or IP and source and destination ports.
Example 1:
To block telnet traffic from any host to any host we will use the following Access List:
access-list 100 deny tcp any any eq 23
Note that eq stands for equal. We can use gt (greater than) and lt (less than) to specify port numbers.
Example 2:
To block traffic all IP traffic from the host 192.168.1.10 to network 10.1.1.0/24, we will use the following ACL:
access-list 101 deny ip host 192.168.1.10 10.1.1.0 0.0.0.255
Note that we have used a deny ACE. If this is the only ACE in the ACL, we will need to add an explicit permit statement in the end or else no traffic will be allowed due to the implicit deny.
Masks are used with IP addresses in IP ACLs to specify what should be permitted and denied. Masks in order to configure IP addresses on interfaces start with 255 and have the large values on the left side, for example, IP address 209.165.202.129 with a 255.255.255.224 mask. Masks for IP ACLs are the reverse, for example, mask 0.0.0.255. This is sometimes called an inverse mask or a wildcard mask. When the value of the mask is broken down into binary (0s and 1s), the results determine which address bits are to be considered in processing the traffic. A 0 indicates that the address bits must be considered (exact match); a 1 in the mask is a "don't care".
This table further explains the concept.
Mask Example
network address (traffic that is to be processed)
10.1.1.0
mask
0.0.0.255
network address (binary)
00001010.00000001.00000001.00000000
mask (binary)
00000000.00000000.00000000.11111111
Based on the binary mask, you can see that the first three sets (octets) must match the given binary network address exactly (00001010.00000001.00000001). The last set of numbers are "don't cares" (.11111111). Therefore, all traffic that begins with 10.1.1. matches since the last octet is "don't care". Therefore, with this mask, network addresses 10.1.1.1 through 10.1.1.255 (10.1.1.x) are processed.
Subtract the normal mask from 255.255.255.255 in order to determine the ACL inverse mask. In this example, the inverse mask is determined for network address 172.16.1.0 with a normal mask of 255.255.255.0.
  • 255.255.255.255 - 255.255.255.0 (normal mask) = 0.0.0.255 (inverse mask)
Note these ACL equivalents.
  • The source/source-wildcard of 0.0.0.0/255.255.255.255 means "any".
  • The source/wildcard of 10.1.1.2/0.0.0.0 is the same as "host 10.1.1.2".
As mentioned earlier, Access Lists are useless if not applied to an interface. They access be applied to an interface using the following command:
ip access-group <access-list> <in|out>

Example:
ip access-ground 101 in
We can use the following commands to verify Access Lists:
  • show access-lists - Will show all access-lists configured on the router and the count of packets which were denied or permitted through each ACE
  • show interfaces - Will show will ACL is applied in which directions on Interfaces.


Lab Scenario

We need some security added to our network shown in Figure 1. Your task is to configure the network such that:
  • HTTP and ICMP traffic should not be allowed from 172.16.0.0/24 and 172.17.0.0/24 networks to Server1 and Server 2. This configuration needs to be done at RouterA
  • Only hosts 172.16.1.1 and 172.16.1.2 can access server Server1 from the 172.16.1.0/24 network. This configuration needs to be done at RouterB
  • Only hosts 172.17.1.10 and 172.17.1.11 can access server Server2 from the 172.16.1.0/24 network. This configuration needs to be done at RouterC

Figure 1


Lab Objectives


  • Create an Access List denying TCP/80 and ICMP traffic from 172.16.0.0/24 and 172.17.0.0/24 to Server1 and Server2. Apply on RouterA fa0/1
  • Create an Access List permitting ip traffic from host 172.16.1.1 and 172.16.1.2 to Server1 and Server2. All other traffic to Server1 and Server2 should be blocked. Apply this ACL on fa0/0 on RouterB
  • Create an Access List permitting ip traffic from host 172.17.1.10 and 172.17.1.11 to Server1 and Server2. All other traffic to Server1 and Server2 should be blocked. Apply this ACL on fa0/0 on RouterC


Lab Solution

The first task requires us to stop HTTP and ICMP traffic from coming to Server1 and Server2 by applying an ACL on RouterA. We will need to deny these traffic and then add an explicit permit in the end:
RouterA(config)#access-list 101 deny tcp 172.16.0.0 0.0.255.255 host 192.168.1.1 eq 80
RouterA(config)#access-list 101 deny icmp 172.16.0.0 0.0.255.255 host 192.168.1.1
RouterA(config)#access-list 101 deny tcp 172.16.0.0 0.0.255.255 host 192.168.1.2 eq 80
RouterA(config)#access-list 101 deny icmp 172.16.0.0 0.0.255.255 host 192.168.1.2
RouterA(config)#access-list 101 deny tcp 172.17.0.0 0.0.255.255 host 192.168.1.1 eq 80
RouterA(config)#access-list 101 deny icmp 172.17.0.0 0.0.255.255 host 192.168.1.1
RouterA(config)#access-list 101 deny tcp 172.17.0.0 0.0.255.255 host 192.168.1.2 eq 80
RouterA(config)#access-list 101 deny icmp 172.17.0.0 0.0.255.255 host 192.168.1.2
RouterA(config)#access-list 101 permit ip any any
RouterA(config)#interface fa0/1
RouterA(config-if)#ip access-group 101 in
The Second task requires us to ensure that only the given hosts are able to access Server1 and Server2 by applying an ACL on RouterB. We first permit the given hosts and then deny all ip traffic destined to the Servers. In the end an explicit permit will be needed:
RouterB(config)#access-list 101 permit ip host 172.16.1.1 host 192.168.1.1
RouterB(config)#access-list 101 permit ip host 172.16.1.1 host 192.168.1.2
RouterB(config)#access-list 101 permit ip host 172.16.1.2 host 192.168.1.1
RouterB(config)#access-list 101 permit ip host 172.16.1.2 host 192.168.1.2
RouterB(config)#access-list 101 deny ip any host 192.168.1.1
RouterB(config)#access-list 101 deny ip any host 192.168.1.2
RouterB(config)#access-list 101 permit ip any any
RouterB(config)#interface fa0/0
RouterB(config-if)#ip access-group 101 in
The Last task also requires us to ensure that certain hosts are able to get to the Servers from RouterC:
RouterC(config)#access-list 101 permit ip host 172.17.1.10 host 192.168.1.1
RouterC(config)#access-list 101 permit ip host 172.17.1.10 host 192.168.1.2
RouterC(config)#access-list 101 permit ip host 172.17.1.11 host 192.168.1.1
RouterC(config)#access-list 101 permit ip host 172.16.1.11 host 192.168.1.2
RouterC(config)#access-list 101 deny ip any host 192.168.1.1
RouterC(config)#access-list 101 deny ip any host 192.168.1.2
RouterC(config)#access-list 101 permit ip any any
RouterC(config)#interface fa0/0
RouterC(config-if)#ip access-group 101 in
To verify this lab try to ping 192.168.1.1 from RouterB's fa0/0 interface. No ICMP reply should be received. The output will be similar to the one given below:
RouterB#ping 192.168.1.1 source fa0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1
.....
Success rate is 0 percent (0/5)
References:
Configuring IP Access Lists
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml#standacl

sábado, 6 de julio de 2013

CCNA 640-802 Lab - Configure and verify a PPP connection between Cisco routers

Exam: 640-802

Exam Objective: Configure and verify a PPP connection between Cisco routers



Contents

  • Introduction
  • Technology Background
  • Lab Scenario
  • Lab Objectives
  • Lab Solution

Introduction

The Point-to-Point Protocol (PPP) originally emerged as an encapsulation protocol for transporting IP traffic over point-to-point links. PPP also established a standard for the assignment and management of IP addresses asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, error detection, and option negotiation for such capabilities as network layer address negotiation and data-compression negotiation.


Technology Background

PPP is Data Link Layer Protocol and supports its functions by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCPs) to negotiate optional configuration parameters and facilities. In addition to IP, PPP supports other protocols, including Novell's Internetwork Packet Exchange (IPX) and DECnet.
The PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection. LCP goes through four distinct phases.
First, link establishment and configuration negotiation occur. Before any network layer datagrams (for example, IP) can be exchanged, LCP first must open the connection and negotiate configuration parameters. This phase is complete when a configuration-acknowledgment frame has been both sent and received.
This is followed by link quality determination. LCP allows an optional link quality determination phase following the link-establishment and configuration-negotiation phase. In this phase, the link is tested to determine whether the link quality is sufficient to bring up network layer protocols. This phase is optional. LCP can delay transmission of network layer protocol information until this phase is complete. An optional authentication phase can be initiated here or along with the link-quality determination phase before NCP takes over.
At this point, network layer protocol configuration negotiation occurs. After LCP has finished the link quality determination phase, network layer protocols can be configured separately by the appropriate NCP and can be brought up and taken down at any time. If LCP closes the link, it informs the network layer protocols so that they can take appropriate action.
Finally, link termination occurs. LCP can terminate the link at any time. This usually is done at the request of a user but can happen because of a physical event, such as the loss of carrier or the expiration of an idle-period timer.
PPP can be enabled on an interface using the "encapsulation ppp" command. Along with this a layer 3 address is required to ensure communication.
As mentioned before, PPP supports authenticating a link. There are two methods of authentication that can be used with PPP links:
Password Authentication Protocol (PAP): The Password Authentication Protocol (PAP) is the less secure of the two methods. Passwords are sent in clear text, and PAP is only performed upon the initial link establishment. When the PPP link is first established, the remote node sends the username and password back to the originating router until authentication is acknowledged.

Challenge Handshake Authentication Protocol (CHAP): The Challenge Handshake Authentication Protocol (CHAP) is used at the initial startup of a link and at periodic checkups on the link to make sure the router is still communicating with the same host. After PPP finishes its initial link-establishment phase, the local router sends a challenge request to the remote device. The remote device sends a value calculated using a one-way hash algorithm called MD5. The local router checks this hash value to make sure it matches. If the values don't match, the link is immediately terminated.
After PPP has been enabled on the interface, authentication can be configured between the routers. First, we need to set the hostname of the router. Then we set the username and password for the remote router that will be connecting to your router:
Example:
Router#config t
Router(config)#hostname RouterA
RouterA(config)#username RouterB password ppppassword
Note that the username (RouterB) is the hostname of the remote router and it is case sensitive. The password on both routers must be the same. We must have a username and password configured for each remote system we plan to connect to. The remote routers must also be configured with usernames and passwords. Now we need to enable authentication on the interface using the "ppp authentication <protocol> <protocol>" command. Note that the second protocol is optionally and is used only when the remote end does not support the first protocol. If a single protocol is selected and the remote then does not support it, the link will be terminated.
Example:
RouterA(config)#interface s0/0
RouterA(config-if)#ppp authentication pap chap

PPP configuration can be verified using the following commands:
  • show interfaces
  • debug ppp negotiation


Lab Scenario

We need to have PPP configured between our Head office and Branch Office. You task is to configure PPP on both the devices and ensure that they authenticate using "0urPPP" password. You also need to ensure that the authentication is done periodically after the link is established. Our network is shown in Figure 1:

Figure 1


Lab Objectives

Configure PPP on both routers using CHAP as authentication protocol


Lab Solution


RouterA(config)#username RouterB password 0urPPP
RouterA(config)#interface s0/0
RouterA(config-if)#encapsulation ppp
RouterA(config-if)#ppp authentication chap
RouterA(config-if)#ip address 192.168.1.1 255.255.255.0
RouterA(config-if)#no shut

RouterB(config)#username RouterA password 0urPPP
RouterB(config)#interface s0/0
RouterB(config-if)#encapsulation ppp
RouterB(config-if)#ppp authentication chap
RouterB(config-if)#ip address 192.168.1.2 255.255.255.0
RouterB(config-if)#no shut
Let's verify the connectivity from RouterA:
RouterA#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/24 ms
Let's see the interface output on both routers:
RouterA#show interfaces s0/0
Serial0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is 192.168.1.1/24
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP, CDPCP, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:44, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:04:33
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations 0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     65 packets input, 3035 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     74 packets output, 2900 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up DSR=up DTR=up RTS=up CTS=up
RouterB#show interfaces s0/0
Serial0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is 192.168.1.2/24
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP, CDPCP, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:30, output 00:00:01, output hang never
  Last clearing of "show interface" counters 00:05:20
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations 0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     79 packets input, 3259 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     81 packets output, 3909 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up DSR=up DTR=up RTS=up CTS=up
This is what debug ppp negotiation looks like on RouterA
*Mar 1 00:08:36.615: Se0/0 LCP: I CONFREQ [Open] id 3 len 15
*Mar 1 00:08:36.619: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar 1 00:08:36.619: Se0/0 LCP:    MagicNumber 0x0136C252 (0x05060136C252)
*Mar 1 00:08:36.627: Se0/0 IPCP: State is Closed
*Mar 1 00:08:36.635: Se0/0 PPP: Phase is TERMINATING
*Mar 1 00:08:36.635: Se0/0 PPP: Phase is ESTABLISHING
*Mar 1 00:08:36.639: Se0/0 LCP: O CONFREQ [Open] id 13 len 15
*Mar 1 00:08:36.643: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar 1 00:08:36.643: Se0/0 LCP:    MagicNumber 0x0036C341 (0x05060036C341)
*Mar 1 00:08:36.647: Se0/0 LCP: O CONFACK [Open] id 3 len 15
*Mar 1 00:08:36.647: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar 1 00:08:36.651: Se0/0 LCP:    MagicNumber 0x0136C252 (0x05060136C252)
*Mar 1 00:08:36.659: Se0/0 IPCP: Remove route to 192.168.1.2
*Mar 1 00:08:36.671: Se0/0 LCP: I CONFACK [ACKsent] id 13 len 15
*Mar 1 00:08:36.671: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar 1 00:08:36.675: Se0/0 LCP:    MagicNumber 0x0036C341 (0x05060036C341)
*Mar 1 00:08:36.675: Se0/0 LCP: State is Open
*Mar 1 00:08:36.679: Se0/0 PPP: Phase is AUTHENTICATING, by both
*Mar 1 00:08:36.679: Se0/0 CHAP: O CHALLENGE id 3 len 28 from "RouterA"
*Mar 1 00:08:36.679: Se0/0 CHAP: I CHALLENGE id 3 len 28 from "RouterB"
*Mar 1 00:08:36.691: Se0/0 CHAP: Using hostname from unknown source
*Mar 1 00:08:36.695: Se0/0 CHAP: Using password from AAA
*Mar 1 00:08:36.695: Se0/0 CHAP: O RESPONSE id 3 len 28 from "RouterA"
*Mar 1 00:08:36.699: Se0/0 CHAP: I RESPONSE id 3 len 28 from "RouterB"
*Mar 1 00:08:36.699: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar 1 00:08:36.703: Se0/0 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar 1 00:08:36.711: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar 1 00:08:36.715: Se0/0 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar 1 00:08:36.731: Se0/0 CHAP: O SUCCESS id 3 len 4
*Mar 1 00:08:36.739: Se0/0 CHAP: I SUCCESS id 3 len 4
*Mar 1 00:08:36.743: Se0/0 PPP: Phase is UP
*Mar 1 00:08:36.747: Se0/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 1 00:08:36.747: Se0/0 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
*Mar 1 00:08:36.747: Se0/0 PPP: Process pending ncp packets
*Mar 1 00:08:36.755: Se0/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar 1 00:08:36.755: Se0/0 IPCP:    Address 192.168.1.2 (0x0306C0A80102)
*Mar 1 00:08:36.759: Se0/0 AAA/AUTHOR/IPCP: Start. Her address 192.168.1.2, we want 0.0.0.0
*Mar 1 00:08:36.775: Se0/0 AAA/AUTHOR/IPCP: Reject 192.168.1.2, using 0.0.0.0
*Mar 1 00:08:36.779: Se0/0 AAA/AUTHOR/IPCP: Done. Her address 192.168.1.2, we want 0.0.0.0
*Mar 1 00:08:36.783: Se0/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Mar 1 00:08:36.783: Se0/0 IPCP:    Address 192.168.1.2 (0x0306C0A80102)
*Mar 1 00:08:36.783: Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar 1 00:08:36.783: Se0/0 IPCP:    Address 192.168.1.1 (0x0306C0A80101)
*Mar 1 00:08:36.783: Se0/0 IPCP: State is Open
*Mar 1 00:08:36.799: Se0/0 IPCP: Install route to 192.168.1.2
References:

PPP
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/PPP.html
Configuring PPP CHAP authentication
http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4131.shtml

sábado, 22 de junio de 2013

CCNA 640-802 Lab - Configure and verify Frame Relay on Cisco routers

Exam: 640-802

Exam Objective: Configure and verify Frame Relay on Cisco routers



Contents

  • Introduction
  • Technology Background
  • Lab Scenario
  • Lab Objectives
  • Lab Solution

Introduction

Frame Relay is a high-performance WAN protocol that operates at the physical and data link layers of the OSI reference model. Frame Relay originally was designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well. This chapter focuses on Frame Relay's specifications and applications in the context of WAN services.
Frame Relay is an example of a packet-switched technology. Packet-switched networks enable end stations to dynamically share the network medium and the available bandwidth. Frame Relay often is described as a streamlined version of X.25, offering fewer of the robust capabilities, such as windowing and retransmission of last data that are offered in X.25. Frame Relay is a layer 2 technology.


Technology Background

The default encapsulation on a Cisco Router's serial interface is HDLC. To use Frame-Relay on them, the encapsulation needs to be changed using the "encapsulation frame-relay" command. With Frame Relay, there are further two encapsulation types - Cisco and IETF. Cisco is the default type and you will need to manually change it to IETF if you are connecting to a non-Cisco device. The command to do this is:
Router(config)#interface s0/0
Router(config-if)#encapsulation frame-relay ietf
Frame Relay operates using virtual circuits. These virtual circuits are what link together the devices connected to the provider's network. Frame Relay provides a virtual circuit between your two DTE devices, making them appear to be connected via a circuit when they are actually sending devices through a shared medium. There are two types of Virtual Circuits - Permanent virtual circuit (PVC) and Switched Virtual Circuit (SVCs). PVCs will always remain in place but SVCs are setup and torn down as and when data needs to be sent.
Frame Relay PVCs use Data Link Connection Identifiers (DLCIs). A Frame Relay service provider assigns DLCI values, which are used on Frame Relay interfaces to distinguish between different virtual circuits.
A DLCI can be assigned to an interface using the following command
Router(config)#interface s0/0
Router(config-if)#frame-relay interface-dlci <dlci>
The DLCI value can be anything between 16 and 1007.
Local Management Interface (LMI) is a signaling standard used between your router and the first Frame Relay switch it's connected to. It allows for sharing information about the operation and status of the virtual circuit between the provider's network and your router. The following information is shared using LMI:
Keepalives: These verify that data is flowing.
Global addressing: This provides global significance to DLCIs, allowing the Frame Relay
cloud to work exactly like a LAN.
Status of virtual circuits: This provides DLCI status. The status inquiries and messages are
used as keepalives when there is no regular LMI traffic to send.
There are three different types of LMI message formats: Cisco, ANSI, and Q.933A. The different
kinds in use depend on both the type and configuration of the telco's switching gear, so it's important the router is configured to use the LMI type configured at the telco's end. Cisco is default LMI type.
LMI type can be configured using the following command:
Router(config-if)#frame-relay lmi-type <cisco|ansi|q933a>
LMI is autosensed in routers running IOS version 11.2 and above.
Let's see the configuration of a PVC on a Serial Interface:
Router(config)#interface s0/0
Router(config-if)#encapsulation frame-relay ietf
Router(config-if)#ip address 192.168.1.1 255.255.255.0
Router(config-if)#frame-relay interface-dlci 101
The above example will configure a serial interface to use frame relay IETF encapsulation and DLCI 101. The router at the other end can use a DLCI provided by the ISP and 192.168.1.1 IP Address to reach us.
We can have multiple virtual circuits on a single Physical interface and each circuit can be treated as a different network/interface. This can be achieved using sub-interfaces. Frame Relay sub-interfaces can be point-to-point or multipoint. Point-to-Point sub-interfaces treat each DLCI as a different network. Multipoint interfaces will treat a group of DLCI as single network. Frame relay can be configured on sub-interfaces using the following commands:
Router(config)#interface s0/0
Router(config-if)#encapsulation frame-relay ietf
Router(config-if)#exit
Router(config)#interface s0/0.1 point-to-point
Router(config-subif)#ip address 192.168.1.1 255.255.255.0
Router(config-subif)#frame-relay interface-dlci 101
The following commands can be used to verify frame relay configuration:
  • show frame-relay pvc
  • show frame-relay lmi
  • show interfaces

Lab Scenario

We have purchased Frame Relay links between our Head Office and Branch Offices. Your task is to configure the Routers as shown in Figure 1. Ensure that IETF frame-relay encapsulation is used.

Figure 1


Lab Objectives


  • Configure Frame Relay using sub-interfaces on RouterA using DLCI 102 and 103
  • Configure Frame Relay using the physical interface of Router B and DLCI 201
  • Configure Frame Relay using the physical interface of Router C and DLCI 301


Lab Solution

Before we configure Frame-relay, it should be noted that a Frame Relay switch is required between the devices for the link to work. A Cisco router can be configured as a Frame Relay Switch. See the References section for the URL to the document explaining the Frame Relay switch configuration:
Let's configure RouterA first:
RouterA(config)#interface s0/0
RouterA(config-if)#encapsulation frame-relay ietf
RouterA(config-if)#no shut
RouterA(config-if)#exit
RouterA(config)#interface s0/0.1 point-to-point
RouterA(config-subif)#frame-relay interface-dlci 102
RouterA(config-fr-dlci)#exit
RouterA(config-subif)#ip address 192.168.1.1 255.255.255.0
RouterA(config-subif)#exit
RouterA(config)#interface s0/0.2 point-to-point
RouterA(config-subif)#frame-relay interface-dlci 103
RouterA(config-fr-dlci)#exit
RouterA(config-subif)#ip address 192.168.2.1 255.255.255.0

Configuration on RouterB:

RouterB(config)#interface s0/0
RouterB(config-if)#encapsulation frame-relay ietf
RouterB(config-if)#frame-relay interface-dlci 201
RouterB(config-fr-dlci)#exit
RouterB(config-if)#ip address 192.168.1.2 255.255.255.0
RouterB(config-if)#no shut
Configuration on RouterC:
RouterC(config)#interface s0/0
RouterC(config-if)#encapsulation frame-relay ietf
RouterC(config-if)#frame-relay interface-dlci 301
RouterC(config-fr-dlci)#exit
RouterC(config-if)#ip address 192.168.2.2 255.255.255.0
RouterC(config-if)#no shut

Let's verify connectivity from RouterA:
RouterA#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/22/32 ms
RouterA#ping 192.168.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/17/64 ms

PVC status on RouterA:
RouterA#show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
  input pkts 7             output pkts 18           in bytes 610       
  out bytes 3502           dropped pkts 0           in pkts dropped 0         
  out pkts dropped 0                out bytes dropped 0         
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0         
  out BECN pkts 0          in DE pkts 0             out DE pkts 0         
  out bcast pkts 7         out bcast bytes 2358      
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:04:33, last time pvc status changed 00:04:13
          
DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.2
  input pkts 8             output pkts 16           in bytes 758       
  out bytes 2378           dropped pkts 0           in pkts dropped 0         
  out pkts dropped 0                out bytes dropped 0         
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0         
  out BECN pkts 0          in DE pkts 0             out DE pkts 0         
  out bcast pkts 3         out bcast bytes 1026      
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:04:34, last time pvc status changed 00:04:14

PVC status on RouterB:
RouterB#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
  input pkts 16            output pkts 7            in bytes 2542      
  out bytes 610            dropped pkts 0           in pkts dropped 0         
  out pkts dropped 0                out bytes dropped 0         
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0         
  out BECN pkts 0          in DE pkts 0             out DE pkts 0         
  out bcast pkts 1         out bcast bytes 30        
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:03:34, last time pvc status changed 00:02:23

PVC status on RouterC

RouterC#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
  input pkts 18            output pkts 8            in bytes 2750      
  out bytes 758            dropped pkts 0           in pkts dropped 0         
  out pkts dropped 0                out bytes dropped 0         
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0         
  out BECN pkts 0          in DE pkts 0             out DE pkts 0         
  out bcast pkts 1         out bcast bytes 30        
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:03:53, last time pvc status changed 00:02:39


References:

Configuring Frame Relay Switching
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml#topic7
Frame Relay
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Frame-Relay.html
Comprehensive Guide to Configuring and Troubleshooting Frame Relay
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml

martes, 18 de junio de 2013

CCNA 640-802 Lab - Configure verify and troubleshoot EIGRP

Exam: 640-802

Exam Objective: Configure, verify, and troubleshoot EIGRP



Contents

  • Introduction
  • Technology Background
  • Lab Scenario
  • Lab Objectives
  • Lab Solution

Introduction

EIGRP is a Cisco proprietary enhanced distance vector (hybrid) routing protocol. It is a classless protocol which sends output updates at startup and when there is a change in the network. The maximum hop count for EIGRP is 255. It supports various Routed protocols such as IPv4, IPv6, Appletalk, etc. It uses proprietary Reliable Transport Protocol (RTP) to send updates and Diffusing Update Algorithm (DUAL) to find the best path.


Technology Background

EIGRP is started on a router using the "router eigrp <as>" command. AS stands for Autonomous system.AS defines an EIGRP network. Routers belonging to different Autonomous Systems do not share routing information.
Once EIGRP has been started, network can be defined using the "network <address> <wildcard mask>". Wildcard mask is optional if you are using default subnet mask for the address class.
As soon as the network statement is added, EIGRP will start on interface which belongs to the Network configured with the network command. EIGRP will start sending out Hello packets to multicast address 224.0.0.10 to discover neighboring routers running EIGRP.
If it receives an ACK or Hello from another router in the same EIGRP AS then it will form an adjacency with it and the routers will exchange their full routing table.
EIGRP maintains a table of all its neighbors. This table can be viewed using the "show ip eigrp neighbor" command.
Routes received from neighbors are stored in a local topology table.
The route received from the neighbor will have a metric attached to it. This is the metric that is applicable on the advertising router. This is called the Reported Distance (RD). The receiving route will need to add the metric of the link between itself and the advertising router. If multiple paths are learned to a remote network then the path with best metric (RD + metric to the advertising router) is selected. This metric is the Feasible Distance (FD).
The path with the best metric is called the Successor. This is the route which will be presented to the router for the routing table. All other route to the same remote network will be kept as Feasible Successors as long as their RD is lower than the FD. Feasible successor is the route which will be used when the Successor is lost. EIGRP will keep upto 6 successors in the topology table.
EIGRP uses a combination of Bandwidth, Delay, Load and Reliability to calculate the metric of a route. Metric is the cost of using that route.
EIGRP topology table can be viewed using "show ip eigrp topology" command.
An important thing to note about EIGRP communication between two routers is that it is done using a Multicast to 224.0.0.10 IP address. If a route does not get Hellos from an adjacent router for a configured period then it will remove it from its neighbor table and also remove all routes learned from it.
Similarly if an EIGRP update is not acknowledged by an adjacent neighbor then update will be resent using a unicast packet up to 16 times. If the adjacent router still fails to acknowledge the update then the adjacency will be torn down and all routes learned from that neighbor will be flushed.
We learned previously that EIGRP will select the route with the best metric. What if there are multiple routes to the same destination with the same metric? EIGRP can load-balance over a maximum of 6 such equal cost paths. By default it is configured to load balance between 4 paths. This can be changed using the following command:
Router(config)#router eigrp 1
Router(config-router)#maximum-paths 6

As mentioned earlier EIGRP has a maximum hop count of 255 but the default maximum hop count is 100. This can be changed using the following command:
Router(config)#router eigrp 1
Router(config-router)#metric maximum-hops 255
The number 255 can be anything from 1 to 255.
EIGRP can be disabled on an interface using the "passive-interface <interface>" command in the EIGRP configuration mode. This will stop EIGRP from sending and receiving Hello packets on an interface. This means that EIGRP will not for adjacency on that interface and hence will not send or receive routes.

Lab Scenario

We want to use EIGRP in the network shown in Figure 2. Your task is to configure EIGRP on all routers such that:
  • Traffic from 192.168.1.0/24 never goes through RouterC to reach 192.168.7.0/24
  • RouterB never load-balances between the two paths to 192.168.7.0/24
  • RouterA should not form adjacency if Hello packets are received on its fa0/1 interface
  • RouterC and RouterD should not form adjacency if Hello packets are received on their fa0/2 interfaces.
Apart from the restrictions above, all routers should know about all the networks. AS 100 should be used across the network.

Figure 2


Lab Objectives

  • Configure EIGRP is AS 100 on all routers and advertise all connected routes
  • Set maximum hop to 2 on RouterA
  • Set maximum-paths to 1 on RouterB
  • Configure fa0/1 as passive on RouterA
  • Configure fa0/2 as passive on RouterC and RouterD


Lab Solution

First we need to enable EIGRP on all routers and advertise their connected routes:
RouterA(config)#router eigrp 100
RouterA(config-router)#network 192.168.1.0
RouterA(config-router)#network 192.168.2.0

RouterB(config)#router eigrp 100
RouterB(config-router)#network 192.168.2.0
RouterB(config-router)#network 192.168.3.0
RouterB(config-router)#network 192.168.5.0

RouterC(config)#router eigrp 100
RouterC(config-router)#network 192.168.3.0
RouterC(config-router)#network 192.168.4.0
RouterC(config-router)#network 192.168.6.0
RouterD(config)#router eigrp 100
RouterD(config-router)#network 192.168.5.0
RouterD(config-router)#network 192.168.6.0
RouterD(config-router)#network 192.168.7.0
We need to ensure that traffic from 192.168.1.0/24 never cross RouterC on the way to 192.168.7.0/24. RouterB will have the path form RouterC as a feasible successor to 192.168.7.0/24. This path will be advertised to RouterA if RouterB's fa0/2 link goes down.
The difference between the two paths for RouterA is the hop count. If we restrict the hop count to 2 on RouterA then the path to 192.168.7.0/24 from RouterC will never be used because its hop count is higher.
RouterA(config)#router eigrp 100
RouterA(config-router)#metric maximum-hops 2
We can stop RouterB from load-balancing by setting maximum-paths to 1 instead of default 4 :
RouterB(config)#router eigrp 100
RouterB(config-router)#maximum-paths 1
Finally we can make the given interfaces passive by using the following commands:
RouterA(config)#router eigrp 100
RouterA(config-router)#passive-interface fa0/1
RouterC(config)#router eigrp 100
RouterC(config-router)#passive-interface fa0/2
RouterD(config)#router eigrp 100
RouterD(config-router)#passive-interface fa0/2

Let's verify configuration by looking at the routing table of each router:
RouterA#show ip route
--output truncated--
Gateway of last resort is not set
D    192.168.4.0/24 [90/309760] via 192.168.2.2, 00:01:59, FastEthernet0/0
D    192.168.5.0/24 [90/284160] via 192.168.2.2, 00:01:59, FastEthernet0/0
D    192.168.6.0/24 [90/309760] via 192.168.2.2, 00:01:59, FastEthernet0/0
D    192.168.7.0/24 [90/286720] via 192.168.2.2, 00:01:59, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/1
C    192.168.2.0/24 is directly connected, FastEthernet0/0
D    192.168.3.0/24 [90/307200] via 192.168.2.2, 00:01:59, FastEthernet0/0
RouterB#show ip route
--output truncated--
Gateway of last resort is not set
D    192.168.4.0/24 [90/284160] via 192.168.3.2, 00:02:12, FastEthernet0/1
C    192.168.5.0/24 is directly connected, FastEthernet0/2
D    192.168.6.0/24 [90/284160] via 192.168.5.2, 00:02:12, FastEthernet0/2
D    192.168.7.0/24 [90/30720] via 192.168.5.2, 00:02:12, FastEthernet0/2
D    192.168.1.0/24 [90/307200] via 192.168.2.1, 00:02:12, FastEthernet0/0
C    192.168.2.0/24 is directly connected, FastEthernet0/0
C    192.168.3.0/24 is directly connected, FastEthernet0/1
RouterC#show ip route
--output truncated--
Gateway of last resort is not set
C    192.168.4.0/24 is directly connected, FastEthernet0/2
D    192.168.5.0/24 [90/284160] via 192.168.3.1, 00:03:22, FastEthernet0/1
C    192.168.6.0/24 is directly connected, FastEthernet0/0
D    192.168.7.0/24 [90/284160] via 192.168.6.2, 00:03:21, FastEthernet0/0
D    192.168.1.0/24 [90/332800] via 192.168.3.1, 00:02:49, FastEthernet0/1
D    192.168.2.0/24 [90/307200] via 192.168.3.1, 00:03:22, FastEthernet0/1
C    192.168.3.0/24 is directly connected, FastEthernet0/1
RouterD#show ip route
--output truncated--
Gateway of last resort is not set
D    192.168.4.0/24 [90/284160] via 192.168.6.1, 00:03:35, FastEthernet0/0
C    192.168.5.0/24 is directly connected, FastEthernet0/1
C    192.168.6.0/24 is directly connected, FastEthernet0/0
C    192.168.7.0/24 is directly connected, FastEthernet0/2
D    192.168.1.0/24 [90/332800] via 192.168.5.1, 00:02:59, FastEthernet0/1
D    192.168.2.0/24 [90/307200] via 192.168.5.1, 00:03:35, FastEthernet0/1
D    192.168.3.0/24 [90/307200] via 192.168.6.1, 00:03:35, FastEthernet0/0
                    [90/307200] via 192.168.5.1, 00:03:35, FastEthernet0/1
We can further verify the configuration using "show ip protocols" command:
RouterA#sh ip protocols
Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 2
  EIGRP maximum metric variance 1
  Redistributing: eigrp 100
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Automatic address summarization:
    192.168.1.0/24 for FastEthernet0/0
  Maximum path: 4
  Routing for Networks:
    192.168.1.0
    192.168.2.0
  Passive Interface(s):
    FastEthernet0/1
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.2.2           90      00:06:31
  Distance: internal 90 external 170
RouterB#sh ip protocols
Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 100
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Automatic address summarization:
    192.168.5.0/24 for FastEthernet0/0, FastEthernet0/1
    192.168.3.0/24 for FastEthernet0/0, FastEthernet0/2
    192.168.2.0/24 for FastEthernet0/1, FastEthernet0/2
  Maximum path: 1
  Routing for Networks:
    192.168.2.0
    192.168.3.0
    192.168.5.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.3.2           90      00:07:25
    192.168.2.1           90      00:07:26
    192.168.5.2           90      00:07:26
  Distance: internal 90 external 170
RouterC#show ip protocols
Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 100
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Automatic address summarization:
    192.168.6.0/24 for FastEthernet0/1
    192.168.4.0/24 for FastEthernet0/0, FastEthernet0/1
    192.168.3.0/24 for FastEthernet0/0
  Maximum path: 4
  Routing for Networks:
    192.168.3.0
    192.168.4.0
    192.168.6.0
  Passive Interface(s):
    FastEthernet0/2
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.3.1           90      00:09:16
    192.168.6.2           90      00:09:16
  Distance: internal 90 external 170
RouterD#show ip protocols
Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 100
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Automatic address summarization:
    192.168.7.0/24 for FastEthernet0/0, FastEthernet0/1
    192.168.6.0/24 for FastEthernet0/1
    192.168.5.0/24 for FastEthernet0/0
  Maximum path: 4
  Routing for Networks:
    192.168.5.0
    192.168.6.0
    192.168.7.0
  Passive Interface(s):
    FastEthernet0/2
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.5.1           90      00:10:08
    192.168.6.1           90      00:10:08
  Distance: internal 90 external 170
References:

Enhanced Interior Gateway Routing Protocol
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml
Configuring EIGRP
http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfeigrp.html