4 ip services span,rspan

TRAINER: SAGAR | NetworkJourney.com | www.youtube.com/c/NetworkJourney | LinkedIN
CCNP ENTERPRISE 2020 LAB WORKBOOK|| TRAINER: SAGAR || WWW.YOUTUBE.COM/C/NETWORKJOURNEY
TOPICS COVERED:
IP SERVICES
- NTP [NETWORK TIME PROTOCOL]
- DHCP
- ADVANCE DHCP
- NAT/PAT
- SPAN / RSPAN / ERSPAN

NETWORK TIME PROTOCOL [NTP]
KEY POINTS:
• NTP is a term which is stands for Network Time Protocol
• NTP is used to allow network devices to synchronize clocks with central source clock.
• NTP make sure logging information and timestamps have the accurate time and date.
• Network Time Protocol (NTP) is runs over User Datagram Protocol [UDP 123]
• Network Time Protocol (NTP) uses a hierarchical system of time sources.
• Network Time Protocol (NTP) uses client-server architecture to work.
• Currently there are two versions of NTP version 3 and NTP version 4.
• A Network Time Protocol (NTP) server is also referred to as an NTP Master.
• Router can be configured in three modes Server, Client and Server/Client mode.
• By default, Router works in Network Time Protocol (NTP) Server/Client mode.
• Stratum defines the reliability and accuracy of Network Time Protocol source.
• Network Time Protocol (NTP) uses of stratum 0 to stratum 15 for NTP sources.
• One 1 is the most reliable and 15 is the worst Network Time Protocol source.
• Stratum 0 represents Atomic Clock and not used in Cisco Router or Cisco Switch.
• Stratum 1 to 15 are valid levels and used in Cisco Routers and Cisco Switches.
• Stratum 16 represents Network Time Protocol (NTP) is not synchronized.
• Default stratum level of Cisco Router’s or Switches internal clock is 8.
• Syslog messages timestamp using the Network Time Protocol (NTP).

NTP Stratum:
• NTP, stratum levels define the distance from the reference clock.
• A Stratum-0 device that is assumed to be most accurate and it has no delay.
• Network Time Protocol Stratum-0 servers cannot be used on the network.
• For example, a device with Network Time Protocol stratum 1 is very accurate device.
• Network Time Protocol (NTP) Stratum 1 might have an atomic clock attached to it.
• Another NTP using stratum 1 server to synchronize own time would be a stratum 2 device.
• Because stratum 2 is one Network Time Protocol (NTP) hop further away from the source.
• Configure multiple NTP servers, client will prefer NTP server with lowest stratum value.
NTP Architecture:
• NTP uses stratums 1 to 16 to define clock accuracy.
• A lower NTP stratum value represents higher accuracy.
• Clocks at NTP stratums 1 through 15 are in synchronized state.
• Clocks at Network Time Protocol stratum 16 are not synchronized.
• Stratums is like TTL number decreases every hop a packet passes by.

NTP Modes:
• Cisco Routers and Cisco Switches can use four (4) different NTP modes.
• NTP Server, NTP Client, NTP Server/Client and NTP Peer or Symmetric Active mode.
NTP Server Mode:
• NTP server is a network device, which is running NTP service.
• NTP server is configured to provide Time information to NTP clients.
• NTP server provide only Time information to NTP Clients.
• NTP server never accept time synchronization information from other devices.
• NTP server mode router reads time from NTP source or uses its own clock as NTP source.
NTP Client Mode:
• NTP Client mode, Router only receives NTP updates.
• NTP Client does not advertise received updates.
• NTP Client uses them to synchronize its own clock.
NTP Server/Client Mode:
• NTP Server/Client, Router receives updates from NTP server.
• NTP Server/Client also advertises them from its own interfaces.
• NTIP Server/Client mode Cisco Router or Switch plays both roles.
• As NTP Client, it receives NTP updates & as NTP Server, it advertises NTP updates.
• NTP Server/Client mode, as an NTP Server, instead of using its own NTP Source.
• NTP router uses received NTP updates from other NTP server.
• NTP Server advertise the NTP updates to other NTP Clients.
• This feature allows using a single centralized NTP source at NTP Server.
NTP Peer Mode:
• An NTP peer does not have authority over the other.
• In NTP peer mode, each device can provide time synchronization to other.
• So, one can synchronize the other in case of failures.
NTP Master:
• To make a router to become an authoritative NTP server.
• Where internal devices can synchronize use NTP master command.
• NTP master command tells router that it is an NTP server.
• NTP server is also referred to as an NTP Master.
• If it is using its hardware clock is a reference.
NTP Versions:
• Cisco IOS use many versions, but version 3 & 4 are most commonly used.

• Version 4 supports IPv6 and is backwards compatible with NTP version 3.
• Network Time Protocol (NTP) Version 4 also adds DNS support for IPv6.
• Another difference is that NTPv3 use broadcast messages & NTPv4 use multicast.
• NTPv4 also allows for increased security using public key cryptography and certificates.
NTP Security & Authentication:
• NTP communications can be secured using an Access Control List.
• NTP can be secured by authentication mechanism that uses MD5 algorithm.
• All NTP packets that can update the clock have to be authenticated.
• The packets will be authenticated using HMAC MD5, which carries a key number.
• To use ACL, write ACL to allow certain IP addresses or a range then apply to NTP.
GNS3:
INITIAL CONFIG:
Router(config)#hostname NTPCORE01
NTPCORE01(config)#int e0/0
NTPCORE01(config-if)#ip add dhcp
NTPCORE01(config-if)#no shut
NTPCORE01(config-if)#int e0/3
NTPCORE01(config-if)#ip add 192.168.1.98 255.255.255.0
NTPCORE01(config-if)#no shut
Switch(config)#hostname NTPCLIENT01
NTPCLIENT01(config)#int gi0/0

NTPCLIENT01(config-if)#no switchport
NTPCLIENT01(config-if)#ip add 192.168.1.99 255.255.255.0
NTPCLIENT01(config-if)#no shut
Switch(config)#hostname NTPCLIENT02
NTPCLIENT01(config)#int gi2/0
NTPCLIENT01(config-if)#no switchport
NTPCLIENT01(config-if)#ip add 192.168.1.100 255.255.255.0
NTPCLIENT01(config-if)#no shut
NTP CONFIG STARTS HERE:
Adjust Router Clock
NTPCORE01# show calendar
NTPCORE01# show clock
NTPCORE01# show clock detail
NTPCORE01# clock set 1:20:11 Feb 20 2020
Configure NTP Server
NTPCORE01 (config)# ntp master 3
NTPCORE01 (config)# interface e0/3
NTPCORE01 (config-if)# ntp broadcast
NTPCORE01# show clock detail
Configure NTP Server/Client
NTPCLIENT02(config)# interface gi0/0
NTPCLIENT02(config)# ntp broadcast
Ntp broadcast client
NTPCLIENT01 (config)#ntp server 192.168.1.100 version 3
NTPCLIENT01# show clock
NTPCLIENT01# show clock detail
Configure NTP Client
NTPCLIENT02(config)#ntp server 192.168.1.1 version 3
NTPCLIENT02(config)# interface gi2/0
NTPCLIENT02(config)# ntp broadcast client
NTPCLIENT02# show clock
NTPCLIENT02# show clock detail
Configure NTP Peer
NTPCLIENT01(config)# ntp peer 192.168.1.100
NTPCLIENT02(config)# ntp peer 192.168.1.99
NTPCLIENT01(config)# ntp peer 192.168.1.100 version 3

NTPCLIENT02(config)# ntp peer 192.168.1.99 version 3
NTPCLIENT01#show ntp associations
Configure Authentication on NTP Server
NTPCORE01(config)# ntp master 5
NTPCORE01(config)# ntp authenticate
NTPCORE01(config)# ntp trusted-key 1
NTPCORE01(config)# ntp authentication-key 1 md5 cisco123
Configure Authentication on NTP Client
NTPCLIENT01 (config)# ntp server 192.168.1.100 key 1
NTPCLIENT01 (config)# ntp authenticate
NTPCLIENT01 (config)# ntp trusted-key 1
NTPCLIENT01 (config)# ntp authentication-key 1 md5 cisco123
Configure Authentication on NTP Peer
NTPCLIENT02(config)# ntp peer 192.168.1.99 key 1
NTPCLIENT02(config)# ntp authenticate
NTPCLIENT02(config)# ntp trusted-key 1
NTPCLIENT02(config)# ntp authentication-key 1 md5 cisco123
NTPCLIENT02# debug ntp packet
NTPCLIENT02# debug ntp auth
Configure ACL on NTP Server
NTPCORE01 (config)# access-list 1 permit 8.8.8.8
NTPCORE01 (config)# ntp access-group peer 1
NTPCORE01 (config)# ntp access-group serve-only 11
Configure ACL on NTP Client
NTPCLIENT01(config)# access-list 3 permit 192.168.1.98
NTPCLIENT01(config)# ntp access-group peer 3
VERIFICATION:
NTPCORE01(config)#do sh clock
04:22:55.983 UTC Wed Jan 1 2020
NTPCLIENT01(config)#do sh clock
*04:22:05.540 UTC Wed Jan 1 2020
NTPCLIENT02(config)#do sh clo
*04:22:24.554 UTC Wed Jan 1 2020
NTPCLIENT01(config)#do sh ntp associations
address ref clock st when poll reach delay offset disp
*~192.168.1.98 127.127.1.1 3 35 64 1 2.694 24460.6 188.54
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

NTPCLIENT01(config)#
Field Description
characters in
display lines
* —Synchronized to this peer
# —Almost synchronized to this peer
+ —Peer selected for possible synchronization
- —Peer is a candidate for selection
~ —Peer is statically configured
Address Address of peer.
ref clock Address of reference clock of peer.
St Stratum of peer.
When Time since last NTP packet was received from peer.
Poll Polling interval (in seconds).
Reach Peer reachability (bit string, in octal).
Delay Round-trip delay to peer (in milliseconds).
Offset Relative time of peer clock to local clock (in milliseconds).
Disp Dispersion
NTPCLIENT01(config)#do sh ntp packets
Ntp In packets : 19
Ntp Out packets : 20
Ntp bad version packets : 19
Ntp protocol error packets : 0
NTPCLIENT01(config)#do sh ntp status
Clock is synchronized, stratum 4, 192.168.1.98
nominal freq is 1000.0003 Hz, actual freq is 1000.0003 Hz, precision is 2**14
ntp uptime is 60000 (1/100 of seconds), resolution is 1000
reference time is E1B69D71.8023BE97 (04:24:17.500 UTC Wed Jan 1 2020)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.07 msec, peer dispersion is 0.00 msec
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
system poll interval is 64, last update was 72 sec ago.
Field Description
Synchronized System is synchronized to an NTP peer.
Unsynchronized System is not synchronized to any NTP peer.
Stratum NTP stratum of this system.
Reference Address of peer the system is synchronized to.
nominal freq Nominal frequency of system hardware clock.
actual freq Measured frequency of system hardware clock.

Precision Precision of the clock of this system (in Hertz).
reference time Reference time stamp.
clock offset Offset of the system clock to synchronized peer.
root delay Total delay along path to root clock.
root dispersion Dispersion of root path.
peer dispersion Dispersion of synchronized peer.
Troubleshoot and Verify NTP:
To verify NTP there many commands to use some of them are the following:
show ntp status
show ntp associations
show ntp associations detail
debug ntp packet
debug ntp events
debug ntp authentication

SYSLOG
• Syslog stands for System Logging, standard protocol used to send system log.
• Cisco network devices Routers and Switches use Syslog to send system messages.
• Cisco network devices use debug output to a local logging process inside the device.
• Syslog is used on a variety of devices to give system information to the system admin.
• Most Cisco devices use the syslog protocol to manage system logs and system alerts.
• Logging can be used for fault notification, network forensics, and security auditing.
• Syslog messages can be output to the console, local buffer or a remote syslog serve.
• Logs can include content flow, configuration changes and new software installs etc.
• Logging helps to detect unusual network traffic, network device failures, issue etc.
• Syslog uses port UDP 514
The syslog logging service provides three primary capabilities:
1. Gathering logging information for monitoring and troubleshooting
2. Selecting the type of logging information that is captured
3. Specifying the destinations of captured syslog messages

Syslog message format
seq no: timestamp: %facility-severity-MNEMONIC: description
Example: 00:00:46: *Feb 20 01:45:15.706: %LINK-3-UPDOWN: Interface Port-channel1,
changed state to up
The service sequence-numbers command was not configured, but the service
timestamps command was configured. The facility is LINK, the severity is 3, and the
MNEMONIC is UPDOWN.

CONFIGURE SYSLOG IN 3-STEPS:
To configure the router to send system messages to a syslog server, complete the following
three steps:
Step 1. Configure the IP address of the syslog server in global configuration mode:
R1(config)# logging 192.168.1.3
Step 2.
R1(config)# logging trap 4
or
R1(config)# logging trap warning
Step 3. Optionally, configure the source interface with the logging source-interface
interface-type interface-number global configuration mode command. This specifies that
syslog packets contain the address of a specific interface, regardless of which interface the
packet uses to exit the router. For example, to set the source interface to g0/0, use the
following command:
R1(config)# logging source-interface g0/0
COMMAND TO SEE “LOGGING” OUTPUT IN CISCO DEVICES:
#Show logging
GNS3

TASK #1 FOLLOW THE LAB FROM PREVIOUS “NTP” SECTION
TASK #2 CONFIGURE “192.168.1.151/24” on SYSLOG SERVER AS SHOWN ABOVE TOPOLOGY
TASK #3 CONFIGURE THE REQUIRED CLI COMMAND ON “NTPCLIENT02”
NTPCLIENT02(config)#loggin host 192.168.1.151
NTPCLIENT02(config)#logging trap 4
TASK #4 GOTO SYSLOG SERVER AND ANALYSE PACKETS
root@SYSLOG:~# cat /var/log/syslog
Jun 25 15:45:17 192.168.1.100 105: *Feb 20 01:45:15.706: %CDP-4-DUPLEX_MISMATCH: duplex
mismatch discovered on GigabitEthernet2/0 (not half duplex), with AGGRSW01 Ethernet2/0 (half
duplex).
WIRESHARK CAPTURE SCREENSHOT:
OPTIONAL SYSLOG CLI COMMANDS:
Router#config t
Router(config)#logging host <snmp-server-ip>
Router(config)#service timestamps log datetime [msec] [localtime] [show-timezone]
Router(config)#service sequence-numbers
Router(config)#logging buffered 16483
Router(config)#logging <ip.of.syslog.server>
Router(config)#logging console <level>
Router(config)#logging monitor <level>
Router(config)#logging trap <level>
Router(config)#logging history <level>
Router(config)#logging history size <1 to 500>
Router(config)#logging rate-limit <seconds> all except <level>
Router(config)#end
Router#terminal monitor
Router#show running-config
Router#show logging
Router#show logging history

DHCP [DYNAMIC HOST CONTROL PROTOCOL]
• DHCP is an abbreviation for Dynamic Host Configuration Protocol.
• Cisco IOS features known as Easy IP Lease which is full-featured DHCP server.
• DHCP is a client server protocol that automatically provides an IP to hosts.
• DHCP also provide IP, subnet mask, default gateway, DNS server & other config.
• DHCP allows a network device to dynamically receive IP address parameters.
• DHCP process follows DORA process, Discover, Offer, Request & Acknowledgement.
• DHCP is application layer protocol used by hosts for obtaining network setup information.
• DHCP Server dynamically configures a host or Network device in a network.
• DHCP is Client server protocol, which uses User Datagram Protocol services.
• DHCP port number for server is UDP port 67 and for the client is UDP port 68.
• DHCP assigned Internet Protocol (IP) address from a pool (range) of addresses.
• Dynamic Host Configuration Protocol (DHCP) is an application layer protocol.
Dynamic Automatically
Host Any computer that is connected to the network
Configuration To configure a host means to provide network information
Protocol Set of rules and regulation
Advantages of DHCP:
• Primary advantage of DHCP is easier management of IP addresses.
• Centralized network client configuration.
• DHCP greatly reduce the time required to configure & reconfigure computers.
• DHCP Server assigning IP addresses automatically avoid configuration errors.
• Ease of adding new clients to a network.
• Reuse of IP addresses reducing the total number of IP addresses.
• No need to reconfigure each client separately.
• Configure the network from a centralized area.
• Easy handling of new users and reuse of IP address can be achieved.
IOS DHCP Server:
• Cisco devices running Cisco software include DHCP server.
• Cisco router can be used as a DHCP server and the various options available.
• Cisco IOS routers and layer 3 switches can be configured as DHCP server.
• The Cisco IOS DHCP server is a full DHCP server implementation.
• Cisco IOS DHCP assigns and manages IP addresses from specified address pools.
• Cisco IOS DHCP server can be configured to assign additional parameters as well.
• DHCP server is the one responsible for handing out IPs to the clients.
DHCP Client:
• DHCP client is a host using DHCP to obtain configuration parameters.
• The endpoint that receives configuration information from a DHCP server.

• DHCP client is anything needing an IP address that is not configured as a static.
• Cisco routers can be configure as both DHCP servers and DHCP clients.
• DHCP clients use UDP broadcasts to send their initial DHCPDISCOVER messages.
• DHCP Client uses UDP port 67 to send messages to the server.
DHCP OPERATIONS:
STEP 1:
DHCP client sends out a DHCP Discover message to find out the DHCP server. DHCP discover
message is a layer 2 broadcast as well as layer 3 broadcast.
Fields in DHCP Discover Message:
Src IP: 0.0.0.0 Dst IP: 255.255.255.255
Src MAC : DHCP clients MAC address
Dst MAC: FF:FF:FF:FF:FF:FF
Hence from the above fields it is clear DHCP Discover message is a Network Layer and Data
Link Layer Broadcast.
STEP 2:
DHCP server receives the DHCP discover message from client and sends back the DHCP offer
message with field information as below:
Src IP: DHCP Server IP Address Dst IP: 255.255.255.255 #Still Broadcast as Client still has
no IP Address#
Src MAC : MAC Address of DHCP Server
Dst MAC: DHCP clients MAC address
Hence from above field it is clear that DHCP offer message is a layer 2 unicast but still as
layer 3 broadcast.
STEP 3:
DHCP client receives the DHCP offer from DHCP server and sends back a DHCP Request
message with following fields:
Src IP: 0.0.0.0 #As still the IP address hasn’t been assigned to Client #Dst IP:
255.255.255.255 #Still Broadcast as Client must have received Offer from more than one
DHCP server in their domain and the DHCP client accepts the Offer that its receives the
earliest and by doing a broadcast it intimates the other DHCP server to release the Offered
IP address to their available pool again #
Above fields concludes that DHCP request message is also a layer 2 unicast and a layer 3
broadcast.

STEP4:
Once the DHCP client sends the request to get the Offered IP address, DHCP server responds
with an acknowledge message towards DHCP client with below fields:
Src IP: DHCP Server IP AddressDst IP: 255.255.255.255
From above fields substantiates that DHCP Acknowledge is a layer 2 unicast but still a layer
3 broadcast.
For more details on the information you must get familiar with the DHCP header fields.
Few important fields from DHCP header for our reference are as below –
Ciaddr: Client IP address.
Yiaddr ‘your’ (client) IP address: Server’s response to client.
Siaddr Server IP address: Address of sending server or of the next server to use in the next
Bootstrap process step.
Giaddr: Relay agent IP address, used in booting via a relay agent.
Chaddr: Client hardware address.
DHCP DISCOVER WIRESHARK PACKETS:

DHCP OFFER WIRESHARK PACKET

DHCP REQUEST WIRESHARK PACKETS

DHCP ACKNOWLEDGE WIRESHARK PACKET

DHCP IPCONFIG/RENEW

GNS3
1. DHCP-server
ip dhcp pool CCIE123
network 192.168.1.0 255.255.255.0
default-router 192.168.1.100
dns-server 192.168.1.50
ip dhcp excluded-address 192.168.1.100

ip dhcp excluded-address 192.168.1.1 192.168.1.2
ip dhcp excluded-address 192.168.1.50
interface Ethernet0/0
ip address 192.168.1.100 255.255.255.0
no shutdown
end
2. DHCP-client
ip address dhcp
end
3. Verifications:
DHCP-server#show ip dhcp pool ccnp
DHCP-server#show ip dhcp server statistics

ADVANCE DHCP [DYNAMIC HOST CONTROL PROTOCOL]
Configuring a DHCP Address Pool with Secondary Subnets:
For any DHCP pool, you can configure a primary subnet and any number of secondary subnets.
Each subnet is a range of IP addresses that the device uses to allocate an IP address to a DHCP client.
The DHCP server multiple subnet functionality enables a Cisco DHCP server address pool to manage
additional IP addresses by adding the addresses to a secondary subnet of an existing DHCP address
pool (instead of using a separate address pool).
CORRECT CONFIG:
ip dhcp pool dhcp_1
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0 secondary
!
interface Loopback111
ip address 172.16.1.1 255.255.255.255 secondary
WRONG CONFIG:
ip dhcp pool dhcp_1
network 172.16.1.0 255.255.255.0
lease 1 20 30
accounting default
!
ip dhcp pool dhcp_2
network 172.16.2.0 255.255.255.0
lease 1 20 30
accounting default
!
ip dhcp pool dhcp_3
network 172.16.3.0 255.255.255.0
lease 1 20 30
accounting default
!
ip dhcp pool dhcp_4
network 172.16.4.0 255.255.255.0
lease 1 20 30
accounting default
!
interface Loopback111

Configuring Manual Bindings:
An address binding is a mapping between the IP address and MAC address of a client.
The IP address of a client can be assigned manually by an administrator or assigned automatically
from a pool by a DHCP server.
Manual bindings are IP addresses that are manually mapped to MAC addresses of hosts that are
found in the DHCP database. Manual bindings are stored in the NVRAM of the DHCP server.
1. enable
2. configure terminal
3. ip dhcp pool pool-name
4. host address [mask | /prefix-length]
5. client-identifier unique-identifier # 01b7.0813.8811.66 [For example, 01b7.0813.8811.66, where
01 represents the Ethernet media type and the remaining bytes represent the MAC address of the
DHCP client]
6. hardware-address hardware-address [protocol-type | hardware-number] # This command is
used for BOOTP requests.
7. client-name name
8. end
Configuring DHCP Static Mapping
The DHCP Static Mapping feature enables the assignment of static IP addresses (without creating
numerous host pools with manual bindings) by using a customer-created text file that the DHCP
server reads.
The benefit of this feature is that it eliminates the need for a long configuration file and reduces the
space required in NVRAM to maintain address pools.
There are two types of bindings: manual bindings that map a single hardware address to a single IP
address, and automatic bindings that dynamically map a hardware address to an IP address from a
pool of IP addresses.
Manual (also known as static) bindings can be configured individually directly on the device or by
using the DHCP Static Mapping feature.
These static bindings can be read from a separate static mapping text file.
The following is a sample static mapping text file:
*time* Jan 21 2005 03:52 PM # Specifies the time the file was created.
*version* 2 # Specifies the database version number.
!IP address Type Hardware address Lease expiration
10.0.0.4 /24 1 0090.bff6.081e Infinite
10.0.0.5 /28 id 00b7.0813.88f1.66 Infinite
10.0.0.2 /21 1 0090.bff6.081d Infinite

*end*
Configure DHCP Server to point Static Text File:
1. enable
2. configure terminal
3. ip dhcp pool name
4. origin file tftp://10.1.0.1/static-bindings
5. end
6. show ip dhcp binding [address]
Role of DHCP/BootP Relay Agent
Routers, by default, will not forward broadcast packets. Since DHCP client messages use the
destination IP address of 255.255.255.255 (all Nets Broadcast), DHCP clients will not be able to send
requests to a DHCP server on a different subnet unless the DHCP/BootP Relay Agent is configured on
the router.
The DHCP/BootP Relay Agent will forward DHCP requests on behalf of a DHCP client to the DHCP
server.
The DHCP/BootP Relay Agent will append its own IP address to the source IP address of the DHCP
frames going to the DHCP server.
This allows the DHCP server to respond via unicast to the DHCP/BootP Relay Agent.
Configuring DHCP/BootP Relay Agent Feature on Cisco IOS Router
To forward the BootP/DHCP request from the client to the DHCP server, the ip helper-address
interface command is used
The IP helper-address can be configured to forward any UDP broadcast based on UDP port number.
By default, the IP helper-address will forward the following UDP broadcasts:
• Trivial File Transfer Protocol (TFTP) (port 69)
• DNS (port 53), time service (port 37)
• NetBIOS name server (port 137)
• NetBIOS datagram server (port 138)
• Boot Protocol (DHCP/BootP) client and server datagrams (ports 67 and 68)
• Terminal Access Control Access Control System (TACACS) service (port 49)
• IEN-116 name service (port 42)

GNS3 (DHCP RELAY AGENT)
DHCPSERVER18
Int e0/0
Ip address 192.168.1.100 255.255.255.0
no shutdown
Ip dhcp pool CCIE
network 172.16.32.0 255.255.255.0
default-router 192.168.1.100
exit
ip route 0.0.0.0 0.0.0.0 192.168.1.99
DHCP-RELAY-AGENT17
Interface gi0/0
no switchport
ip address 192.168.1.99 255.255.255.0
no shutdown
Interface gi0/2
no switchport
ip add 172.16.32.100 255.255.255.0
ip helper-address 192.168.1.100
no shutdown
PC8 (ENABLE DHCP SERVICES)

VERIFICATIONS:
1. show ip dhcp pool [name]
2. show ip dhcp binding [address]
3. show ip dhcp conflict [address]
4. show ip dhcp database [url]
5. show ip dhcp server statistics [type-number]
8 DHCP MESSAGE STATES:
DHCPDISCOVER
When a client boots up for the first time, it is said to be in the Initializing state, and transmits a
DHCPDISCOVER message on its local physical subnet over User Datagram Protocol (UDP) port 67
(BootP server). Since the client has no way of knowing the subnet to which it belongs, the
DHCPDISCOVER is an all subnets broadcast (destination IP address of 255.255.255.255), with a
source IP address of 0.0.0.0. The source IP address is 0.0.0.0, since the client does not have a
configured IP address. If a DHCP server exists on this local subnet and is configured and operating
correctly, the DHCP server will hear the broadcast and respond with a DHCPOFFER message. If a
DHCP server does not exist on the local subnet, there must be a DHCP/BootP Relay Agent on this
local subnet to forward the DHCPDISCOVER message to a subnet that contains a DHCP server.
This relay agent can either be a dedicated host (for example, Microsoft Windows Server), or router
(for example, a Cisco router configured with interface level IP helper statements).
DHCPOFFER
A DHCP server that receives a DHCPDISCOVER message may respond with a DHCPOFFER message on
UDP port 68 (BootP client). The client receives the DHCPOFFER and moves into the Selecting state.
This DHCPOFFER message contains initial configuration information for the client. For example, the
DHCP server will fill in the yiaddr field of the DHCPOFFER message with the requested IP address.
The subnet mask and default gateway are specified in the options field, subnet mask and router
options, respectively. Other common options in the DHCPOFFER message include IP Address lease
time, renewal time, domain name server, and NetBIOS name server (WINS). The DHCP server will
send the DHCPOFFER to the broadcast address, but will include the clients hardware address in the
chaddr field of the offer, so the client knows that it is the intended destination. In the event that the
DHCP server is not on the local subnet, the DHCP server will send the DHCPOFFER, as a unicast
packet, on UDP port 67, back to the DHCP/BootP Relay Agent from which the DHCPDISCOVER came.
The DHCP/BootP Relay Agent will then either broadcast or unicast the DHCPOFFER on the local
subnet on UDP port 68, depending on the Broadcast flag set by the Bootp client.
DHCPREQUEST
After the client receives a DHCPOFFER, it responds with a DHCPREQUEST message, indicating its
intent to accept the parameters in the DHCPOFFER, and moves into the Requesting state. The client

may receive multiple DHCPOFFER messages, one from each DHCP server that received the original
DHCPDISCOVER message. The client chooses one DHCPOFFER and responds to that DHCP server
only, implicitly declining all other DHCPOFFER messages. The client identifies the selected server by
populating the Server Identifier option field with the DHCP server's IP address. The DHCPREQUEST is
also a broadcast, so all DHCP servers that sent a DHCPOFFER will see the DHCPREQUEST, and each
will know whether its DHCPOFFER was accepted or declined. Any additional configuration options
that the client requires will be included in the options field of the DHCPREQUEST message. Even
though the client has been offered an IP address, it will send the DHCPREQUEST message with a
source IP address of 0.0.0.0. At this time, the client has not yet received verification that it is clear to
use the IP address.
DHCPACK
After the DHCP server receives the DHCPREQUEST, it acknowledges the request with a DHCPACK
message, thus completing the initialization process. The DHCPACK message has a source IP address
of the DHCP server, and the destination address is once again a broadcast and contains all the
parameters that the client requested in the DHCPREQUEST message. When the client receives the
DHCPACK, it enters into the Bound state, and is now free to use the IP address to communicate on
the network. Meanwhile, the DHCP server stores the lease in its database and uniquely identifies it
using the client identifier or chaddr, and the associated IP address. Both the client and server will use
this combination of identifiers to refer to the lease. The client identifier is the Mac address of the
device plus the media type.
Before the DHCP client begins using the new address, the DHCP client must calculate the time
parameters associated with a leased address, which are Lease Time (LT), Renewal Time (T1), and
Rebind Time (T2). The typical default LT is 72 hours. You can use shorter lease times to conserve
addresses, if needed.
DHCPNAK
If the selected server is unable to satisfy the DHCPREQUEST message, the DHCP server will respond
with a DHCPNAK message. When the client receives a DHCPNAK message, or does not receive a
response to a DHCPREQUEST message, the client restarts the configuration process by going into the
Requesting state. The client will retransmit the DHCPREQUEST at least four times within 60 seconds
before restarting the Initializing state.
DHCPDECLINE
The client receives the DHCPACK and will optionally perform a final check on the parameters. The
client performs this procedure by sending Address Resolution Protocol (ARP) requests for the IP
address provided in the DHCPACK. If the client detects that the address is already in use by receiving
a reply to the ARP request, the client will send a DHCPDECLINE message to the server and restart the
configuration process by going into the Requesting state.
DHCPINFORM
If a client has obtained a network address through some other means or has a manually configured
IP address, a client workstation may use a DHCPINFORM request message to obtain other local
configuration parameters, such as the domain name and Domain Name Servers (DNSs). DHCP
servers receiving a DHCPINFORM message construct a DHCPACK message with any local

configuration parameters appropriate for the client without allocating a new IP address. This
DHCPACK will be sent unicast to the client.
DHCPRELEASE
A DHCP client may choose to relinquish its lease on a network address by sending a DHCPRELEASE
message to the DHCP server. The client identifies the lease to be released by the use of the client
identifier field and network address in the DHCPRELEASE message. If you need to extend the current
DHCP pool range, remove
the current pool of addresses and specify the new range of IP addresses under the DHCP pool. In
order to remove specific IP addresses or a range of addresses that you want to be in the DHCP pool,
use the command ip dhcp excluded-address .

NAT/PAT
• NAT is a cisco term which is stand for Network Address Translation.
• NAT is a process that involves translating Private IP into Public IP addresses.
• The process of translating one IP address to another is known as a NAT.
• Router and Firewall is a device, which is used for network Address Translation.
• There are many forms and kinds of Network Address Translation (NAT).
• Network Address Translation used to reduce requirement of the Public IP address.
• Network Address Translation increase security of Internal Computer Networks.
• NAT Translate Private IP into Public IP address & Public IP into Private IP address.
• NAT used to connect a device with Private IP address to the Internet or WAN.
• Network Address Translation hide an organization internal network from external.
• Network Address Translation (NAT) modifies only the Layer 3 header of IP address.
• PAT, User port numbers mapped to single Public IP to differentiate connections
• Port Address Translation (PAT) modifies both the Layer 3 and Layer 4 header of IP.

Some of the advantages of using NAT in IP networks are the following:
• NAT helps to mitigate global public IP address depletion.
• Networks can use the RFC 1918 private address space internally.
• NAT increases security by hiding the internal network topology and addressing
NORMAL SCENERIO: (WITHOUT NAT)
NAT SCENERIO:

Cisco defines these terms as:
• Inside local address—The IP address assigned to a host on the inside network. This is the address
configured as a parameter of the computer OS or received via dynamic address allocation
protocols such as DHCP. The address is likely not a legitimate IP address assigned by the Network
Information Center (NIC) or service provider.
• Inside global address—A legitimate IP address assigned by the NIC or service provider that
represents one or more inside local IP addresses to the outside world.
• Outside local address—The IP address of an outside host as it appears to the inside network. Not
necessarily a legitimate address, it is allocated from an address space routable on the inside.
• Outside global address—The IP address assigned to a host on the outside network by the host
owner. The address is allocated from a globally routable address or network space.
TYPES OF NAT:
1. STATIC NAT
2. DYNAMIC NAT
3. PORT ADDRESS TRANSLATION (PAT)
1. STATIC NAT
▪ 1:1 mapping done manually
▪ Every private IP need one registered public IP address (one:one)
2. Dynamic NAT

▪ One to one mapping done automatically by NAT device
▪ For every private IP need on registered IP address (one:one)
3. Port Address Translation (Dynamic NAT Overload)
▪ Thousands of private users – use single Public IP
▪ User port numbers mapped to single Public IP to differentiate connections
▪ PAT is the real reason we haven’t run out valid IP address on the Internet
Did You Know?
IP NAT inside source vs IP NAT outside source
On Cisco IOS routers we can use the ip nat inside sourceand ip nat outside source commands.
Most of us are familiar with the ip nat inside source command because we often use it to translate
private IP addressses on our LAN to a public IP address we received from our ISP.
What about the ip nat outside source command? Does it work in the same way as ip nat inside
source?
This is the difference between the two commands:
ip nat inside source:
• Translates the source IP address of packets that travel from inside to outside.
• Translates the destination IP address of packets that travel from outside to inside.
ip nat outside source:
• Translates the source IP address of packets that travel from outside to inside.
• Translates the destination IP address of packets that travel from inside to outside.

GNS3:
Lab#1: Configure Static NAT
Lab#2: Configure Dynamic NAT
Lab#3: Configure PAT
LAB#1: STATIC NAT LAB
REQURIED CONFIG:

MOSCOWR19:
interface Ethernet0/1.40
encapsulation dot1Q 40
ip address 172.16.40.1 255.255.255.0
end
ip address dhcp
end
ip route 0.0.0.0 0.0.0.0 192.168.32.2
PRE-CHECKS:
PING INITITATED FROM PC9 and PC11 TOWARDS 8.8.8.8
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=127 time=65.021 ms
64 bytes from 8.8.8.8: seq=1 ttl=127 time=61.335 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 61.335/63.178/65.021 ms
/ #
VALIDATION: (NORMAL SCEENERIO WITHOUT NAT)
We see private IP as L3 source header address

LAB#1: CONFIGURE STATIC NAT:
MOSCOWR19(config)#
int e0/1.40
ip nat inside
MOSCOWR19(config)#
int e0/2
ip nat outside
ip nat inside source static 172.16.40.10 50.1.1.1
ip nat inside source static 172.16.40.20 50.1.1.2
POST NAT VALIDATION:
We see NAT’d public IP as L3 source header address
This is an example for STATIC NAT CONFIGRATIONS.
LAB#2: DYNAMIC NAT LAB
CONFIGURE DYNAMIC NAT:
MOSCOWR19(config)#
int e0/1.40
ip nat inside
MOSCOWR19(config)#
int e0/2
ip nat outside
access-list 55 permit 172.16.40.0 0.0.0.255
ip nat pool NETWORKJOURNEY 50.1.1.1 50.1.1.10 netmask 255.255.255.240
ip nat inside source list 55 pool NETWORKJOURNEY
VALIDATION:
MOSCOWR19#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 50.1.1.1:19968 172.16.40.10:19968 8.8.8.8:19968 8.8.8.8:19968
--- 50.1.1.1 172.16.40.10 --- ---
icmp 50.1.1.2:16128 172.16.40.20:16128 8.8.8.8:16128 8.8.8.8:16128
--- 50.1.1.2 172.16.40.20 --- ---

LAB#3: DYNAMIC PAT LAB
CONFIGURE DYNAMIC PAT:
MOSCOWR19(config)#
int e0/1.40
ip nat inside
MOSCOWR19(config)#
int e0/2
ip nat outside
access-list 55 permit 172.16.40.0 0.0.0.255
ip nat pool NETWORKJOURNEY 50.1.1.1 50.1.1.10 netmask 255.255.255.240
ip nat inside source list 55 pool NETWORKJOURNEY overload
VALIDATIONS:
MOSCOWR19# sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 50.1.1.2:20224 172.16.40.10:20224 8.8.8.8:20224 8.8.8.8:20224
icmp 50.1.1.2:20480 172.16.40.10:20480 8.8.8.8:20480 8.8.8.8:20480
icmp 50.1.1.2:16384 172.16.40.20:16384 8.8.8.8:16384 8.8.8.8:16384
icmp 50.1.1.2:16640 172.16.40.20:16640 8.8.8.8:16640 8.8.8.8:16640
PTO NEXT PAGE.
Contd.

ASSIGNMENTS - (FOR STUDENTS)
R1 Basic Configuration
R1(config)#interface f0/0
R1(config-if)#ip address dhcp
R1(config-if)#no shutdown
R1(config-if)#ip add 192.168.0.100 255.255.255.0
R1(config-if)#no shutdown
R1(config)#ip name-server 8.8.8.8 R1(config)#ip domain-lookup
Static NAT Configuration on R1
R1(config)#ip nat inside source static 192.168.0.1 192.168.169.139
R1(config-if)#ip nat outside
R1(config-if)#interface f0/1
R1(config-if)#ip nat inside
After send the traffic from 192.168.01, it is translated and send the traffic outside.
Dynamic NAT Configuration on R1
R1(config)#access-list 1 permit 192.168.0.0 0.0.0.255

R1(config)#ip nat pool mypool 192.168.169.139 192.168.169.140 netmask 255.255.255.0
R1(config)#ip nat inside source list 1 pool mypool
PAT Configuration on R1
R1(config)#access-list 1 permit 192.168.0.0 0.0.0.255
R1(config)#ip nat pool mypool 192.168.169.139 192.168.169.139 netmask 255.255.255.0
R1(config)#ip nat inside source list 1 pool mypool overload

SPAN / RSPAN / ERSPAN
SPAN
Cisco Catalyst Switches have a feature called SPAN (Switch Port Analyzer) that lets you copy all
traffic from a source port or source VLAN to a destination interface. This is very useful for a number
of reasons:
• If you want to use wireshark to capture traffic from an interface that is connected to a
workstation, server, phone or anything else you want to sniff.
• Redirect all traffic from a VLAN to an IDS / IPS.
• Redirect all VoIP calls from a VLAN so you can record the calls.
The source can be an interface or a VLAN, the destination is an interface. You can choose if you want
to forward transmitted, received or both directions to the destination interface.
EXAMPLE 1: SPAN
EXAMPLE 2: SPAN
When you use a destination interface on the same switch as your switch, we call it SPAN, when the
destination is a remote interface on another switch we call it RSPAN (Remote SPAN). When using
RSPAN you need to use a VLAN for your RSPAN traffic so that traffic can travel from the source
switch to the destination switch.

RSPAN
When you use RSPAN you need to use a VLAN that carries the traffic that you are copying. In the
picture above you see SW1 which will copy the traffic from the computer onto a “RSPAN VLAN”.
SW2 receives the traffic and forwards it to a computer that has wireshark running. Make sure the
trunks between the switches allow the RSPAN VLAN.
EXAMPLE 1: RSPAN
EXAMPLE 2: RSPAN
SPAN and RSPAN are great but there are a couple of things you need to keep in mind…
RESTRICTIONS:
Both SPAN and RSPAN have some restrictions, I’ll give you an overview of the most important ones:
• The source interface can be anything…switchport, routed port, access port, trunk port,
etherchannel, etc.
• When you configure a trunk as the source interface it will copy traffic from all VLANs,
however there is an option to filter this.
• You can use multiple source interfaces or multiple VLANs, but you can’t mix interfaces and
VLANs.
• It’s very simple to overload an interface. When you select an entire VLAN as the source and
use a 100Mbit destination interface…it might be too much.
• When you configure a destination port you will “lose” its configuration. By default, the
destination interface will only be used to forward SPAN traffic to. However, it can be
configured to permit incoming traffic from a device that is connected to the destination
interface.
• Layer 2 frames like CDP, VTP, DTP and spanning-tree BPDUs are not copied by default but
you can tell SPAN/RSPAN to copy them anyway.

This should give you an idea of what SPAN / RSPAN are capable of. The configuration is pretty
straight-forward so let me give you some examples…
GNS3
LAB#1: SPAN CONFIGURATIONS:
MOSCOWSW01 (config)#
monitor session 1 source interface gi0/2
monitor session 1 destination interface gi1/0
MOSCOWSW01#sh monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi0/2
Destination Ports : Gi1/0
Encapsulation : Native
As you can see, by default it will copy traffic that is transmitted and received (both) to the
destination port. If you only want the capture the traffic going in one direction you have to specify it
like this:

MOSCOWSW01 (config)#monitor session 1 source interface gi0/2 ?
, Specify another range of interfaces
- Specify a range of interfaces
both Monitor received and transmitted traffic
rx Monitor received traffic only
tx Monitor transmitted traffic only
Just add rx or tx and you are ready to go. If interface FastEthernet 0/1 were a trunk you could add a
filter to select the VLANs you want to forward:
MOSCOWSW01 (config)#monitor session 1 filter vlan 1 - 100
This filter above will only forward VLAN 1 – 100 to the destination. If you don’t want to use an
interface as the source but a VLAN, you can do it like this:
MOSCOWSW01 (config)#monitor session 2 source vlan 1
Switch(config)#monitor session 2 destination interface Gi0/3
I am unable to use session 1 for this because I am already using source interfaces for that session.
It’s also impossible to use the same destination interface for another session. This is why I created
another session number and picked Gi 0/3 as a destination.
VALIDATION:
MOSCOWSW01(config)#do sh int gi1/0
GigabitEthernet1/0 is up, line protocol is down (monitoring)
Hardware is iGbE, address is 0c67.9181.a704 (bia 0c67.9181.a704)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
SPAN capture working in right way.
I can see packet capture on my Wireshark
When I stop monitor session 1 or 2, span traffic stops coming to wireshark.

LAB#2: RSPAN CONFIGURATIONS:
The idea is to forward traffic from Gi0/2 on MOSCOWSW01 to Gi 1/0 on MOSCOWSW02. There are a
couple of things we have to configure here:
MOSCOWSW01
vlan 100
remote-span
MOSCOWSW02 (config)#
vlan 100
remote-span
First, we need to create the VLAN and tell the switches that it’s a RSPAN vlan. This is something that
is easily forgotten. Secondly, we will configure the link between the two switches as a trunk:
MOSCOWSW01(config)#
interface Gi 0/0
switchport trunk encapsulation dot1q
switchport mode trunk
MOSCOWSW02(config)#
interface Gi 0/0
switchport trunk encapsulation dot1q
switchport mode trunk
Now we can configure RSPAN:
MOSCOWSW01(config)#
monitor session 1 source interface Gi 0/2
monitor session 1 destination remote vlan 100
This selects Gi 0/1 as the source and VLAN 100 as the destination…

MOSCOWSW02(config)#
monitor session 1 source remote vlan 100
monitor session 1 destination interface Gi 1/0
And on MOSCOWSW02, we select VLAN 100 as the source and Gi 0/1 as its destination. Here’s the
output of the show monitor session command:
MOSCOWSW01# show monitor session 1
Session 1
---------
Type : Remote Source Session
Source Ports :
Both : Gi 0/2
Dest RSPAN VLAN : 40
MOSCOWSW02#show monitor session 1
Session 1
---------
Type : Remote Destination Session
Source RSPAN VLAN : 100
Destination Ports : Gi 1/0
Ingress : Disabled
MOSCOWSW02(config)#do sh int gi1/0
GigabitEthernet1/0 is up, line protocol is down (monitoring)
Hardware is iGbE, address is 0c67.9181.a704 (bia 0c67.9181.a704)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Wireshark Capture Applied between MOSCOWSW02_Gi1/0 to Wireshark host can see RSPAN
captured traffic:
When I stop the traffic, Wireshark stops the capturing too:

ASSIGNMENTS - (FOR STUDENTS)
LAB#3 SPAN
S1(config)#monitor session 1 source interface FastEthernet 1/1
S1(config)#monitor session 1 destination interface FastEthernet 1/3
S1#show monitor session 1
S1#show interfaces FastEthernet 1/3

LAB#4 RSPAN
SW1 Configuration
SW1(config)#vlan 100
SW1(config‐vlan)#remote‐span
SW1(config)#interface Ethernet 0/0
SW1(config‐if)#switchport trunk encapsulation dot1q
SW1(config‐if)#switchport mode trunk
SW1(config)#monitor session 1 source interface Ethernet 0/1
SW1(config)#monitor session 1 destination remote vlan 100
SW1#show monitor session all
SW2 Configuration
SW2(config)#vlan 100
SW2(config‐vlan)#remote‐span
SW2(config)#interface Ethernet 0/0
SW2(config‐if)#switchport trunk encapsulation dot1q
SW2(config‐if)#switchport mode trunk
SW2(config)#monitor session 1 source remote vlan 100
SW2(config)#monitor session 1 destination interface Ethernet 0/1
SW2#show monitor session all
VALIDATIONS:
MOSCOWSW01# show monitor session 1
Session 1
---------
Type : Remote Source Session
Source Ports :
Both : Gi0/2
Dest RSPAN VLAN : 100
MOSCOWSW02#show monitor session 1
Session 1
---------
Type : Remote Destination Session
Source RSPAN VLAN : 100
Destination Ports : Gi1/0

4 ip services span,rspan

More Related Content

What's hot

Similar to 4 ip services span,rspan

More from SagarR24

Recently uploaded

4 ip services span,rspan