Monday, September 7, 2015

VoIP- CUCM Express: Advanced Features, H323 and SIP Trunks Configuration.



Introduction:

  In this lab, I will introduce you how to configure several call features including call-transfer, hunt groups, call park, call pickup, paging groups, paging/intercom, Music on Hold (MoH). Then, I will implement the auto-QoS and cRTP as well as show you how to configure VTP (VLAN trunking protocol) so you can add, delete and modify VLAN on a single switch and have that VLAN information propagate into the VLAN database on other switches within the VTP domain. Finally, I will show you how to configure H323 and SIP trunks between voice gateways using specific codecs.

Network Topology:
                                                              
                                                               Figure 1: Lab Topology.



                                                           
                                                         Figure 2: Lab device connectivity.

Equipment List:

- Site A:
Ra: Cisco router 3750.
SWA, SWA1: Cisco router 3750, included NM-16ESW card, operates as Switch 3560.
DNS_A: VPCS operates as DNS Server.
IP phone A1, A2, A3:  VPCS operates as Cisco IP Phone 7960.

- Site B:
Rb: Cisco router 3750.
SWB: Cisco router 3750, included NM-16ESW card, operates as Switch 3560.
DNS_B: VPCS operates as DNS Server
IP phone B1, B2, B3:  VPCS operates as Cisco IP Phone 7960.

- Site C:
Rc: Cisco router 3750.
SWC: Cisco router 3750, included NM-16ESW card, operates as Switch 3560.
DNS_C: VPCS operating as DNS Server
IP phone C1, C2, C3:  VPCS operates as Cisco IP Phone 7960.

For more information: GSN3-tutorial.

Overview:

- VoIP is a technology that allows phone calls to be reliably made over a packet-switched network. As we know,  human voice is analog signals that need to be transmitted over IP environment. So, this analog signals need to be converted into digital signals for transmission and be converted back to analog signals at the other side so called person can hear the voice. There are 2 main reasons for us to deal with digital circuits: One deals with inefficiencies of analog because we can't compress the analog signals for transmission in order to reduce the bandwidth. The other reason is that there is a distance limitation with analog signals. The longer distance, the degrader it's sufferred. we can address this degraded problem by using a electrical repeater that its job is to listen to the electrical signals coming in one end and reproduce the signals out the other. However, while this may work to extend analog distances a bit farther, they stop becoming productive at a certain point. This is because repeaters can interpret electrical pulses called noise on the wire and falsely assume they are part of the signal to be repeated. This noise gets retransmitted by the repeater and be carried to other side.
-   Four steps are necessary to transform an analog signal into a compressed digital signal. 
The steps always occur in the following order: 
     1. Sample the analog voice signal.   
     2. Quantize the sample.   
     3. Encode the digital sample.   
     4. Compress the encoded sample (optional).


Figure 3: Analog to Digital Conversion Process.

- In reality, DSP resources provide analog-to-digital translation, codec transcoding, echo cancellation, DTMF-Relay Services, and Media termination points. Because DSPs are responsible for analog-to-digital conversion, they are required on voice gateway that sits between the legacy PSTN network and the VoIP network. Moreover, when two VoIP devices wish to talk to one another over the IP network, both need to be able to understand the codec that is being used. If one VoIP end unit uses a codec that the other end unit does not understand, a DSP can be used to transcode  the stream into a codec that is supported. DSP resources are also used to assist in the elimination of echo when converting from one voice signal into another. Besides, it may be necessary to allow your IP endpoints to use DTMF to communicate with non-VoIP-based services. DTMF-relay can be used to facilitate this conversion. There are several methods for configuring DTMF-relay. All of them require the use of DSPs to properly transport the DTMF tone uncompressed over an IP network. When using H.323 or SIP endpoints or gateways, you can use DSP resources to assist with the process of functions such as call holds, parks, transfers, and conferences. These supplementary services are referred to as  media termination points.
- In order to encode and decode the quantized samples, we use intelligent algorithms called a codec (compressor/decompressor). We usually use some popular codecs:
+ G711: ITU standard codec is known as pulse code modulation (PCM). This codec samples voice signals at a frequency of 8,000 samples per second. There are 2 types G711 codec: G711 u-law is used in US, Canada and Japan while G711 a-law is used elsewhere on the planet.  Each phone call on the network requires 64 Kbps on the wire, and there is no compression when it encodes the voice stream.
+ G729: ITU standard codec samples the voice signal at the same rate as G.711 of 8,000 samples per second per the Nyquist rate theorem. Also like G.711, the bit rate is fixed at 8 per sample. The major difference between G.711 and the variations of G.729 has to do with compression. G.729's use of CS ACELP allows the compressed voice signal to require only 8 Kbps per call as opposed to 64 Kbps required per stream of G.711. However, the quality of the voice signal is not quite good and sound  likes robotic.
 While G711 is considered as medium complexity, G729 is considered as high complexity. High- complexity codecs use more DSP processing power than medium-complexity codecs.
- It is important to know that VoIP uses IP for routing decisions, UDP for packet delivery, and RTP/RTCP for real-time transport. While RTP is used for the transport of voice packets on a Unified Communications system and uses even numbered UDP port (e.g port 22864), RTCP is responsible for out-of-band monitoring of the RTP packets and uses the next-highest odd-numbered UDP port (e.g port 22865). You also need to understand how the CUCM solution handles the signaling responsibilities for voice endpoints. VoIP endpoint signaling protocols are responsible for locating endpoints, negotiation of various functions, and the setup and teardown of voice calls. You must be familiar with some endpoint signaling protocols below:


Figure 4: Voice signaling protocols

- In VoIP world, there are many things that need to be discussed such as Dialing Plan, Signaling protocols, QoS and so on. I've just mentioned some important points so that we can understand what happened underlying the VoIP calls.

Configuration:

Based on the Lab diagram in Figure 1, and refer to VoIP-Cisco Unified Communications Manager Express (CUCME)  for configuration of step 1 to 6 below:

Step 1: Build the lab Topology.
Step 2: Perform basic device configuration.
- On each router and switch:
•  Set the hostname as indicated on the topology diagram
•  Set the enable secret to class
•  Disable DNS lookups
•  Set a Telnet and Console password of cisco 
•  Set IP addresses as indicated on the above chart
- On each switch:
•  Create VLAN 10 with the name VOICE
•  Create VLAN 20 with the name DATA
•  Create VLAN 99 with the name MANAGEMENT
•  Configure VTP on SWA and SWA1:

 The purpose of VTP is  that we can add, delete and modify VLAN on a single switch, for example SWA, and have that VLAN information propagate into the VLAN database on other switches, for example SWA1, within its VTP domain. There are 3 VTP modes:
VTP Server: 
 VTP server mode allows an administrator to add, delete, and modify VLANs on the network over trunked links. All changes are propagated to other switches within the VTP domain. VTP server is the default VTP mode on all Cisco switches.   
VTP Client: 
  VTP client mode listens to the VTP server and copies its VLAN settings to its own VLAN database. It also forwards the VTP update messages from the server to other switches within the same VTP domain on its trunked links. This mode does not allow you to add, delete, or modify VLANs.   
VTP Transparent: 
  VTP transparent  mode basically disables VTP on the switch. You can add, delete, and modify VLAN information on the switch, but it never propagates this information to any other switch. Also, if the switch in this mode receives VTP update messages from other switches it is trunked with, it ignores the updates locally but will pass them on to connected neighbors.
  The VTP configuration on SWA and SWA1 as below
 Step 1:
SWA:
   VTP Mode: Server  
   VTP Version: 2
   VTP Domain: voip 
   VTP Password: cisco  
 SWA1:
   VTP Mode: Client
   VTP Version: 2
   VTP Domain: voip  
   VTP Password: cisco
On SWA:
SWA#vlan database
SWA(vlan)#vtp server
SWA(vlan)#vtp v2-mode
V2 mode enabled.
SWA(vlan)#vtp domain voip
SWA(vlan)#vtp password cisco
On SWA1:
SWA#vlan database
SWA(vlan)#vtp client
SWA(vlan)#vtp v2-mode
V2 mode enabled.
SWA(vlan)#vtp domain voip
SWA(vlan)#vtp password cisco

 Step 2:
 Configure 802.1Q trunking on Fa3/14 interface of SWA and SWA1
On SWA:
SWA(config)#int f3/14
SWA(config-if)#switchport trunk encapsulation dot1q
SWA(config-if)#switchport mode trunk
SWA(config-if)#no shut
On SWA1:
SWA1(config)#int f3/14
SWA1(config-if)#switchport trunk encapsulation dot1q
SWA1(config-if)#switchport mode trunk
SWA1(config-if)#no shut
 After creating VLAN 10, 20, 99 on SWA, these vlans will be propagated into vlan database on SWA1.
SWA1#show vtp status
VTP Version                     : 2
Configuration Revision          : 2
Maximum VLANs supported locally : 68
Number of existing VLANs        : 8
VTP Operating Mode              : Client
VTP Domain Name                 : voip
VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Enabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x68 0xC6 0x4B 0xA9 0xE6 0x84 0x2A 0x57
Configuration last modified by 172.16.99.2 at 3-1-02 00:18:36
SWA1#show vlan-switch
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa3/0, Fa3/1, Fa3/2, Fa3/3
                                                Fa3/4, Fa3/5, Fa3/6, Fa3/7
                                                Fa3/8, Fa3/9, Fa3/10, Fa3/11
                                                Fa3/12, Fa3/13, Fa3/14, Fa3/15
10   VLAN0010                         active
20   VLAN0020                         active
99   VLAN0099                         active
1002 fddi-default                     active
1003 trcrf-default                    active
1004 fddinet-default                  active
1005 trbrf-default                    active

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1    enet  100001     1500  -      -      -        -    -        1002   1003
10   enet  100010     1500  -      -      -        -    -        0      0
20   enet  100020     1500  -      -      -        -    -        0      0
99   enet  100099     1500  -      -      -        -    -        0      0
1002 fddi  101002     1500  -      -      -        -    -        1      1003
1003 trcrf 101003     4472  1005   3276   -        -    srb      1      1002
1004 fdnet 101004     1500  -      -      1        ibm  -        0      0
1005 trbrf 101005     4472  -      -      15       ibm  -        0      0
VLAN AREHops STEHops Backup CRF
---- ------- ------- ----------
1003 7       7       off

- On each DNS Server:
•  Configure a static IP address.
VPCS[1]> ip 172.16.20.100 172.16.20.1 24
Checking for duplicate address...
PC1 : 172.16.20.100 255.255.255.0 gateway 172.16.20.1
VPCS[1]> 2
VPCS[2]> ip 172.17.20.100 172.17.20.1 24
Checking for duplicate address...
PC2 : 172.17.20.100 255.255.255.0 gateway 172.17.20.1
VPCS[2]> 3
VPCS[3]> ip 172.18.20.100 172.18.20.1 24
Checking for duplicate address...
PC3 : 172.18.20.100 255.255.255.0 gateway 172.18.20.1

- On each IP Phone:
•  Configure to receive IP address via DHCP.
VPCS[4]> ip dhcp
DDORA IP 172.16.20.2/24 GW 172.16.20.1
VPCS[4]> 5
VPCS[5]> ip dhcp
DDORA IP 172.18.20.2/24 GW 172.18.20.1
VPCS[5]> ip dhcp
DORA IP 172.16.20.3/24 GW 172.16.20.1
VPCS[5]> 6
VPCS[6]> ip dhcp
DDORA IP 172.16.20.4/24 GW 172.16.20.1
VPCS[6]> 7
VPCS[7]> ip dhcp
DDORA IP 172.17.20.3/24 GW 172.17.20.1
VPCS[7]> 8
VPCS[8]> ip dhcp
DDORA IP 172.17.20.4/24 GW 172.17.20.1
VPCS[8]> 9
VPCS[9]> ip dhcp
DDORA IP 172.17.20.5/24 GW 172.17.20.1

  Note that VPCS supports only 9 PCs using udp ports. If we want to configure more IP phones in the lab, we can create MS Loopback adapter and apply on cloud devices that operate as IP Phones. Furthermore, these IP Phones cannot make call because they are actually cloud devices. But they can obtain IP address via DHCP from routers within DATA VLAN instead of VOICE VLAN because GSN3 simulator doesn't support IP Phone devices as Cisco Packet tracer does. In this lab, I used GNS3 simulator to show you how to configure advanced features in CUCME. However, we won't find these features on Cisco routers if we use Cisco Packet tracer simulator.
 As I said, GNS3 doesn't support IP Phone devices. However, you can even connect to virtual machines running on your computer inside VMware or Virtual PC. Then you run Cisco soft IP Phones that can talk to themselves. You can also connect GSN3 simulator to a real PC with MS Loopback interface as well. I have sucessfully registered the Cisco IP Communicator 7.0.4.0 that ran on real PC when connecting to GNS3 simulator via MS Loopback interface with DN 4001. Furthermore, I have already registered the Cisco IP Communicator 7.0.4.0 that ran on window XP based virtualbox via bridged adapter MS Loopback interface with DN 4002. Then I made a call from DN 4001 to DN 4002.

Ra#sh telephony-service
CONFIG (Version=3.3)
=====================
Version 3.3
Cisco CallManager Express
For on-line documentation please see:
www.cisco.com/univercd/cc/td/doc/product/access/ip_ph/ip_ks/index.htm

ip source-address 172.16.10.1 port 2000
max-ephones 5
max-dn 5
max-conferences 8 gain -6
dspfarm units 0
dspfarm transcode sessions 0
hunt-group report delay 1 hours
max-redirect 5
time-format 12
date-format mm-dd-yy
timezone 0 Greenwich Standard Time
keepalive 30
timeout interdigit 10
timeout busy 10
timeout ringing 180
caller-id name-only: enable
web admin system name Admin
web admin customer name Customer
edit DN through Web:  disabled.
edit TIME through web:  disabled.
Log (table parameters):
     max-size: 150
     retain-timer: 15
auto assign 1 to 5
local directory service: enabled.

Ra#sh telephony-service ephone
Number of Configured ephones 2 (Registered 1)
ephone 1
mac-address 0200.4C4F.4F50
type CIPC
button  1:1
!
ephone 2
mac-address 0800.27BE.48DE
type CIPC
button  1:2
!

Ra#sh telephony-service ephone-dn

ephone-dn 1
number 4001
preference 0 secondary 9
huntstop
call-waiting beep

ephone-dn 2
number 4002
preference 0 secondary 9
huntstop
call-waiting beep

ephone-dn 3
number 4003
preference 0 secondary 9
huntstop
call-waiting beep


Figure 5: Local call between Cisco IP Communicator 7.0.4.0

Step 3: Configure DHCP service on the Routers.
Step 4: Enable basic VoIP service on each router.
Step 5: Configure the pool of directory numbers on each router. 
Step 6: Configure switch interfaces. 
Step 7: Configure site-to-site calling: H323 and SIP trunks.




Monday, August 24, 2015

VoIP-Cisco Unified Communications Manager Express (CUCME)


Introduction:

 In this lab, I will introduce you how to configure Cisco Unified Communications Manager Express (CUCME) in a basic two site topology. You'll learn how to create vlan, configure trunk ports and switch ports as well as provide power supply to the IP Phones using PoE on switches. Moreover, You'll also learn how to configure DHCP, enable VoIP service and create directory numbers (DNs) on each router. Especially, you will have an opportunity to learn how to configure site-to-site calling (H323 trunk) so we are able to make call between Site A and Site B.

Network Topology:


Figure 1: Lab Topology.
 Equipment List:

- Site A:
RouterA1: Cisco router 2811.
SwitchA1: Cisco switch 3560-24PS
IP phoneA1, and A2: Cisco IP Phone 7960
PC A1

- Site B:
RouterB1: Cisco router 2811.
SwitchB1: Cisco switch 2960-24T
IP phoneB1, and B2: Cisco IP Phone 7960
Home VoIPB1: Analog Telephone Adapter (ATA)
Analog PhoneB1: Cisco Analog phone.
PC B1

Configuration:

 Step 1: Build the lab Topology.
  Build the lab topology as the figure 1. Note that the IP Phones at site A will be receiving Power over Ethernet (PoE) from the Switch (3560) but the IP Phones at site B should be configured with Power Supply.

Step 2: Perform basic device configuration.
- On each router and switch:
•  Set the hostname as indicated on the topology diagram
•  Set the enable secret to class
•  Disable DNS lookups
•  Set a Telnet and Console password of cisco 
•  Set IP addresses as indicated on the above chart
- On each switch:
•  Create VLAN 10 with the name VOICE
•  Create VLAN 20 with the name DATA
•  Create VLAN 99 with the name MANAGEMENT
- On each PC:
•  Configure to receive IP address via DHCP

*  Site A configuration:
Switch 3560:
Switch(config)#hostname SwitchA1
SwitchA1(config)#no ip domain lookup
SwitchA1(config)#line console 0
SwitchA1(config-line)#password cisco
SwitchA1(config-line)#exec-timeout 0 0
SwitchA1(config-line)#exit
SwitchA1(config)#line vty 0 4
SwitchA1(config-line)#password cisco
SwitchA1(config-line)#login
SwitchA1(config-line)#exit
SwitchA1(config)#enable secret class 
SwitchA1(config)#vlan 10
SwitchA1(config-vlan)#name VOICE
SwitchA1(config-vlan)#vlan 20
SwitchA1(config-vlan)#name DATA
SwitchA1(config-vlan)#vlan 99
SwitchA1(config-vlan)#name MANAGEMENT
SwitchA1(config-vlan)#exit
SwitchA1(config)#int vlan 99
SwitchA1(config-if)#
%LINK-5-CHANGED: Interface Vlan99, changed state to up
SwitchA1(config-if)#ip address 172.16.99.2 255.255.255.0

 Router 2811:
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#hostname RouterA1
RouterA1(config)#enable sec class
RouterA1(config)#no ip domain lookup
RouterA1(config)#line con 0
RouterA1(config-line)#pass cisco
RouterA1(config-line)#exec-timeout 0 0
RouterA1(config-line)#exit
RouterA1(config)#line vty 0 4
RouterA1(config-line)#pass cisco
RouterA1(config-line)#login
RouterA1(config-line)#exit
RouterA1(config)#int fa0/1
RouterA1(config-if)#ip address 10.0.0.1 255.255.255.0
RouterA1(config-if)#no shut
%LINK-5-CHANGED: Interface FastEthernet0/1, changed state to up
RouterA1(config-if)#int fa0/0
RouterA1(config-if)#no shut
%LINK-5-CHANGED: Interface FastEthernet0/0, changed state to up
RouterA1(config-if)#int fa0/0.10
%LINK-5-CHANGED: Interface FastEthernet0/0.10, changed state to up
RouterA1(config-subif)#encapsulation dot1Q 10
RouterA1(config-subif)#ip address 172.16.10.1 255.255.255.0
RouterA1(config-subif)#no shut
RouterA1(config-subif)#int fa0/0.20
%LINK-5-CHANGED: Interface FastEthernet0/0.20, changed state to up
RouterA1(config-subif)#encapsulation dot1Q 20
RouterA1(config-subif)#ip address 172.16.20.1 255.255.255.0
RouterA1(config-subif)#no shut
RouterA1(config-subif)#int fa0/0.99
%LINK-5-CHANGED: Interface FastEthernet0/0.99, changed state to up
RouterA1(config-subif)#encapsulation dot1Q 99 native
RouterA1(config-subif)#ip address 172.16.99.1 255.255.255.0
RouterA1(config-subif)#no shut

 Switch 2960 and router 2811 are configured similarly on site B.

Step 3: Configure DHCP service on the Routers.
  The VoIP devices and PCs need to receive IP addressing information by DHCP. Each router will need to act as the DHCP server for its location. We will be separating the voice and data networks at each location so we will need two DHCP pools. The special DHCP option 150 is used to send the CUCME address to the VoIP devices so they can register and receive configuration information. Even though this option is only required on the Voice VLAN we have included it on the Data VLAN in case soft-phones are ever used on the PCs. 
  The commands to setup the DHCP pools on RouterA1 are given below. You will have to modify them as appropriate for RouterB1 and apply them there as well.

RouterA1(config)#ip dhcp pool VOICE
RouterA1(dhcp-config)#network 172.16.10.0 255.255.255.0
RouterA1(dhcp-config)#default-router 172.16.10.1
RouterA1(dhcp-config)#option 150 ip 172.16.10.1
RouterA1(dhcp-config)#exit
RouterA1(config)#ip dhcp pool DATA
RouterA1(dhcp-config)#network 172.16.20.0 255.255.255.0
RouterA1(dhcp-config)#default-router 172.16.20.1
RouterA1(dhcp-config)#option 150 ip 172.16.10.1

Step 4: Enable basic VoIP service on each router:
 The DHCP option 150 instructs the VoIP devices receiving addresses to contact the router for registration and configuration information. We must next configure the router to provide voice service to those devices. Enable the VoIP service and set the maximum number of VoIP devices and directory numbers to 5 on each router. We will also allow phones to self-register and get an extension number automatically from directory numbers 1-5. Finally, the outgoing IP and port number for VoIP traffic from the router must be selected. The example configuration commands for RouterA1 are given below. Modify and apply to router B1 as well. 

RouterA1(config)#telephony-service
RouterA1(config-telephony)#max-ephones 5
RouterA1(config-telephony)#max-dn 5
RouterA1(config-telephony)#auto-reg-ephone
RouterA1(config-telephony)#auto assign 1 to 5
RouterA1(config-telephony)#ip source-address 172.16.10.1 port 2000

Step 5: Configure the pool of directory numbers on each router. 
  Each site will have a unique pool of directory (extension) numbers for each phone. On physical equipment it is possible to have overlapping dial plans (the same extension numbers duplicated at both sites) and then use a special prefix to dial between sites, but this is not supported by Cisco Packet Tracer simulation tool. We will need to ensure that each phone in the topology has a unique number. The numbers at site A will all start with 4xxx and at site B they should all start with 5xxx. Below is the configuration for one of the directory numbers at site A. Create enough (correctly numbered) directory numbers at each site to support all of the VoIP devices at that site.

RouterA1(config)#ephone-dn 1
RouterA1(config-ephone-dn)#%LINK-3-UPDOWN: Interface ephone_dsp DN 1.1, changed state to up
RouterA1(config-ephone-dn)#number 4001
RouterA1(config-ephone-dn)#ephone-dn 2
RouterA1(config-ephone-dn)#%LINK-3-UPDOWN: Interface ephone_dsp DN 2.1, changed state to up
RouterA1(config-ephone-dn)#number 4002

Step 6: Configure switch interfaces. 
 Trunk Ports: 
Configure an 802.1Q trunk link from FastEthernet 0/1 on each switch to the router. 
Access Ports: 
 All of the remaining ports on each switch should be configured as access ports in the DATA VLAN and should have PortFast enabled. The ports should all be shutdown for security reasons unless they have a device plugged into them. Enter this configuration as you normally would on the switches at both sites. Remember that there are shortcuts to configuring multiple interfaces on a switch the same way. Because we want to have our IP phones on a different VLAN than our PCs we need to perform a special configuration on all the access switch ports to turn them into two VLAN trunks when IP phones are identified by CDP. Leave the ports in switchport mode access but add a special second VLAN to them for voice traffic.

SwitchA1(config)#int fa0/1
SwitchA1(config-if)#switchport trunk encapsulation dot1q
SwitchA1(config-if)#switchport mode trunk
SwitchA1(config-if)#int range fa0/2-24
SwitchA1(config-if-range)#switchport access vlan 20
SwitchA1(config-if-range)#switchport mode access
SwitchA1(config-if-range)#switchport voice vlan 10
SwitchA1(config-if-range)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast will be configured in 23 interfaces due to the range command
but will only have effect when the interfaces are in a non-trunking mode.
SwitchA1(config-if-range)#
  At site A we also need to provide power to the IP phones using PoE:

SwitchA1(config-if-range)#power inline auto
 Because SwitchA1 does not support port-security so I couldn't configure this feature on this switch. However, you can do it on SwitchB1 as below:

SwitchB1(config)#int rang fa0/2-24
SwitchB1(config-if-range)#switchport port-security 

Step 7: Test the configuration.
 At this point you should have enough configuration done for communications within each site to be working so this is a good place to stop and test your work. The first thing to check is to ensure all your devices have IP addresses in the appropriate subnets. Note that after you enable all the ports it will take some time for all the devices to attempt requesting a DHCP address again so if you don’t see addresses right away wait a couple minutes and check again. You can easily check the addresses of IP phones and PCs by hovering your mouse over the device in PT (Packet Tracer) and checking the listed IP and gateway addresses. You can further check connectivity by pinging one of the interfaces on the router at the same site from each PC. Once your IP phones have IP addresses they should automatically contact the CUCME software running on the router (using the option 150 address), register, and get an extension number. You can verify the extension number of each IP phone by hovering your mouse over the phone and looking for a Line Number or by opening the phone and checking on the upper right of the display on the GUI tab. Note that the Analog Telephone Adapter (ATA) at site B does not use DHCP option 150 to find the CUCME server. You will have to enter the correct server address on the Config tab of the ATA before the analog phone will receive an extension number. Once all your devices have extension numbers you can try placing a call between devices at the same site. Click on one of the IP phones and switch to the GUI tab. Open up the same window for another IP phone at the same site and place it next to the first window so you can see both phones at the same time. Enter the extension number of the other phone on the dial pad of one phone and click on the receiver to place the call. The other phone should indicate that it is ringing and the number of the extension which is calling should appear on the display. Click the receiver on this phone to answer the call. The display should now show the phones are Connected. If you look to the upper right of each phone (you may have to scroll over to the right) you should see Do, Re, Mi buttons. Pressing one of these simulates talking into the phone. If you press one you should see a message above the phone you are connected to like Playing ‘Do’… for a short while after you press it. This indicates the connection between the phones is working properly.
 Now, I will try to make a local call on site A from IP Phone with ext. 4001 to the IP Phone with ext. 4002.


Then, off-hook the phone with ext. 4002


Step 8: Configure site-to-site calling (H323 trunk).
 To enable site-to-site dialing we must make each of the two CUCME systems aware of the other so that they can facilitate a connection between phones. Even though the CUCME systems manage the connection the voice traffic is not required to flow through them (though it does in this topology when a call is being made site-to-site). Because of this the first thing we need to do is make sure that every device at each site will be able to reach all of the devices at the other site. Add the appropriate routes to each router to enable routing between the sites. The most best way to do this is with a single /16 summary route on each of the routers to manually summarize the addresses found at the other site. Once you have the appropriate routes installed and have tested by successfully pinging from the PC at one site to the PC at the other site we need to setup VoIP call routing between sites. This link is made by what is called a dial-peer which identifies specific destination extensions and directs them to another CUCME server in much the same way a routing table works for IP traffic. We must also identify what extension numbers to direct to the other server, something done with a destination-pattern. Examine the dial-peer configuration given for RouterA1 below and then enter it into RouterA1.

RouterA1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RouterA1(config)#router rip
RouterA1(config-router)#version 2
RouterA1(config-router)#network 172.16.0.0
RouterA1(config-router)#network 10.0.0.0
RouterA1(config-router)#no auto
RouterA1(config-router)#dial-peer voice 1 voip
RouterA1(config-dial-peer)#destination-pattern 5...
RouterA1(config-dial-peer)#session target ipv4:10.0.0.2

  This will identify all extensions which start with a 5 followed by three other digits and direct them to the CUCME server running on RouterB1. Make the appropriate changes to this configuration and then apply it to RouterB1 to allow the VoIP devices at site B to call site A as well.
 Test your configuration by calling from site A to site B and from site B to site A.
 Now, I will try to make a remote call from IP Phone with ext. 4001 on site A to the IP Phone with ext. 5001 on site B.


Then, off-hook the phone with ext. 5001.


Now, I will try to make a remote call from IP Phone with ext. 5002 on site B to the IP Phone with ext. 4002 on site A.


Then, off-hook the phone with ext. 4002.


Well-done! Now, I want to challenge you by making some or all of these modifications to what you have done so far: 
•  Add another VoIP device (IP phone or ATA) to site A 
•  Setup specific devices to receive specific extension (directory) numbers. For example, make sure that IP Phone A1 always receives extension 4001 and IP ATA B1 always receives extension 5003 
instead of allowing devices to auto register. Hint: Exploring your running configurations on the routers after you have everything working should provide some hints about how to do this. 
•  Setup a multiuser Packet Tracer configuration and enable calling between your two sites and a 
partner’s two sites 
•  Add a third site and enable calling between all three sites 
•  Add quality of service (QoS) to the network to prioritize voice traffic over data traffic 

Conclusions:
 In this lab, you've learned how to build a lab to make call from site to site by using function CUCME on Cisco router. Specifically, you learned how to create vlan, configure trunk ports and switch ports as well as provide power supply to the IP Phones using PoE on switches. Moreover, you also learned how to configure DHCP, enable VoIP service and create directory numbers (DNs) on each router. Finally, you learned how to configure dynamic routing protocol RIPv2 and dial-peer on each router so we can make call from site to site by using H323 trunk.

Tuesday, August 18, 2015

CCIE Lab1, Section 2


Section 2: IPv4 IGP Protocols

Section 2.1: OSPF



Requirements:

■  Use  a process  ID of 1; all OSPF  configuration where  possible  should not be configured  under  the process  ID. Do not change the preconfigured interface types where  applicable, The Loopback  interfaces of Routers R1, R2, and R3 should  be configured  to be  in Area  0. R4 should  be in Area 34 and R5 in Area 5. 
■  All Loopback  networks  should  not be advertised  as host  routes. 
■  Ensure  that R1 does not advertise  the preconfigured  secondary  address  under  interface Gigabit  1/0 of 120.100.100.1/24 to  the OSPF  network.  Do not use any  filtering  techniques to achieve  this. 
■  R5 should  use  the Frame Relay  link within Area 5 for  its primary communication  to the OSPF network. If this network should fail either  at Layer  1 or Layer  2, R5 should  form  a neighbor relationship  with R4 under Area  5 to maintain connectivity. Your solution should  be dynamic ensuring  that while  the Area 5 Frame  Relay  link  is operational there  is no neighbor  relationship between R4 and R5; however,  the Ethernet  interfaces  of R4 and R5 must remain up. To confirm the operational  status  of the Frame  Relay  network, you  should  ensure  that the  serial interface of R5 is reachable by configuration  of R5. You  are permitted  to define neighbor  statements between  R5 and R4.

Configuration:

■  Use  a process  ID of 1; all OSPF  configuration where  possible  should not be configured  under  the process  ID. Do not change the preconfigured interface types where  applicable, The Loopback  interfaces of Routers R1, R2, and R3 should  be configured  to be  in Area  0. R4 should  be in Area 34 and R5 in Area 5.

  Recent  advances  in OSPF have enabled configuration  of the network  area directly  under  the  interface  as opposed  to within the OSPF process.

R1(config)#  interface GigabitEthernet 1/0
R1(config-if)#  ip ospf 1 area 100
R1(config)#  interface  Serial  6/0
R1(config-if)#  ip ospf 1 area 0
R1(config-if)#  interface Loopback  0
R1(config-if)#  ip ospf 1 area 0

R2(config)#  interface Loopback 0
R2(config-if)#  ip ospf 1 area 0
R2(config-if)#  interface  Serial  6/0
R2(config-if)#  ip ospf 1 area 0
R2(config-if)#  interface  Serial  6/1
R2(config-if)#  ip ospf 1 area 5
R2(config-if)#  interface FastEthernet  3/1
R2(config-if)#  ip ospf 1 area 200

R3(config)#  interface  loopback  0
R3(config-if)#  ip ospf 1 area 0
R3(config-if)#  interface  Serial  6/0
R3(config-if)#  ip ospf 1 area 0
R3(config-if)#  interface GigabitEthernet  0/0
R3(config-if)#  ip ospf 1 area 34

R4(config)#  interface Loopback 0
R4(config-if)#  ip ospf 1 area 34
R4(config-if)#  interface GigabitEthernet  0/0
R4(config-if)#  ip ospf 1 area 34
R4(config-if)#  interface GigabitEthernet  1/0.45
R4(config-if)#  ip ospf 1 area 5

R5(config)#  interface Loopback 0
R5(config-if)#  ip ospf 1 area 5
R5(config-if)#  interface GigabitEthernet  0/0
R5(config-if)#  ip ospf 1 area 5
R5(config-if)#  interface  Serial  6/1
R5(config-if)#  ip ospf 1 area 5.

 Since Frame Relay NBMA networks won’t allow broadcasts or multicasts, an OSPF router will not attempt to dynamically discover any OSPF neighbors on the Frame Relay interface. Also, since this means that elections won’t be allowed, you’d have to statically confgure OSPF neighbors, plus the R2 router would need to be configured as a DR. Even though these are serial links, an NBMA network behaves like Ethernet and a DR is needed to exchange routing information. Only the R2 router can act as a DR because it would have the PVCs for all other routers. But the easiest way to fix this problem is to use the command ip ospf network point-to-multipoint on all router Frame Relay interfaces—not just the R2 router, but all branches too! Moreover, if the neighbor relationship is not formed, we also need to check the Hello and the Dead interval timers.

R1#show ip ospf int s6/0
Serial6/0 is up, line protocol is up
  Internet Address 120.100.123.1/24, Area 0, Attached via Interface Enable
  Process ID 1, Router ID 120.100.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 5208
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           5208      no          no            Base
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:18
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 2/3, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 120.100.3.1
  Suppress hello for 0 neighbor(s)

R3#show ip ospf int s6/0
Serial6/0 is up, line protocol is up
  Internet Address 120.100.123.3/24, Area 0, Attached via Interface Enable
  Process ID 1, Router ID 120.100.3.1, Network Type POINT_TO_MULTIPOINT, Cost: 5208
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           5208      no          no            Base
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:10
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 2/3, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 2, Adjacent neighbor count is 2
    Adjacent with neighbor 120.100.1.1
    Adjacent with neighbor 120.100.2.1
  Suppress hello for 0 neighbor(s)

 We can the Hello timer, if there is a mismatch timers by using the command below:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int 6/0
R3(config-if)#ip ospf hello-interval 30
R3(config-if)#^Z

R3#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
120.100.2.1       0   FULL/  -        00:01:59    120.100.123.2   Serial6/0
120.100.1.1       0   FULL/  -        00:01:58    120.100.123.1   Serial6/0
120.100.4.1       1   FULL/DR         00:00:38    120.100.34.4    GigabitEthernet0/0


■  All Loopback  networks  should  not be advertised  as host  routes.

Loopback interfaces within OSPF will by default be advertised as host routes. To manipulate  this behavior you need to override the network type that the IOS associates with the Loopback interface.  The output below shows that the host routes learned from R2. Note that 120.100.123.3/32 is actually a host route generated by OSPF for the Frame Relay connection, so this is expected behavior and acceptable  in the routing table.

R2#sh ip route | inc /32
O        120.100.1.1/32 [110/10417] via 120.100.123.3, 00:24:51, Serial6/0
L        120.100.2.1/32 is directly connected, Loopback0
O        120.100.3.1/32 [110/5209] via 120.100.123.3, 00:25:06, Serial6/0
O        120.100.5.1/32 [110/5209] via 120.100.25.5, 00:25:06, Serial6/1
L        120.100.25.2/32 is directly connected, Serial6/1
O        120.100.25.5/32 [110/5208] via 120.100.25.5, 00:25:06, Serial6/1
O        120.100.123.1/32 [110/10416] via 120.100.123.3, 00:24:51, Serial6/0
L        120.100.123.2/32 is directly connected, Serial6/0
O        120.100.123.3/32 [110/5208] via 120.100.123.3, 00:25:06, Serial6/0
L        150.100.2.1/32 is directly connected, FastEthernet3/1

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int l0
R1(config-if)#ip ospf network point-to-point

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int l0
R2(config-if)#ip ospf network point-to-point

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int l0
R3(config-if)#ip ospf network point-to-point

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int l0
R4(config-if)#ip ospf network point-to-point

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#int l0
R5(config-if)#ip ospf network point-to-point

R2#sh ip route ospf 1 | include /24
O        120.100.1.0/24 [110/10417] via 120.100.123.3, 01:31:32, Serial6/0
O        120.100.3.0/24 [110/5209] via 120.100.123.3, 01:33:36, Serial6/0
O IA     120.100.4.0/24 [110/5219] via 120.100.123.3, 00:15:18, Serial6/0
O        120.100.5.0/24 [110/5209] via 120.100.25.5, 01:31:47, Serial6/1
O IA     120.100.34.0/24 [110/5218] via 120.100.123.3, 01:33:36, Serial6/0
O        120.100.45.0/24 [110/5209] via 120.100.25.5, 01:31:47, Serial6/1
O IA     150.100.1.0/24 [110/10426] via 120.100.123.3, 01:31:32, Serial6/0

■  Ensure  that R1 does not advertise  the preconfigured  secondary  address  under  interface Gigabit  1/0 of 120.100.100.1/24 to  the OSPF  network.  Do not use any  filtering  techniques to achieve  this. 
 The associated  behavior with configuring OSPF directly  under the  interface  is that  it will by default  advertise  any secondary addresses assigned  to the  interface.  R1 has a preconfigured secondary address  on interface Gigabit  1/0 that  is therefore  advertised. Because  you cannot  filter this advertisement,  you need  to inform OSPF not  to include  the secondary addresses  under  the interface command. 

  Adding a secondary address on g1/0 interface of R1

R1(config)#int g1/0
R1(config-if)#ip address 120.100.100.1 255.255.255.0 secondary
R1(config-if)#^Z
R1#sh ip ospf int g1/0
GigabitEthernet1/0 is up, line protocol is up
  Internet Address 150.100.1.1/24, Area 100, Attached via Interface Enable
  Process ID 1, Router ID 120.100.1.1, Network Type BROADCAST, Cost: 10
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           10        no          no            Base
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 120.100.1.1, Interface address 150.100.1.1
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:01
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

 Check the routing table on R2:

R2#sh ip route ospf | include /24
O        120.100.1.0/24 [110/10417] via 120.100.123.3, 01:31:32, Serial6/0
O        120.100.3.0/24 [110/5209] via 120.100.123.3, 01:33:36, Serial6/0
O IA     120.100.4.0/24 [110/5219] via 120.100.123.3, 00:15:18, Serial6/0
O        120.100.5.0/24 [110/5209] via 120.100.25.5, 01:31:47, Serial6/1
O IA     120.100.34.0/24 [110/5218] via 120.100.123.3, 01:33:36, Serial6/0
O        120.100.45.0/24 [110/5209] via 120.100.25.5, 01:31:47, Serial6/1
O IA     120.100.100.0/24 [110/10426] via 120.100.123.3, 00:01:52, Serial6/0
O IA     150.100.1.0/24 [110/10426] via 120.100.123.3, 01:31:32, Serial6/0

 In order to inform OSPF not to include  the secondary addresses  under  the interface command on R1, we can do:

R1(config)#int g1/0
R1(config-if)#ip ospf 1 area 100 secondaries none
Check  the 120.100.100.0 network on R2's routing table to see whether R1 stops advertising it or not.

R2#sh ip route 120.100.100.0
% Subnet not in table

■  R5 should  use  the Frame Relay  link within Area 5 for  its primary communication  to the OSPF  network. If  this  network should fail either  at Layer  1 or Layer  2, R5 should  form  a neighbor  relationship  with R4 under Area  5 to maintain connectivity. Your solution should  be dynamic,  ensuring  that while  the Area 5 Frame  Relay  link  is operational, there  is no neighbor  relationship between R4 and R5; however,  the Ethernet  interfaces  of R4 and R5 must remain up. To confirm  the operational  status  of the Frame  Relay  network, you  should  ensure  that the  serial interface of R5  is reachable by configuration  of R5. You are permitted  to define neighbor  statements between  R5 and R4.
 This  is a complex  scenario  that can consume your  time, but all the clues are  in the question,  so some  lateral  thinking  is required. You can  rule out a backup  interface  solution  because  the Ethernet  needs  to remain  up, and  the solution must cater for Layer 1 and Layer 2 rather  than purely Layer 1. Similarly, a demand scenario is also out because this would involve a neighbor relationship being formed. You are also requested to confirm operational status of the Frame Relay interface on R5 with your overall solution  being dynamic.  This would  take a great  deal of effort and  trial and error, but you will  find  that you can use  the  IP SLA  feature  to monitor  the  IP address  of the Frame Relay  interface  on R5 by R5 itself.  If this responds to the automatic polling with ICMP, you know the frame relay is up at Layers 1 and 2. (Layer  2 would also need  to be up for a valid  response  because  the  ICMP packet would be sent over  the Frame Relay  network,  and a local map  to R5’s own  IP address is required for this.)  If the polling fails, you know the interface is down.  IP SLA can  then be used  to inform  the router, and a forwarding  decision  can be manipulated;  this  feature  is known  as Policy-Based Routing (PBR)  support with multiple  Tracking Options.  This gives PBR access to all the objects that are available through  the  tracking process.
 The tracking process  provides the ability  to track  individual  objects,  such as ICMP ping  reachability, and inform  the required PBR process when  an object  state  changes.  In summary, if the object status changes, R5 can simply manipulate the way  it sends  traffic  by policy  routing. The  traffic  it manipulates  needs  to be OSPF  that should  be directed  to R4 to form the adjacency  over the Ethernet network  (VLAN45), so when R5 Frame Relay  is up and  running, we just need to break the adjacency  between  R5 and R4. When the Frame Relay fails, we need to allow the adjacency between  R5 and R4 to form. The first step in this solution is to configure the IP SLA object tracking on R5. Remember the additional map is needed locally, so it can ping  its own serial  interface;

R5(config)#  interface  s6/1
R5(config-if)#  frame-relay  map  ip 120.100.25.5 512 broadcast
R5(config-if)#  exit
R5(config)#  ip sla 1
R5(config-ip-sla)#  icmp-echo 120.100.25.5
R5(config-ip-sla-echo)#  ip sla schedule  1 life forever start-time  now
R5(config)#track 1 rtr 1 reachability

 OSPF  needs  to be  configured  between  R4  and R5 with manual  neighbor  statements  as directed  in  the  question,  which ensures  the routers  unicast  traffic  to  each  other.  To do  this  you  need  to  change  the  network  type  to nonbroadcast.  The unicast  traffic  between neighbors  can be  identified  by an ACL  that  the PBR  process  can match,  and  then  instead  of allowing  normal  traffic  flow  between R5  and R4  to  form  the  neighbor  relationship,  the next  hop  can  be modified  and  as the OSPF TTL  is set to 1 by default,  the  traffic will effectively  be dropped  by the next hop and  the OSPF between  R5 and R4 will never  establish.  Similarly,  when  the object  tracking  fails,  the PBR process will be overridden  and  traffic  can flow as normal.  This will  then allow R5 and R4  to form an OSPF  adjacency.  So by using  the PBR command set ip next- hop verify-availability  120.100.25.2  10 track 1, R5 can  forward  normal OSPF  traffic  to 120.100.25.2 (R2 Frame Relay  to effectively discard  the  traffic) if the tracked  object  (1)  is up. If the object  status  changes  to down,  the PBR process  is informed, and  the OPSF traffic  to 120.100.25.2  would  follow  the usual next hop. R5 must be configured  to locally  policy route traffic  because  normal  PBR behavior  is for traffic manipulation  for traffic  that  flows through the  router rather  than traffic  generated  by the router  itself. The following configuration shows  the  required OSPF  configuration  on R4 and R5,  the PBR on R5, a debug of R2 sending TTL  expired  to R5 after  the OSPF traffic  is sent  to R2 instead  of R5, and  the resulting neighbor partial  adjacency  that  is formed  between  R4 and R5.

R4(config)#int g1/0.45
R4(config-subif)#ip ospf network non-broadcast
R4(config-subif)#router ospf 1
R4(config-router)#neighbor 120.100.45.5

R5(config)#int g0/0
R5(config-if)#ip ospf network non-broadcast
R5(config-if)#router ospf 1
R5(config-router)#neighbor 120.100.45.4
R5(config-router)#exit
R5(config)#access-list 100 permit ospf host 120.100.45.5 host 120.100.45.4
R5(config)#route-map TEST permit 10
R5(config-route-map)#match ip address 100
R5(config-route-map)#set ip next-hop  verify-availability 120.100.25.2  10 track 1
R5(config-route-map)#int g0/0
R5(config-if)#ip policy route-map TEST
R5(config-if)#exit
R5(config)#ip local policy route-map TEST

R2#debug ip icmp
ICMP packet debugging is on

R5#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
120.100.2.1       0   FULL/  -        00:01:55    120.100.25.2    Serial6/1
N/A               0   ATTEMPT/DROTHER    -        120.100.45.4    GigabitEthernet0/0

  The following configuration shows  the OSPF  adjacency  formed when  the Frame Relay  between R2 and R5 is shut down on R5. The PBR is overridden and normal  routing  occurs  because  the next hop  is not verified  by the object  tracking. Your  routing  table needs to be an exact  replica  as below. You must  remember  that when  an OSPF adjacency  forms between  R5 and R2, you are joining Area 5 into Area 34 and a virtual-link  between  R3 and R4 is required  to extend area 0. If you hadn’t  configured  a virtual-link it would  have been an easy mistake that would  take your points  away.

R3(config)#router ospf 1
R3(config-router)#area 34 virtual-link 120.100.4.1

R4(config)#router ospf 1
R4(config-router)#area 34 virtual-link 120.100.3.1

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#int s6/1
R5(config-if)#shut
R5(config-if)#
*Aug 19 20:14:46.067: %OSPF-5-ADJCHG: Process 1, Nbr 120.100.2.1 on Serial6/1 from FULL to DOWN, Neighbor Down: Interface down or detached
R5(config-if)#
*Aug 19 20:14:48.031: %LINK-5-CHANGED: Interface Serial6/1, changed state to administratively down
*Aug 19 20:14:49.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial6/1, changed state to down
R5(config-if)#do show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
N/A               0   ATTEMPT/DROTHER    -        120.100.45.4    GigabitEthernet0/0
R5(config-if)#

R5#sh ip route ospf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      120.0.0.0/8 is variably subnetted, 15 subnets, 2 masks
O IA     120.100.1.0/24 [110/10481] via 120.100.25.2, 00:00:34, Serial6/1
O IA     120.100.2.0/24 [110/65] via 120.100.25.2, 00:00:34, Serial6/1
O IA     120.100.3.0/24 [110/5273] via 120.100.25.2, 00:00:34, Serial6/1
O IA     120.100.4.0/24 [110/5283] via 120.100.25.2, 00:00:34, Serial6/1
O        120.100.25.2/32 [110/64] via 120.100.25.2, 00:00:34, Serial6/1
O IA     120.100.34.0/24 [110/5282] via 120.100.25.2, 00:00:34, Serial6/1
O IA     120.100.123.1/32 [110/10480] via 120.100.25.2, 00:00:34, Serial6/1
O IA     120.100.123.2/32 [110/64] via 120.100.25.2, 00:00:34, Serial6/1
O IA     120.100.123.3/32 [110/5272] via 120.100.25.2, 00:00:34, Serial6/1
      150.100.0.0/16 is variably subnetted, 4 subnets, 2 masks
O IA     150.100.1.0/24 [110/10490] via 120.100.25.2, 00:00:34, Serial6/1
O IA     150.100.2.0/24 [110/74] via 120.100.25.2, 00:00:34, Serial6/1

Section 2.2: EIGRP

Thursday, August 13, 2015

CCIE Lab1, Section 1


Introduction:

 In this lab, I will introduce you a CCIE Lab configuration including 8 sections:

- Section 1: LAN Switching and Frame Relay.
- Section 2: IPv4 IGP Protocols.
- Section 3: BGP.
- Section 4: IPv6.
- Section 5: QoS.
- Section 6: Security.
- Section 7: Multicast.
- Section 8: IP Services.

Through this lab, you will learn L2, L3 switching and routing configuration from basic to high level. Because there are lots of topics mentioned in this lab, it requires you to have a fundamental knowledge of Switch and Router.

Network Topology:
Figure 1: Lab Diagram. 


Figure 2: Lab device connectivity.

  R1 Lo0 120.100.1.1/24        R6 Lo0 120.100.6.1/24      
R2 Lo0 120.100.2.1/24        SW1 Lo0 120.100.7.1/24
R3 Lo0 120.100.3.1/24        SW2 Lo0 120.100.8.1/24
R4 Lo0 120.100.4.1/24         SW3 Lo0 120.100.9.1/24
  R5 Lo0 120.100.5.1/24         SW4 Lo0 120.100.10.1/24

Figure 3: Lab topology details.

Equipment List:

- R1, R2, R3, R4, R5, R6: Cisco routers c7200.
- Sw1, Sw2, Sw3, Sw4: Cisco routers c3745 operating as 3550, 3560 Switches.


Figure 4: VLAN Assignment.


Figure 5: Frame Relay Logical Connectivity.

Section 1: LAN Switching and Frame Relay


Requirements:

■  Configure  your  switches as a collapsed  backbone  network  with Switches  1 and 2 performing  core  and distribution functionality and  Switches  3 and  4 as access  switches  in your  topology. Switches  3 and  4 should  connect only to the core switches.
■  Switch  1 and  2 should  run  spanning  tree  in 802.1w  mode;  Switches  3 and  4 should operate  in their  default  spanning-tree mode.  
■  Configure  Switch  1 to be the root bridge and Switch  2 the secondary root bridge for VLANs  1 and 300. Ensure  that Switches 3 and 4 can never  become  root bridges for any VLANs  for which Switch  1 and  Switch  2 are  root bridges by configuring  only Switches  1 and  2.  
■  Ensure  you  fully  utilize  the  available  bandwidth between  switches  by grouping  together  your  interswitch  links  as trunks. Ensure  that only dot1q  and EtherChannel are supported.
■  Ensure  traffic  is distributed on individual Ethernet  trunks  between  switches  based on  the destination MAC  address of individual flows.
■  Ensure  that user  interfaces  are shut  down  dynamically by all switches  should  they  toggle excessively; if they  remain stable for 35 seconds,  they  should  be reenabled. Configure  Fast Ethernet  Port 3/7 on each  switch so that  if multicast traffic  is received on this port,  the port  is automatically  disabled. 
■  Fast Ethernet  Ports  3/8  will be used for  future  connectivity on each  switch.  Configure these  ports as access ports for VLAN300, which  should  begin  forwarding  traffic  immediately on connection. Devices  connected  to these ports will dynamically  receive  IP addresses  from a DHCP  server  due  to be connected  to Port 3/9 on sw1.  For security purposes,  this is the only port on the network from which DHCP addresses  should  be allocated.  En-  sure the switches  intercept  the DHCP  requests and  add  the  ingress  port  and VLAN and  switch MAC address  prior to sending onward  to the DHCP  server.  Limit DHCP requests  to 600 packets  per minute  per user port.
■  For  additional  security ensure  the user ports on Switches  1–4 and 8 can communicate only with  the network with IP addresses  gained  from the DHCP  feature configured  previously.  Use a dynamic  feature  to ensure  the only information forwarded upon  connection is DHCP  request  packets,  then  any  traffic  that matches  the DHCP  IP  information received  from  the DHCP binding for  additional  security.  
■  R5 and R6 have  been  preconfigured  with  IP addresses on  their  Ethernet  interfaces. Configure R4  and  its associated switch port accordingly without  using secondary  addressing  to communicate with R5 and R6. Configure R4 with an IP address  of 120.100.45.4/24  to communicate with R5, and configure R4 with  an IP address  of 120.100.46.4/24 to communicate with R6. Configure R4 g1/0 and Switch  2 f3/4 only.  
■  Your  initial  Frame  Relay  configuration  has  been  supplied   for  the  R1-R2-R3   connectivity and  R2-R5.  Configure each device per  Figure  5  to ensure  each  device  is  reachable  over  the  Frame Relay  network.  Use  only  the  indicated DLCIs.  

Configuration:

■  Configure  your  switches as a collapsed  backbone  network  with Switches  1 and 2 performing  core  and distribution functionality and  Switches  3 and  4 as access  switches  in your  topology. Switches  3 and  4 should  connect only to the core switches.

This  is a simple  start  to the exercise.  The switches  are fully meshed  to begin with;  to create  a collapsed  backbone  topology, the core switches  should be connected together,  and each  access switch  should  be dual-homed  to the core switches. The only switches  that should  not connect directly  to each other would  be the access  switches  (Sw3  and Sw4). By shutting down  the interfaces  between Sw3 and Sw4, you create  the required  topology. Even  though  the resulting topology is not looped  at this stage, you can verify  route bridge  assignment  by using  the show spanning  tree root command.

SW3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW3(config)#int f3/14
SW3(config-if)#shut
SW3(config-if)#int f3/15
SW3(config-if)#shut
SW4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW4(config)#int f3/14
SW4(config-if)#shut
SW4(config-if)#int f3/15
SW4(config-if)#shut

■  Switch  1 and  2 should  run  spanning  tree  in 802.1w  mode;  Switches  3 and  4 should operate  in their  default  spanning-tree mode. 

 802.1w  is rapid  spanning  tree;  this  is backward  compatible  with  the switches'  default  (PVST), so by configuring  Switches 1 and 2 into rapid  spanning  tree mode,  spanning  tree can still operate  effectively  with Switches  3 and 4.

SW1(config)#spanning-tree mode rapid-pvst
SW2(config)#spanning-tree mode rapid-pvst

■  Configure  Switch  1 to be the root bridge and Switch  2 the secondary root bridge for VLANs  1 and 300. Ensure  that Switches 3 and 4 can never  become  root bridges for any VLANs  for which Switch  1 and  Switch  2 are  root bridges by configuring  only Switches  1 and  2. 

 This  is a straightforward question  for the core switches. The  root bridge  prioritization  root guard  is configured  on the ports  that connect  Switches 1 and 2 to Switches 3 and 4; this ensures  that  if a superior  BPDU  is received  on these  ports, it is ignored. 
  
SW1(config)#  spanning-tree  vlan 1 root primary 
SW1(config)# spanning-tree vlan 300 root primary 
SW1(config-if)# interface Fastethernet  3/10
SW1(config-if)#  spanning-tree  guard  root
SW1(config-if)#  interface Fastethernet  3/11
SW1(config-if)#  spanning-tree  guard  root
SW1(config-if)#  interface Fastethernet  3/12
SW1(config-if)#  spanning-tree  guard  root
SW1(config-if)#  interface Fastethernet  3/13
SW1(config-if)#  spanning-tree  guard  root

SW2(config)#  spanning-tree  vlan 1 root secondary
SW2(config)# spanning-tree vlan 300 root secondary
SW2(config-if)# interface Fastethernet  3/10
SW2(config-if)#  spanning-tree  guard  root
SW2(config-if)#  interface Fastethernet  3/11
SW2(config-if)#  spanning-tree  guard  root
SW2(config-if)#  interface Fastethernet  3/12
SW2(config-if)#  spanning-tree  guard  root
SW2(config-if)#  interface Fastethernet  3/13
SW2(config-if)#  spanning-tree  guard  root

■  Ensure  you  fully  utilize  the  available  bandwidth between  switches  by grouping  together  your  interswitch  links  as trunks. Ensure  that only dot1q  and EtherChannel are supported.

This  is another  straightforward question for all switches  to create EtherChannels  between  devices. Using  the command channel-group n mode on under  the physical  interfaces  ensures that only EtherChannel  is supported,  as opposed to pagp or lacp, and dot1q  is the trunking  protocol. For Layer 2 EtherChannels,  you don’t have  to create  a port-channel  interface first by using  the interface port-channel configuration  command  before  assigning  a physical  port  to a channel group. You can use  the channel-group interface  configuration  command  that automatically creates the port-channel interface,  although  a manual  port channel  configuration has been  shown  here  for clarity. Remember  that now  that you have Ether- Channels between  switches, you will need  to configure  root guard on these interfaces to ensure  that Switches 3 and 4 cannot become root bridges. This is over and above  the previous  physical interface configuration completed previously.

SW1(config)#  interface  Port-channel1
SW1(config-if)#  switchport trunk encapsulation dot1q
SW1(config-if)#  switchport mode trunk 
SW1(config-if)# spanning-tree  guard  root 
SW1(config-if)# interface Port-channel2
SW1(config-if)#  switchport trunk encapsulation dot1q
SW1(config-if)#  switchport mode trunk 
SW1(config-if)# spanning-tree  guard  root 
SW1(config-if)# interface Port-channel3
SW1(config-if)#  switchport trunk encapsulation dot1q
SW1(config-if)#  switchport mode  trunk
SW1(config-if)#  interface  range FastEthernet3/10-11
SW1(config-if)#  channel-group  1 mode  on
SW1(config-if)#  interface  range FastEthernet3/12-13
SW1(config-if)#  channel-group  2 mode  on
SW1(config-if)#  interface  range FastEthernet3/14-15
SW1(config-if)#  channel-group  3 mode  on

SW2(config)#  interface  Port-channel1
SW2(config-if)#  switchport trunk encapsulation dot1q
SW2(config-if)#  switchport mode  trunk
SW2(config-if)#  interface  Port-channel2
SW2(config-if)#  switchport trunk encapsulation dot1q
SW2(config-if)#  switchport mode  trunk
SW2(config-if)#  interface  Port-channel3
SW2(config-if)#  switchport trunk  encapsulation dot1q
SW2(config-if)#  switchport mode  trunk
SW2(config-if)#  interface  range FastEthernet3/10-11
SW2(config-if)#  channel-group  1 mode  on
SW2(config-if)#  interface  range FastEthernet3/12-13
SW2(config-if)#  channel-group  2 mode  on
SW2(config-if)#  interface  range FastEthernet3/14-15
SW2(config-if)#  channel-group  3 mode  on

SW3(config)#  interface  Port-channel1
SW3(config-if)#  switchport trunk encapsulation dot1q
SW3(config-if)#  switchport mode  trunk
SW3(config-if)#  interface  Port-channel2
SW3(config-if)#  switchport trunk encapsulation dot1q
SW3(config-if)#  switchport mode  trunk
SW3(config-if)#  interface  range FastEthernet3/10-11
SW3(config-if)#  channel-group  1 mode  on
SW3(config-if)#  interface  range FastEthernet3/12-13
SW3(config-if)#  channel-group  2 mode  on

SW4(config)#  interface  Port-channel1
SW4(config-if)#  switchport trunk encapsulation dot1q
SW4(config-if)#  switchport mode  trunk
SW4(config-if)#  interface  Port-channel2
SW4(config-if)#  switchport trunk encapsulation dot1q
SW4(config-if)#  switchport mode  trunk
SW4(config-if)#  interface  range FastEthernet3/10-11
SW4(config-if)#  channel-group  1 mode  on
SW4(config-if)#  interface  range FastEthernet3/12-13
SW4(config-if)#  channel-group  2 mode  on

SW1#show etherchannel summary
Flags:  D - down        P - in port-channel
        I - stand-alone s - suspended
        R - Layer3      S - Layer2
        U - in use
Group Port-channel  Ports
-----+------------+-----------------------------------------------------------
1     Po1(SU)     Fa3/10(P)  Fa3/11(P)
2     Po2(SU)     Fa3/12(P)  Fa3/13(P)
3     Po3(SU)     Fa3/14(P)  Fa3/15(P)

SW2#show etherchannel summary
Flags:  D - down        P - in port-channel
        I - stand-alone s - suspended
        R - Layer3      S - Layer2
        U - in use
Group Port-channel  Ports
-----+------------+-----------------------------------------------------------
1     Po1(SU)     Fa3/10(P)  Fa3/11(P)
2     Po2(SU)     Fa3/12(P)  Fa3/13(P)
3     Po3(SU)     Fa3/14(P)  Fa3/15(P)

SW3#show etherchannel summary
Flags:  D - down        P - in port-channel
        I - stand-alone s - suspended
        R - Layer3      S - Layer2
        U - in use
Group Port-channel  Ports
-----+------------+-----------------------------------------------------------
1     Po1(SU)     Fa3/10(P)  Fa3/11(P)
2     Po2(SU)     Fa3/12(P)  Fa3/13(P)

SW4#show etherchannel summary
Flags:  D - down        P - in port-channel
        I - stand-alone s - suspended
        R - Layer3      S - Layer2
        U - in use
Group Port-channel  Ports
-----+------------+-----------------------------------------------------------
1     Po1(SU)     Fa3/10(P)  Fa3/11(P)
2     Po2(SU)     Fa3/12(P)  Fa3/13(P)

■  Ensure  traffic  is distributed on individual Ethernet  trunks  between  switches  based on  the destination MAC  address of individual flows.

  A common problem with EtherChannels  is traffic not being distributed  equally  among  the physical interfaces.  Configuring channel load balancing  based on the destination  MAC  address  of an individual  flow  is just one method  available  to distribute traffic.

SW1(config)#  port-channel load-balance  dst-mac 
SW2(config)#  port-channel  load-balance  dst-mac 
SW3(config)#  port-channel load-balance dst-mac
SW4(config)# port-channel load-balance dst-mac

SW1#sh etherchannel load-balance
 Po1 ---> Destination MAC address
 Po2 ---> Destination MAC address
 Po3 ---> Destination MAC address

■  Ensure  that user  interfaces  are shut  down  dynamically by all switches  should  they  toggle excessively; if they  remain stable for 35 seconds,  they  should  be reenabled. Configure  Fast Ethernet  Port 3/7 on each  switch so that  if multicast traffic  is received on this port,  the port  is automatically  disabled.


  Interfaces  that  flap can cause  problems  in a network.  Toggling would  usually  indicate a problem such as a faulty  connecting NIC or faulty  cable;  placing  the ports  into error disable  is a method  of stabilizing  the environment.  To disable  a port when multicast traffic is present,  you need  to configure  storm control with  the multicast  option  set  to 0.

SW1(config)#  errdisable  recovery cause link-flap
SW1(config)#  errdisable  recovery interval 35
SW1(config)#  interface FastEthernet  3/7
SW1(config-if)#  storm-control multicast  level 0
SW1(config-if)#  storm-control  action shutdown

SW2(config)#  errdisable  recovery cause link-flap
SW2(config)#  errdisable  recovery interval 35
SW2(config)#  interface FastEthernet  3/7
SW2(config-if)#  storm-control multicast  level 0
SW2(config-if)#  storm-control  action shutdown

SW3(config)#  errdisable  recovery cause link-flap
SW3(config)#  errdisable  recovery interval 35
SW3(config)#  interface FastEthernet  3/7
SW3(config-if)#  storm-control multicast  level 0
SW3(config-if)#  storm-control  action shutdown

SW4(config)#  errdisable  recovery cause link-flap
SW4(config)#  errdisable  recovery interval 35
SW4(config)#  interface FastEthernet  3/7
SW4(config-if)#  storm-control multicast  level 0
SW4(config-if)#  storm-control  action shutdown

■  Fast Ethernet  Ports  3/8  will be used for  future  connectivity on each  switch.  Configure these  ports as access ports for VLAN300, which  should  begin  forwarding  traffic  immediately on connection. Devices  connected  to these ports will dynamically  receive  IP addresses  from a DHCP  server  due  to be connected  to Port 3/9 on sw1.  For security purposes,  this is the only port on the network from which DHCP addresses  should  be allocated.  Ensure the switches  intercept  the DHCP  requests and  add  the  ingress  port  and VLAN and  switch MAC address  prior to sending onward  to the DHCP  server.  Limit DHCP requests  to 600 packets  per minute  per user port.

  This  is a DHCP  Snooping  question. This  is a useful  security  feature  that protects  the network  from  rogue DHCP  servers.  When the DHCP  option-82  feature  is enabled  on the switch with  the command  ip dhcp  snooping  information  option,  a subscriber  is identified by the switch port  through which  it connects  to the network  and by its MAC  address. DHCP snooping also facilitates  a rate  limiting feature  for DHCP  requests  to prevent  a DHCP  denial  of service  by excessive false  requests  from a host, which would have the "gobbler  effect"  of requesting numerous  leases  from  the same  port. The question includes  a couple  of points  that could  easily  be overlooked  if you are suffering  from exam pressure, namely  the ports are  required  to be configured  with  switchport  host (or by configuring portfast)  to set the port mode  to access  and to 
forward immediately. The  rate limiting  is configured in packets  per second  not per minute  as implied,  so you would need  to pay attention  to detail.

SW1(config)#  ip dhcp  snooping
SW1(config)#  ip dhcp  snooping vlan 300
SW1(config)#  ip dhcp  snooping  information option
SW1(config)#  int fastEthernet  3/9
SW1(config-if)#  ip dhcp  snooping  trust
SW1(config)#  interface  fastEthernet  3/8
SW1(config-if)#  ip dhcp  snooping  limit rate 10
SW1(config)#  interface  range  fastEthernet  3/8-9
SW1(config-if-range)#  switchport host
SW1(config-if-range)#  switchport  access vlan 300

SW2(config)#  ip dhcp  snooping
SW2(config)#  ip dhcp  snooping vlan 300
SW2(config)#  ip dhcp  snooping  information option
SW2(config)#  interface fastEthernet  3/8
SW2(config-if)#  ip dhcp  snooping  limit rate 10
SW2(config-if)#  switchport host
SW2(config-if)#  switchport  access vlan 300

SW3(config)#  ip dhcp  snooping
SW3(config)#  ip dhcp  snooping vlan 300
SW3(config)#  ip dhcp  snooping  information option
SW3(config)#  interface  fastEthernet  3/8
SW3(config-if)#  ip dhcp  snooping  limit rate 10
SW3(config-if)#  switchport host
SW3(config-if)#  switchport  access vlan 300

SW4(config)#  ip dhcp  snooping
SW4(config)#  ip dhcp  snooping vlan 300
SW4(config)#  ip dhcp  snooping  information option
SW4(config)#  interface  fastEthernet  3/8
SW4(config-if)#  ip dhcp  snooping  limit rate 10
SW4(config-if)#  switchport host
SW4(config-if)#  switchport  access vlan 300

■  For  additional  security ensure  the user ports on Switches  1–4 and 8 can communicate only with  the network with IP addresses  gained  from the DHCP  feature configured  previously.  Use a dynamic  feature  to ensure  the only information forwarded upon  connection is DHCP  request  packets,  then  any  traffic  that matches  the DHCP  IP  information received  from  the DHCP binding for  additional  security.  

 A complementary feature  to DHCP  Snooping  is IP Source Guard. This  feature  binds  the  information  received  from  the DHCP address offered  and effectively  builds a dynamic VACL  on a per port basis  to enable  only source  traffic matched from  the DHCP offer to ingress  the switch  port  for additional  security.


SW1(config)#  int f3/8
SW1(config-if)#  ip verify source

SW2(config)#  int f3/8
SW2(config-if)#  ip verify source

SW3(config)#  int f3/8

SW3(config-if)#  ip verify source

SW4(config)#  int f3/8
SW4(config-if)#  ip verify source

■  R5 and R6 have  been  preconfigured  with  IP addresses on  their  Ethernet  interfaces. Configure R4  and  its associated switch port accordingly without  using secondary  addressing  to communicate with R5 and R6. Configure R4 with an IP address  of 120.100.45.4/24  to communicate with R5, and configure R4 with  an IP address  of 120.100.46.4/24 to communicate with R6. Configure R4 g1/0 and Switch  2 f3/4 only.  

  This  is just a simple  trunking  question  on Switch2  to R4 to enable  R4 to connect  to VLAN45  and VLAN46.  One point to remember is that Switch2  does not have VLAN45  and VLAN46 configured  locally within  the default  configuration, so you will need  to create  the VLANs  locally  prior  to configuring  the  trunk.


R4(config)#  interface GigabitEthernet1/0.45
R4(config-if)#  encapsulation  dot1Q  45
R4(config-if)#  ip address  120.100.45.4  255.255.255.0
R4(config-if)#  interface GigabitEthernet1/0.46
R4(config-if)#  encapsulation  dot1Q  46
R4(config-if)#  ip address  120.100.46.4  255.255.255.0

SW2#vlan database
SW2(vlan)#  vlan 45
SW2(vlan)#  vlan 46
SW2(vlan)#exit
APPLY completed.
Exiting....
SW2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW2(config)#  interface FastEthernet3/4
SW2(config-if)#  switchport trunk encapsulation dot1q
SW2(config-if)#  switchport trunk allowed vlan 45,46

SW2(config-if)#  switchport mode  trunk

■  Your  initial  Frame  Relay  configuration  has  been  supplied   for  the  R1-R2-R3   connectivity and  R2-R5.  Configure each device per  Figure  5  to ensure  each  device  is  reachable  over  the  Frame Relay  network.  Use  only  the  indicated DLCIs.  


  Make sure the interface IP address has been set for R1, R2, R3 and R5. All you need  to add  is maps on R1, R2 and R3 as well as R2 and R5 spokes to enable them  to communicate with each other. Depend on the question, R1 and  R2 also need to communicate each other.

R1#  conf  t
R1(config)#  int s6/0
R1(config-if)#encapsulation frame-relay ietf
R1(config-if)#  frame-relay  map  ip 120.100.123.2 103 broadcast
R1(config-if)#  frame-relay  map  ip 120.100.123.3 103 broadcast

R2#  conf  t
R2(config)#  int s6/0
R2(config-if)#encapsulation frame-relay ietf
R2(config-if)#  frame-relay  map  ip 120.100.123.1 203 broadcast
R2(config-if)#  frame-relay  map  ip 120.100.123.3 203 broadcast
R2(config-if)#exit
R2(config)#  int s6/1
R2(config-if)#encapsulation frame-relay ietf
R2(config-if)#  frame-relay  map  ip 120.100.25.5 215 broadcast

R3#  conf  t
R3(config)#  int s6/0
R3(config-if)#encapsulation frame-relay ietf
R3(config-if)#  frame-relay  map  ip 120.100.123.1 301 broadcast
R3(config-if)#  frame-relay  map  ip 120.100.123.2 302 broadcast

R5#  conf  t
R5(config)#  int s6/1
R5(config-if)#encapsulation frame-relay ietf
R5(config-if)#  frame-relay  map  ip 120.100.25.2 315 broadcast

R1#ping 120.100.123.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 120.100.123.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 780/940/1088 ms
R1#ping 120.100.123.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 120.100.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 232/456/580 ms

R2#ping 120.100.25.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 120.100.25.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 384/568/800 ms