IP ADDRESS & SUBNETTING

Clas 1st Octet Decimal 1st Octet High Default Subnet Number of Hosts per Network
s Range Order Bits Mask Networks
A 1 – 126 0000               0         255.0.0.0 (27 – 2) 126 (224 – 2)
       
B 128 – 191 1000              128 255.255.0.0 (214 – 2) 16,382 (216 – 2)
C 192 – 223 1100              192 255.255.255.0 (221 – 2) 2,097,150 (28 – 2)
D 224 – 239 1110              224 Reserved for Multicasting
E 240 – 254 1111              255 Experimental; used for research
Private IP addressing -
Clas
Private Networks Subnet Mask Address Range
s
A 10.0.0.0 255.0.0.0 10.0.0.0 - 10.255.255.255
172.16.0.0 -
B 255.240.0.0 172.16.0.0 - 172.31.255.255
172.31.0.0
C 192.168.0.0 255.255.0.0 192.168.0.0 - 192.168.255.255

Subnet Mask calculation -

If the CIDR value is /25 then subnet mask will be – 255.255.255.128. In binary –
11111111.11111111.11111111.10000000  (8+8+8+1 = 25)
Same way if subnet mask is – 255.255.192.0 the CIDR value will be /18 (8+8+2)
Wild card calculation -
Whatever the subnet mask minus it with 255. E.g. – mask 255.255.0.0 wildcard will be 0.0.255.255
Subnet Mask Wildcard Mask Calculation
255.255.128.0 0.0.127.255 255-128 = 127
255.192.0.0 0.63.255.255 255-192 = 63
 
Supernet calculation –
Sometimes we set lesser subnet mask or cidr value than the default value & apply it on ACL, Prefix-list or route
advertisement. This will help us to just select 1 master subnet & all child subnet will be select. Example –

1. 172.16.0.0/12 – This will select 172.16.0.0 to 172.31.0.0         B.  192.168.0.0/ 13 will select 192.168.0.0 to
192.175.255.255

Master network octet + wildcard mask octet = extended range.

Network Subnet Wildcard mask Range to select Calculation
mask
192.168.0.0/ 255.248.0.0 0.7.255.255 192.168.0.0 - 168+7 = 175
13 192.175.255.255
172.16.0.0/1 255.240.0.0 0.15.255.255 172.16.0.0 – 16+15 = 31
2 172.31.255.255
If we extend master subnet 172.16.0.0/16 to 172.31.0.0 then calculation of subnet mask or cidr value will be 31-16 = 15.
So calculating by wildcard – 0.15.255.255 mask will be – 255.240.0.0. Extended range minus master range = wildcard
octet (convert into subnet mask) 
Range Calculation Wildcard Subnet mask to select
172.16.0.0 – 31-16 = 15 0.15.255.255 255.240.0.0
172.31.255.255
192.168.12.0 - 15-12 = 3 0.0.3.255 255.255.252.0
192.168.15.255
172.24.0.0 – 27-24=3 0.3.255.255 255.252.0.0
172.27.255.255
192.168.0.0 - 63-0=63 0.0.63.255 255.255.192.0
192.168.63.255
 Note that we cannot select any range from our mind, e.g. if we want to range from 192.168.1.0/24 to 192.168.63.255
then we’ve to start from 192.168.0.0 instead of 192.168.0.0.

ROUTER MAINTENANCE, MONITORING & CEF

Backing up configuration –
Configuration & IOS file of router or switch can be backed up in a ftp,http,tftp server. The procedure mentioned below.

1. Create a FTP server with user id & password authentication

2. Copy startup-config ftp://sudeb:[email protected]
3. To save the login credential configure the ftp server login details on router. -> ip ftp username sudeb.   ip ftp
password password. Copy startup-config ftp://172.16.20.201
4. To automatically backup the running-config or startup-config – Procedure

R1(Config)#archive
R1(Config-archive)# path ftp://172.16.20.201/r1-config    (name of the file will be created as – r1-config-1…2)
R1(Config-archive)# write memory       (To save the config file on ftp during write memory command applied)
R1(Config-archive)# time-period 60 mins           (This will auto save the running config on to FTP after 1 hour)
R1# show archive             (To check the configuration file backup)
To rollback a configuration –
R1# configure replace ftp://172.16.20.201/r1-config-3      (name of the desired file)
Show tech-support command which collect the whole information of router & its process & displaying on console. Its
taking a huge buffer size & it automatically scroll through until complete. So we are not able to see all the info normally.
Redirect it to an external FTP,tftp server or flash to see the detail info.
R3#show tech-support | redirect flash:techsupport.txt
R3#sh flash:
System CompactFlash directory:
File  Length   Name/status
  1   109908   techsupport.txt  
[109972 bytes used, 16667240 available, 16777212 total]
16384K bytes of ATA System CompactFlash (Read/Write)

R3#more flash:techsupport.txt          *** to display text file of flash we have to use more command.
Logging – 3 types of logging can be configured on Cisco devices. Syslog, SNMP, Netflow
Console logging: All console messages will display on the pc connected to device console port.
Monitor logging: While terminal monitor command enable on VTY session logs will display.
Buffer logging: Log store on nvram & can be seen with show logging command.
Trap logging: Logging to an SNMP server.

To enable buffer logging. -

(config)# logging buffered 4096 informational       (4096 bytes size)
Syslog is on port 514 UDP, snmp traps on port 162 UDP
Monitoring with SNMP & NETFLOW -
Simple Network Management Protocol (SNMP) and NetFlow are two technologies available on some Cisco IOS platforms
that can automate the collection statistics. Although both SNMP and NetFlow are useful for statistical data collection,
they target different fundamental functions. SNMP is primarily focused on device statistics, whereas NetFlow is primarily
focused on traffic statistics.              SNMP versions & security levels –
Model Level Authentication Encryption What Happens
v1 noAuthNoPriv Community String No Uses a community string match for authentication.
v2c noAuthNoPriv Community String No Uses a community string match for authentication.
v3 noAuthNoPriv Username No Uses a username match for authentication.
v3 authNoPriv MD5 or SHA No Provides authentication based on the HMAC-MD5 or
HMAC-SHA algorithms.
v3 authPriv MD5 or SHA DES Provides authentication based on the HMAC-MD5 or
HMAC-SHA algorithms. Provides DES 56-bit encryption in
addition to authentication based on the CBC-DES (DES-56)
standard.
An SNMP-managed network consists of three key components:

∙ Managed device
∙ Agent — software which runs on managed devices
∙ Network management system (NMS) — software which runs on the manager

Default SNMP version is v1. By default - The SNMP agent receives requests on UDP port 161. The manager receives
notifications (Traps and Inform Requests) on port 162.  Default community is public.
SNMP v2c sample configuration – 
R1(config)# snmp-server host 192.168.1.1 version 2c CISCO          (Community string)
R1(config)# snmp-server contact [email protected]
R1(config)# snmp-server location 3rd Floor      
R1(config)# snmp-server ifindex persist                     (SNMP stays consistent during data collection, even if the device is
rebooted.)
***  The community string & version must match between manager & agent.
NET FLOW
Unlike SNMP, NetFlow can distinguish between different traffic flows. A flow is a series of packets, all of which have
shared header information such as source and destination IP addresses, protocols numbers, port numbers, and Type of
Service (TOS) field information. We can use the NetFlow feature as a standalone feature on an individual router. However,
rather than using just a standalone implementation of NetFlow, entries in a router’s flow cache can be exported to a
NetFlow collector prior to the entries expiring.

R4(config)# int fa 0/0

R4(config-if)# ip flow ingress
R4(config)# int fa 0/1
R4(config-if)# ip flow ingress
R4(config)#ip flow-?
flow-aggregation  flow-cache        flow-capture          flow-egress               flow-export         flow-top-talkers
R4(config)#ip flow-cache    (This will cache the ip-flow on the router)
R4(config)# ip flow-export source lo 0     (Exporting to other device)
R4(config)# ip flow-export version 5
R4(config)# ip flow-export destination 192.168.1.50 5000    **    
**   NetFlow does not have a standardized port number, So configure it according to the collector software’s requirement.

**   NetFlow does not have a standardized port number, So configure it according to the collector software’s requirement.
Reminder of network events –
The event manager applet command used for displaying customized & user specified notifications on the console
through syslog message. EEM can perform various actions, including sending an SNMP trap to an NMS, writing a log
message to a syslog server, executing specified Cisco IOS commands, sending an e-mail to an appropriate party, or
executing a tool command language (Tcl) script.   Example –
R4(config)# event manager applet COUNTER-RESET
R4(config-applet)# event cli pattern “clear counters” sync no skip no occurs 1
R4(config-applet)# action A syslog priority informational msg “Please update network documentation to record.”
R4# clear counters
Clear “show interface” counters on all interfaces [confirm]
R4#
*Mar 3 08:41:00.582: %HA_EM-6-LOG: COUNTER-RESET: Please update network documentation to record.

Monitoring from console –

Router performance can be monitor from console through CPU graph & process. R1# sh process cpu history

    
The row section 0 to 100 represents the utilization percentage. The column section 0…5…10…20 represents the time.
Current status starts from the left side & goes to the past time to the right side. As per the image of last 60 minutes
utilization – Last minute cpu utilization reaches at a peak of – 60% at an average of 40% 2nd last minute peak – 50%
35 minutes ago @ 60% from when the router started.
Now if you found the utilization is high & slowness of the console & the network side. Then look for the process that uses
max cpu.
R1# sh process cpu sorted    (This will arrange the cpu process from highest to lowest.)

The CPU utilization history shows only the total CPU utilization over time. It does not show the CPU time spent at
interrupt. Knowing 
the time spent at interrupt is critical for determining the cause of CPU utilization. Its normal for the interrupt percentage to
be greater than 0 percent and less than 5 percent. It is acceptable for the interrupt percentage to be between 5 percent
and 10 percent. An interrupt percentage over 10 percent should be investigated.
Monitoring & troubleshooting interface issues -
Default route must be configure against ip instead of interface as interface broadcast to all ips on the subnet querying for
a route.
Checking MTU with Ping –
We might get reply from an IP by testing with a maximum MTU but it doesn’t tell us what MTU set at my end or remote
end. Packet fragmentation can occur & sent some part of packet which permitted to get the reply but if I set don’t
fragment the packet & test, then only I can get to know whether it support that MTU or not.  In windows PC –
C:\>ping google.com -l 1500
Pinging google.com [173.194.36.6] with 1500 bytes of data:
Reply from 173.194.36.6: bytes=1500 time=108ms TTL=55
Reply from 173.194.36.6: bytes=1500 time=108ms TTL=55
C:\>ping google.com -l 1500 -f
Pinging google.com [173.194.36.4] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.        (DF= Don’t fragment set)
In router –
R3#ping 3.3.3.3 size 1530 df-bit
Type escape sequence to abort.
Sending 5, 1530-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with the DF bit set
MMMM
Checking interface for error –
DSW1#sh interfaces | inc FastEthernet|error  
FastEthernet0/0 is up, line protocol is up
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 output errors, 0 collisions, 0 interface resets
FastEthernet0/1 is administratively down, line protocol is down
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 output errors, 0 collisions, 0 interface resets
FastEthernet1/0 is administratively down, line protocol is down
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 output errors, 0 collisions, 4 interface resets
FastEthernet1/1 is up, line protocol is down
R1# show interface f0/1
   ## Output omitted ##
127195 packets input, 37913789 bytes
     Received 42407 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     124519 packets output, 21822674 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
** Clear interface counter will reset every counters to 0
Counters Description Common Cause
Runts The frames received that are smaller than the This can be caused by a duplex mismatch and
minimum IEEE 802.3 frame size (64 bytes for physical problems, such as a bad cable, port, or NIC
Ethernet), and with a bad CRC. on the attached device.
Giants Frames received that exceed the maximum IEEE In many cases, this is the result of a bad NIC. Try to
802.3 frame size (1518 bytes for non-jumbo find the offending device and remove it from the
Ethernet) and have a bad Frame Check Sequence network
(FCS).
throttles The number of times the receiver on the port is Packets which can increase the processor overload
disabled, possibly because of buffer or include IP packets with options, expired TTL,
processor overload. If an asterisk (*) appears non-ARPA encapsulation, fragmentation, tunelling,
after the throttles counter value, it means that ICMP packets, packets with MTU checksum failure,
the interface is throttled at the time the RPF failure, IP checksum and length errors.
command is run.
Input This includes runts, giants, no buffer, CRC, frame,
Errors overrun, and ignored counts. Other input-related
errors can also cause the input errors count to be
increased, and some datagrams can have more
than one error.
CRC This increments when the CRC generated by the This usually indicates noise or transmission problems
originating LAN station or far-end device does on the LAN interface or the LAN itself. A high number
not match the checksum calculated from the of CRCs is usually the result of collisions but can also
data received. indicate a physical issue (such as cabling, bad
interface or NIC) or a duplex mismatch
collisions The number of times a collision occurred before Collisions are normal for interfaces configured as half
 the interface transmitted a frame to the media duplex but must not be seen on full duplex interfaces.
successfully. If collisions increase dramatically, this points to a
highly utilized link or possibly a duplex mismatch with
the attached device.
Ignored The number of received packets ignored by the Broadcast storms and bursts of noise can cause the
interface because the interface hardware ran low ignored count to be increased.
on internal buffers.

Overrun The number of times the receiver hardware was The input rate of traffic exceeded the ability of the
unable to hand received data to a hardware receiver to handle the data.
buffer.

underruns The number of times that the transmitter has This can occur in a high throughput situation where
been that run faster than the switch can handle. an interface is hit with a high volume of bursty traffic
from many other interfaces all at once. Interface
resets can occur along with the underruns.
Cisco IOS & their versions –
http://www.cisco.com/web/about/security/intelligence/ios-ref.html

Show Version –

NVRAM store the startup config file which copies to memory as running config when the router started.
Configuration register 0x2102 means it will check the startup-config file & 0x2142 means it will by pass it.
Files on NVRAM can be seen with - dir nvram:
Check flash files-

c2800….bin is the IOS.

Router architecture divides router functions into three operational planes:
■ Management plane: The management plane is concerned with the management of the device. For example, an
administrator connecting to a router through a Secure Shell (SSH) connection through one of the router’s VTY lines would
be a management
Plane operation.
■ Control plane: The control plane is concerned with making packet-forwarding decisions. For example, routing protocol
operation would be a control plane function.
■ Data plane: The data plane is concerned with the forwarding of data through a router. For example, end-user traffic
traveling from a user’s PC to a web server on a different network would go across the data plane.
Packet switching - packets arriving on an ingress interface and being sent out an appropriate egress interface, a process
called packet switching. Cisco routers support the following three primary modes of packet switching:
■ Process switching          ■ Fast switching          ■ Cisco Express Forwarding (CEF)
Process Switching - When a router routes a packet (that is, performs packet switching), the router removes the packet’s
Layer 2 header, examines the Layer 3 addressing, and decides how to forward the packet. The Layer 2 header is then
rewritten (which might involve changing the source and destination MAC addresses and computing a new cyclic
redundancy check [CRC]), and the packet is forwarded out an appropriate interface. With process switching a router’s CPU
becomes directly involved with packet-switching decisions. As a result, the performance of a router configured for
process switching can suffer significantly. An interface can be configured for process switching by disabling fast
switching on that interface. The interface configuration mode no ip route-cache .
Fast Switching - Fast switching uses a fast cache maintained in a router’s data plane. The fast cache contains information
about how traffic from different data flows should be forwarded. The first packet in a data flow is process switched by a
router’s CPU. Once the router determines how to forward the first frame of a data flow, the forwarding information is
stored in the fast cache. Subsequent packets in that same data flow are forwarded based on information in the fast
cache. As a result, fast switching dramatically reduces a router’s CPU utilization, as compared to process switching. Fast
cache is configured by default with ip route-cache on interface.
(config-if)#ip route-cache flow                #Show ip cache flow

CEF - Cisco Express Forwarding maintains two tables in the data plane. Forwarding Information Base (FIB) maintains
Layer 3 forwarding information. Adjacency table maintains Layer 2 information for next hops listed in the FIB.

CEF built FIB from router’s routing table information & adjacency table from router’s ARP cache. Unlike fast switching, CEF
does not require the first packet of a data flow to be process switched. Rather, an entire data flow can be forwarded at the
data plane. CEF is enabled globally on many platforms. To enable it globally – ip cef. To enable on interface individually ip
route-cache cef on interface.

   

  
Show ip interface command helps to check the fast switching or cef enable on the interface.
 
CEF load balancing –
If we have multiple paths in routing table for a destination then CEF will load balance the traffic. The default is per
destination load balancing. Per-destination load balancing means the router distributes the packets based on the
destination address. Given two paths to the same network, all packets for destination1 on that network go over the first
path, all packets for destination2 on that network go over the second path, and so on.
Per-packet load-balancing means that the router sends one packet for destination1 over the first path, the second packet
for (the same) destination1 over the second path, and so on. Per-packet load balancing guarantees equal load across all
links. However, there is potential that the packets may arrive out of order at the destination because differential delay may
exist within the network.
To check the load balancing –

Route Recursive Lookup - 

Every route that has only a next-hop IP address and does not has an exit interface must have the next-hop IP address
resolved using another route in the routing table that has an exit interface. Therefore another lookup has to be made.
There can be more lookups, until the route with exit interface specified is found - so that's why it's called recursive. E.g. - S
192.168.2.0/24 [1/0]  via 172.16.2.2. When a packet arrives with destination IP 192.168.2.69, router will find out that a
suitable route for such packet is static route 192.168.2.0/24 with the next hop IP address 172.16.2.2.This next hop IP
address 172.16.2.2 is then found as directly connected through exit interface Serial0/0/0.
Unicast Reverse Path Forwarding –
 It Prevents malicious traffic from entering a network. uRPF can help block packets having a spoofed IP address. uRPF
check the source IP address of a packet arriving on an interface and determine whether that IP address is reachable,
based on the router’s FIB used by CEF. Optionally, the router can also check to see whether the packet is arriving on the
interface the router would use to send traffic back to that IP address. CEF must be enabled on a router
Three modes of operation for uRPF:   1. Strict mode, 2. Loose mode, 3. VRF mode.
Strict mode: With strict mode operation, a router not only checks the source IP address of an arriving packet is reachable,
based on the router’s FIB, but the packet must also be arriving on the same interface the router would use to send traffic
back to that IP address. From a design perspective, strict mode could cause traffic to be dropped if an asynchronous
routing situation.
Loose mode: With loose mode operation, a router only verifies that the source IP address of a packet is reachable, based
on the router FIB.
VRF mode: Virtual Routing and Forwarding (VRF) is a technology that allows a router to have multiple IP routing table
instances, thus allowing overlapping IP addresses to be used.
R1(Config-if)# ip verify unicast source reachable-via { rx | any } [ allow-default ] [ allow-selfping] [ acl ]
rx - Enables uRPF in strict mode, any - Enables uRPF in loose mode,
allow-default - Allows uRPF to use a default route if a network is not found in a router’s FIB
allow-self-ping - Allows a router to ping itself when checking the reachability of an IP address
acl - Identifies an optional access control list that can either permit or deny traffic that fails the uRPF check
R1# show cef interface fa 1/0        
IP unicast RPF check is enabled
Input features: uRPF
 PBR

Policy base routing by Sudeb

PBR chooses how to forward the packet by using matching of a route-map. The route-map also defines the forwarding instruction –
i. Set ip next hop ip address (of the connected subnet).
 ii. set ip default next-hop ip-address(first attempts to route based on the routing table.)
iii. set interface interface-type interface-number [. . .interface-type interface-number] (Forwards packets using the first     interface in
the list that is up.)
 iv. set default interface interface-type interface number [. . . interface-type interface-number] (policy routing first attempts to route
based on the routing table.)

  By default the hosts will use R2 on T1 link to reach to S1. Configure PBR so that Pc2 will use the low cost path.
R1#interface Fastethernet 0/0
ip address 10.1.1.9 255.255.255.0                                                        R1# show ip policy
ip policy route-map PC2-over-low-route                                                Interface      Route map
                                                                                Fa0/0            PC2-over-low-route
!                                                                                                                
access-list 101 permit ip host 10.1.1.2 10.1.3.0 0.0.0.255
!
route-map PC2-over-low-route permit
match ip address 101
set ip next-hop 10.1.14.4
In some cases, it may be useful to use PBR to process packets generated by the router itself. To make IOS process locally
created packets using PBR logic, configure the ip local policy route-map name global command
IP SLA –  ip sla is a service license agreement that measures on going behavior of the network by ping reply & checking jitter etc.
Many network management tools support the ability to configure IP SLA from the management tools’ graphical interfaces.
For example, a single IP SLA operation could define the following:
■ Use ICMP echo packets.
■ Measure the end-to-end round trip response time (ICMP echo).
■ Send the packets every 5 minutes, all day long.
A wide range of IP SLA operations exist. The following list summarizes the majority of the available operation types, just for
perspective:
■ ICMP (echo, jitter)
■ RTP (VoIP)
■ TCP connection (establishes TCP connections)
■ UDP (echo, jitter)
■ DNS
■ DHCP
■ HTTP
■ FTP
Configuration –
■ Send ICMP Echo Requests to server S1 (10.1.3.99).
■ Use source address 10.1.1.9 (R1’s F0/0 IP address).
■ Send these packets every 60 seconds.
■ Start the operation immediately, and run it forever.
■ Enable PBR for locally generated packets, matching the IP SLA operation with the PBR configuration so that the SLA operation’s
packets flow over the lower route.

R1# conf t
R1(config)# ip sla 11
R1(config-ip-sla)#icmp?
icmp-echo icmp-jitter
R1(config-ip-sla)# icmp-echo 10.1.3.99 source-ip 10.1.1.9
R1(config-ip-sla)# frequency 60
R1(config-ip-sla)# exit
R1(config)# ip sla schedule 11 start-time now life forever             
! Changes to the PBR configuration below
R1(config)# access-list 101 permit ip host 10.1.1.9 host 10.1.3.99
R1(config)# ip local policy PC2-over-low-route
R1(config)# end
Verification - R1# show ip sla configuration
Configuring a Static Route to Track an IP SLA Operation –
We can configure both static routes and PBR to be used only when an SLA operation remains successful.
Step 1. Use the track object-number ip sla sla-ops-number [state | reachability]
Step 2. (Optional) Configure the delay to regulate flapping of the tracking state by using the delay {down seconds | up seconds}
command in tracking configuration mode.
Step 3. Configure the static route with the ip route destination mask {interface | next-hop} track object-number.
R1# conf t
R1(config)# track 2 ip sla 11 state
R1(config-track)# delay up 90 down 90
R1(config-track)# exit
R1(config)# ip route 10.1.234.0 255.255.255.0 s0/0/1 track 2
R1(config)# end
As soon as the static route goes down – it generates a console log message –
R1#
*Sep 14 22:55:43.362: %TRACKING-5-STATE: 2 ip sla 11 state Up->Down
Verification - ---
R1# show track
Track 2
IP SLA 11 state
State is Down
2 changes, last change 00:00:15
Delay up 90 secs, down 90 secs
Latest operation return code: No connection
Tracked by:
STATIC-IP-ROUTING 0
Configuring PBR to Track an IP SLA
Set ip next-hop verify-availability 10.1.14.4 1 track 2   (In route-map configuration)
When the tracking object is up, PBR works as configured. When the tracking object is down, PBR acts as if the set command does not
exist. That means that the router will still attempt to route the packet per the normal destination-based routing process. The other
route to reach the destination.
The show track command lists “ROUTE-MAP” instead of “STATIC-IP-ROUTING,
Exam – Company Acan has two links which can take it to the Internet. The company policy demands that you use web traffic to be
forwarded only to Frame Relay link if available and other traffic can go through any links. No static or default routing is allowed.

Answer and Explanation:

All the HTTP traffic from the EIGRP Network should go through Frame Relay link if available and all the other traffic should go through
either link.The only router you are able to administrate is the Border Router, from the EIGRP Network you may only send HTTP traffic.
As the other people mentioned, actually it is not a BGP lab. You are not able to execute the command “router bgp 65001″
1) Access list that catches the HTTP traffic:
BorderRouter#access-list 101 permit tcp any any eq www
Note that the server was not directly connected to the Border Router. There were a lot of EIGRP routes on it. In the real exam you do
not know the exact IP address of the server in the EIGRP network so we have to use the source as “any” to catch all the source
addresses.
2) Route map that sets the next hop address to be ISP1 and permits the rest of the traffic:
BorderRouter(config)#route-map pbr permit 10
BorderRouter(config-route-map)#match ip address 101
BorderRouter(config-route-map)#set ip next-hop 10.1.101.1
BorderRouter(config-route-map)#exit
BorderRouter(config)#route-map pbr permit 20
(Notice: the route-map pbr permit 20 line allows other traffic than HTTP to be routed. Otherwise, other traffic will be dropped)
3) Apply the route-map on the interface to the server in the EIGRP Network:
BorderRouter(config-route-map)#exit
BorderRouter(config)#int fa0/0
BorderRouter(config-if)#ip policy route-map pbr
BorderRouter(config-if)#exit
BorderRouter(config)#exit
4) There is a “Host for Testing”, click on this host to open a box in which there is a button named “Generate HTTP traffic”. Click on this
button to generate some packets for HTTP traffic. Jump back to the BorderRouter and type the command “show route-map”.
BorderRouter#show route-map
INTERFACE NULL0

Use a Static Route to the Null0 Interface for Loop Prevention

Source : Cisco.com
The Null interface is typically used for preventing routing loops. Enhanced Interior Gateway Routing Protocol ( EIGRP), for
instance, always creates a route to the Null0 interface when it summarizes a group of routes. Whenever a routing protocol
summarizes, this means that the router might receive traffic for any IP address within that summary. Because not all IP
addresses are always in use, there is a risk of looping packets in case default routes are used on the router which receives the
traffic for the summary.
A static route to Null0 is a normal static route, except that it points to the Null0 interface, which is a virtual
IOS interface. Refer to the IP Routing Protocols Commands: I section of Cisco IOS IP Command Reference, Volume 2 of 4: Routing
Protocols, Release 12.3 for more information about the ip route command. The next section presents an example of how to use
the ip route command to create a static route to Null0.

Example
A common scenario where you may need to add a static route to Null0 is that of an access server which has many clients
dialing in. This scenario causes host routes to be installed in the access server routing table. To ensure reachability to these
clients, while not flooding the entire network with host routes, other routers in the network typically have a summary route
which points to the access server. In this type of configuration, the access server should have that same summary route
pointing to the access server Null0 interface. If not, routing loops may occur when outside hosts attempt to reach IP
addresses not currently assigned to a dialed in client but are part of the summary route. This is because the access server
would bounce the packets back over the access server default route into the core network, because the access server lacks a
specific host route for the destination.
Consider this example:
A small ISP (ISP−R1) gives one of his customers a network block of 192.168.0.0/16. In this example, the customer divided
192.168.0.0/16 in /24 networks and only uses 192.168.1.0/24 and 192.168.2.0/24 at the moment. On router ISP−R1, the ISP
configures a static route for 192.168.0.0/16 toward the customer router ( cust−R2). The ISP then connects to a backbone ISP,
represented by router BB−R3. Router BB−R3 sends a default route to ISP−R1 and receives the network 192.168.0.0/16 via BGP
from ISP−R1.
Reachability is now guaranteed from the Internet (backbone ISP router BB−R3) to the customer router cust−R2 because
cust−R2 has a default route configured to point to ISP−R1. However, if packets are destined to network blocks which are not
in use out of the 192.168.0.0/16 range, then the cust−R2 router uses the default route to ISP−R1 to forward those packets.
The packs then loop between ISP−R1 and cust−R2 until the TTL expires. This can have a huge impact on the router CPU and
link utilization. An example of where this traffic to unused IP addresses might come from could be denial of service attacks,
scanning of IP blocks to find vulnerable hosts, etc Relevant configurations:
cust−R2
version 12.3 !
hostname cust−R2
 ISP−R1
version 12.3 !
hostname ISP−R1 !
ip subnet−zero ! interface Loopback0  ip
address 10.1.1.1 255.255.255.255 !
interface Serial0/0  ip address 10.0.0.1
255.255.255.252 !−−−  Interface to cust−R
2.
! interface Serial1/0  ip unnumbered
Loopback0 !−−−  Interface going to
BB−R 3.
! router bgp 65501  no synchronization
 network 192.168.0.0 mask 255.255.0.0
!−−− ISP−R1 injects 192.168.0.0/16 into BGP to !−−−  advertise it to
BB−R 3.
 neighbor 10.3.3.3 remote−as 65503
 neighbor 10.3.3.3 ebgp−multihop 255  no
auto−summary !
ip classless ip route 10.3.3.3 255.255.255.255
Serial1/0 ip route 192.168.0.0 255.255.0.0 Serial0/0
!−−− The first route is necessary for the eBGP

BB−R3
version 12.3 !
hostname BB−R3
!
ip subnet−zero ! ! interface Loopback0  ip
address 10.3.3.3 255.255.255.255 !
interface Serial2/0  ip unnumbered
Loopback0 !−−−  This interface goes to
ISP−R 1.
! router bgp 65503  no synchronization  bgp
log−neighbor−changes  neighbor 10.1.1.1
remote−as 65501  neighbor 10.1.1.1
ebgp−multihop 255  neighbor 10.1.1.1
default−originate
!−−− BB−R3 injects a default route into BGP and !−−−  sends it
to ISP−R 1.
 no auto−summary ! ip classless ip route 10.1.1.1
255.255.255.255 Serial2/0
!−−− This route points to ISP−R1 and is !−−−  used to
establish the eBGP peering.
! end
Packet flow:
Note: We enabled some debug commands on the routers to better illustrate the packet flow, notably debug ip packet and debug ip
icmp. Do not enable these commands in a production environment unless you fully understand the consequences.

BB−R3# ping ip 192.168.20.1 repeat 1

Type escape sequence to abort.

Sending 1, 100−byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
*Oct  6 09:36:45.355: IP: tableid=0, s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), routed *Oct  6 09:36:45.355: IP: s=10.3.3.3
(local), d=192.168.20.1 (Serial2/0), len 100, sending.
Success rate is 0 percent (0/1)
BB−R3#
*Oct  6 09:36:50.943: ICMP: time exceeded rcvd from 10.0.0.1
BB−R3 sends a single ICMP request to an IP address within the 192.168.0.0/16 block which is not in use on cust−R2. BB−R3
receives an ICMP time exceeded back from ISP−R1.
On ISP−R1:
18:50:22: IP:  tableid=0, s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100,
18:50:22: IP:  tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100,
18:50:22: IP:  tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100,
18:50:22: IP:  tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
The initial packet is received on serial1/0 from BB−R3 and is forwarded to cust−R2 from serial0/0 as expected. The same
packet arrives back at ISP−R1 on serial0/0 and is sent immediately out the same interface, to cust−R2, because of this route:

ISP−R1# show ip route 192.168.20.1

Routing entry for 192.168.0.0/16, supernet

  Known via "static", distance 1, metric 0 (connected)
  Advertised by bgp 65501   Routing Descriptor Blocks:
  * directly connected, via Serial0/0
      Route metric is 0, traffic share count is 1 What happens on cust−R2 that causes
it to send this traffic back to ISP−R1?

On cust−R2:
*Oct  6 09:41:43.495: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, l
*Oct  6 09:41:43.515: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), ro
*Oct  6 09:41:43.515: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, l
*Oct  6 09:41:43.555: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), ro
We see that cust−R2 sends these packets back to ISP−R1, because of this route:
cust−R2# show ip route 192.168.20.1 longer−prefixes Codes: 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 Gateway of last resort is
10.0.0.1 to network 0.0.0.0
cust−R2#
Router cust−R2 does not have a route to 192.168.20.1 because this network is not in use in the customer network, so the best
route to 192.168.20.1 is the default route which points to ISP−R1.
The result is that the packets loop between ISP−R1 and cust−R2 until the TTL expires.
Note that if the ICMP request had gone to an IP address within a network that is in use, this result would not occur. For example,
if the ICMP request was for 192.168.1.x, which is directly connected on cust−R2, no looping would have occurred:
cust−R2# show ip rou 192.168.1.1 Routing entry for
192.168.1.0/24   Known via "connected", distance 0, metric 0
(connected, via interface)   Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0
      Route metric is 0, traffic share count is 1
The solution to this problem is to configure a static route to Null0 for 192.168.0.0/16 on cust−R2.
cust−R2# conf t Enter configuration commands, one per line.  End with CNTL/Z.
cust−R2(config)# ip route 192.168.0.0 255.255.0.0 Null0 cust−R2(config)# end cust−R2# *Oct  6
09:53:18.015: %SYS−5−CONFIG_I: Configured from console by console cust−R2# show ip route
192.168.20.1 Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)   Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
If we now resend the ICMP request from BB−R3 to 192.168.20.1, cust−R2 sends this traffic to Null0, which triggers an ICMP
unreachable to be generated.

BB−R3# p ip 192.168.20.1 repeat 1

Type escape sequence to abort. Sending 1, 100−byte ICMP Echos to 192.168.20.1, timeout is 2
seconds:
U
Success rate is 0 percent (0/1)
BB−R3#
*Oct  6 09:54:33.051: ICMP: dst (10.3.3.3) host unreachable rcv from 10.0.0.2
Note: There may be situations where the use of a summary static route to Null0 is not feasible. For example, if in the previous
example:

∙ Block 192.168.1.0/24 is connected to another router which dials into cust−R2 via ISDN
∙ ISP−R1 does not allocate 192.168.0.0/16 but only 192.168.1.0/24
 ∙ A disconnection of the ISDN link occurs

Note: The result would be that packets in transit or applications that attempt to reach this block of IP addresses create the
same routing loop described earlier.
Note: To fix this routing loop, you must use the ip route 192.168.1.0 255.255.255.0 Null0 200 command to configure a floating
static route to Null0 for 192.168.1.0/24. The 200 in the command is the administrative distance. Refer to What Is Administrative
Distance? for more information.
Note: Because we use a higher administrative distance than any routing protocol, if the route to
192.168.1.0/24  via the ISDN link becomes inactive, cust−R2 installs a floating static route. Packets are then sent to Null0 until
the ISDN link becomes active.

OSPF
OSPF BY SUDEB on IOS & IOS-XR
 
OSPF
stored
to advertises
in a local
construct link-state
database
a loop-free advertisements
called
topology the (LSAs)
link-state
of shortest that
database
paths. contain
OSPF runs the
(LSDB). link state and89.
onAllIpv4 protocol
OSPF routerslink
runmetric
DRtocommunicate
neighboring
the Dijkstra
OSPF routers.
Shortest Path FirstReceived LSAs are
(SPF) algorithm
on 224.0.0.5 multicast
 
OSPF packet types – Hello, DBD (database descriptor), LSR (Link state request), LSU (update), Link state acknowledge.
OSPF hello packet: On point-to-point & Broadcast network OSPF sends hello on 10 seconds & dead timer 40 seconds. (10x4)
On point-to-multipoint & NBMA network hello sent on 30 seconds & dead timer 120 seconds (30x4)
OSPF hello packet contains the following information – Hello & Dead interval, Router ID, Area ID, Interface mask, interface priority, DR
& BDR router, Authentication, Active neighbor.
Config-if# ip ospf hello interval 1-65535 & Config-if#  ip ospf dead-interval 1-65535
OSPF router ID (32 bits) selection – Router manually configure with router id, If no RID mention then ip address highest UP/UP
loopback interface set as RID, If loopback not configure then ip address of highest up/up physical interface set as RID.
IOS XR Use the lowest IP address of any up/up loopback interface. If no loopback set then lowest physical up ip address selected.  
8 OSPF Neighbor State
Down No Hellos have been received from this neighbor for more than the dead interval. 
Attempt Used when the neighbor is manually defined with the neighbor command, after sending a Hello, but before
receiving a Hello from that neighbor.
Init A Hello has been received from the neighbor but it did not have the local router’s RID in it. This is a
permanent state when Hello parameters do not match.
2 Way A Hello parameter match from the neighbor. DR BDR election process start.  
ExStart Routers identify which router will be the DR & BDR. 1st stage of forming adjacency started.  
Exchange Routers are exchanging link states via DBD packets.
Loading LSR packets sent to the neighbor asking for LSA that have been discovered in Exchange state.
Full Neighbors are fully adjacent, meaning they believe that their LSDBs for that area are identical. Routing table
(re)calculations can begin.
**NON dr & bdr (DR other) routers are only adjacent (full state) with dr & bdr & they are on 2way state with other router.
■
OSPF
OSPF
The
quits
subnetsends
ifhas
neighbor
sending multicast
been
OSPFsubnet
passive-interface:
OSPF &Hello
enabled
area
works
is enabled on
just
Hellos, messages
so
on the
must
like doeson
itinterface,
match
theinterface,
the router LAN
with
will either
but theinterfaces
EIGRP.
not all through
advertising
discover
other to discover
In short, when
neighbors.
OSPF OSPF
the network router
router.aRID onneighbors,
should
router
The
processing configures
router
the will stillwhen
subcommand
be unique,
interface an two
or
MTU requirements
the ip
interface
advertise
is ospf
match.
as
about
stopped. passive
the
 RIP areOSPF,
to met:connected
area interface
interface’s subcommand.
OSPF
passive-interface will
OSPF configure on IOS –                                                 

1. Router ospf 1

                Network 192.168.1.0 0.0.0.255 area 0                **any ip on network 192.168.1.0 will match.

2. Router ospf 1

                Network 192.168.1.1 0.0.0.0 area 0                **only match the explicit ip address

3. Config-if)#ip ospf 1 area 0                                 **This allow interface primary & secondary ip to participate.
4. Router ospf 1

Network 0.0.0.0 255.255.255.255 area 0                **this allow ospf configure for all interfaces.
 OSPF configure on IOS-XR –
router ospf 1
area 0
           interface GigabitEthernet 0/0/0/0                        ** Interface participate in process & areas.
Show ip ospf interface brief & Show ospf interface brief (XR) – Will show the interface, process ID, address-mask, cost, state,
Neighbors, NBRS F – Number of neighbor routers fully adjacent, NBRS C – Number of neighbor detected & in 2-way state.

Show IP ospf neighbor & Show ospf neighbor (XR) – Will show the Neighbor Router ID, Priority, State, Dead time, Neighbor interface
Address, Local interface, Uptime for IOS-XR, IOS neighbor uptime shown in – neighbor detail command.
DR & BDR (Designated & Backup designated router) –
On a multi-access network if all routers flood LSAs without the DR BDR. The routers have to form many adjacencies with each other
which will result LSA flood & high cpu utilization. So the DR BDR reduce the number of OSPF adjacencies on network segment
because routers only form a full OSPF adjacency with the DR & BDR and not each other. If DR fails BDR become the DR  
Setting the ospf priority to 0 will remove the interface from DR/BDR election. The default priority is 1. Higher priority wins.
OSPF4. Use
Step
Step DR election
1. The
3. Use router process:
with highest
the highest IP addresspriority (default
of any up/up1non-loopback
max 255,interface.
loopback set interface.
with ip ospf priority value interface sub-com)
RP/0/0/CPU0:XR1(cofig)# router ospf 1
router-id 192.168.1.1
priority 200
Link
So Cost: Link
formula
fast – COSTcost
2 Ethernet,
(config-router)#
Other options is essential
=Gigabit
reference
auto-cost
are on Ethernet for & shortest
bandwidth 10 / cost
Gigabit
reference-bandwidth
interface - ip ospf path
interface metric
Ethernet
1000. calculation.
bandwidth. The
all
xx & bandwidth OSPF
costxxto 1.default
To assign
break linkbandwidth
reference
the TIE cost
we (metric)
need formbps.
toischange
100 anthe
interface
So for based
reference on a
bandwidth.
OSPF AUTHENTICATION  TYPE                           
Type Meaning    Enabling interface sub-command       Authentication key conf.   
0 None ip ospf authentication null  -
1 Clear text Ip ospf authentication  Ip ospf authentication-key key-value 
2 MD5 Ip ospf authentication message digest  Ip ospf message-digest-key key-number Md5 key-value 
flaps&SPF
calculation.tree calculation
Also no route willrouters.
–run. AsBy
summarization the router
route increase forCreating
an areabinary
all–routers consume more memory –& =taking long time for SPF
area
Dotted
Binary
decimal make
decimal
– less
11111111.
area impact
area
number on
calculation
conversation
11111111.
& vice 11111111.
versa. – design
– Decimal
BinarySo if Area
00000000.
we ais836.
11111111 possible.
get normal areas
Convert
00000000.
| Dotted
decimal connect
areaitdecimal
into different
00000000.
1000 we through areas
area
–convert
00000000
can 0will
| to
255.255.255.255. restrict
itbackbone.
 Dotted
dotted any
0-0.0-0.00000011.01000100
Decimal
All dotted network
decimal convergence
0.0.768+68=836
0.0.0.0
decimal together
following way.will
1000within
create the
to binary
decimal - 1000 512 256 128 64 32 16 8 4 2 1
binary 1 1 1 1 1 0 1 0 0 0
dotted decimal 3. 232
So decimal
Same area0.0.3.68
way area 1000 can canbebewritten as – 0.0.3.232
converted to decimal (768+232=1000)
area as –
dotted decimal 3 68
binary 1 1 0 1 0 0 0 1 0 0
decimal 512 256 128 64 32 16 8 4 2 1
Add the on bits of 1  & 2  octets – (512+256) + (64+4) = 836    |   It’s the same way as IP Address written on devices –

ABRs holdrouter: Any
Backbone topology data for that
router eachhas
area,
at and
leastcalculate routesconnected
one interface for each area,
to theand advertise
backbone about those routes between areas.
area.

ASBR – Autonomous System Boundary Router redistributes routes into an OSPF domain from any other ospf process or other routing
domain. An ASBR can be any OSPF router. An OSPF router can be an ASBR and ABR at the same time.

OSPF routes types –

R3 route O means same area (intra area) route, XR5 route O IA means other area (inter area) route, R6 route O E2 & O E1 means
external route. Difference between E2 & E1 routes –
Type 1 routes are preferred over Type 2. Type 1 metric equals the Redistribution Metric + Total Path Metric to the ASBR. The Type 2
metric equals only the redistribution metric (default 20) & remains same as it goes router by route.
OSPF
Number
Link haveLSA
LSA, Age –
Transit: A types
ofnot
Links:
connected
transit – OSPF LSA
AgePoint-to-point
time of lsa,
1a Transit
to:
network contains
expire
Network
indicates &that /the
renew anfollowing
after
 point-to-point
adjacency every field. Link
30 Stub
 /
has ID –
minutes. Link
been Network
formed number, ADV
count –
and Number Router –
ofbeen Advertising
linkselected
on router. router’s RID for this
Point-to-point:
that become links
adjacent with indicate
another an adjacency
OSPF router has
are been formed
classified as a that
on stubanetwork
DR has
a network type
linkthat does
type. on that
not use alink.
DR.
 
      LSA TYPE   | NAME        |                                                              DESCRIPTION 
1 Router link Each router creates its own Type 1 LSA to represent itself for each area to which it connects.
The LSDB for one area contains one Type 1 LSA per router per area, listing the RID and all
interface IP addresses on that router that are in that area. Represents stub networks as well.
2 Network link Ospf router chooses whether to use the type 2 lsa for a multi-access network based on a DR
has elect or not. The designated router on a broadcast segment (e.g. Ethernet) lists which
routers are joined together by the segment. Type 2 LSAs are flooded across their own area
only. The link-state ID of the type 2 LSA is the IP interface address of the DR.
3 Summary link ABRs do not forward Type 1 and Type 2 LSAs from one area into another area, and vice versa.
Routers still need to learn about subnets in other areas. OSPF advertises these interarea
routes using the Type 3 summary LSA. ABRs generate a Type 3 LSA for each subnet in one
area, and advertises each Type 3 LSA into the other areas.
4 ASBR summary Type 4 LSA provides a way for routers to locate the ASBR when the router is in a different area
from the ASBR..
5 AS external An ASBR injects external routes as Type 7 LSAs in an NSSA area. The ABR does not advertise
Type 7 LSAs outside of the originating NSSA area but converts the Type 7 LSA into Type 5
LSA for
the other OSPF areas. If the Type 5 LSA crosses Area 0, the second ABR creates a Type 4 LSA
for the Type 5 LSA.
6 Group Defined for MOSPF; not supported by Cisco IOS.
membership
7 NSSA external Created by ASBRs inside an NSSA area, instead of a type 5 LSA.
8 External attributes Not implemented in Cisco routers.
9-11 Opaque Used as generic LSAs to allow for easy future extension of OSPF; for example, type 10 has
been adapted for MPLS traffic engineering.

OSPF Path selection –  OSPF SPF algorithm select path with the following logic.

Intra-area -   Routes advertised via a Type 1 LSA for an area are always preferred over Type 3 and Type 5 LSAs. If multiple intra-area

Interarea -     Interarea
routing table. routes
All inter area takefor
paths thea lowest total go
route must path metricArea
through to the
0. destination. If there is a tie in metric, both routes install into the

External
the ASBRType
that 1advertised
-  E1 or N1the
- External OSPFASBR
network. An Type router
1 routewill
calculation
not installuses
an Othe
E1Redistribution
and O N1 routeMetric + The
into the RIBLowest Path time.
at the same MetricOto
N1reach
is

External
and O N2Type
the router route2 into
 -  E2the
compares or RIB
theN2 -
cost.External
at If
thethereOSPF
same a tieType
is time. 2 routes
inOcost,
N2 isthen do not
both
always increment
routes
given installininto
preference metric.
andthe Ifprevent
theretable.
routing
will is the
a tieASBR
Oin
E2the redistribution
router
from will not on
installing metric,
install
the an then
O E2
ASBR.
Route summarization – 
the same
area (ABR
Manual for all routers
or ASBR) andat
Summarization in a single
flooded area.
ABRs –throughout So, if
Summarization summarization
that area. 
can be is needed, the summary prefixes
  reasonable if two conditions are met – should be created at the edge of an
1.  If the subnet numbers inside an area happen to be from the same general range.
2.  None of the
advertise onesubnet
type 3 in
lsathat range
with exist in other
summarized OSPF
address. areas. Instead
Configuration of advertising
– On ABR to areadifferent
1 & areatype
2. 3 lsa for different network ABR

    

The ABR performing inter area summarization will install discard routes, a route to the Null0 interface that matches the summarized
network range. For internal discard routes IOS sets AD 110 & for external discard routes 254. IOS XR sets the AD to 254 for all discard
route, allowing another protocol to preempt the network range if present.

source. When redistributing the routes, the ASBR creates a Type 5 External LSA for each redistributed subnet.  

   

  

IP ospfoccur.
advertise network apoint-to-point –cannot
If we(host
have configure a loopback interface withfor
/24 subnet, with the help of this command OSPF only
ROUTE
could
OSPF
■
filtering tothe
uses
Filtering
R4(config)# the
R4(config-router)#
network
FILTERING
transmission
ip
of
As
distance  as
result,
following:--
routes OSPF
prefix-list
area 1
/32
----vector
LSAs. However, subnet
■logic
OSPF inside
with
Filtering
would
block50
filter-listdeny
oneroute)
and
Type
Type
normally 33area,
does
LSAs
LSAs
add toallon
not
192.168.50.0/24
prefix block50 in
routers
allow
(and
the ABRs. must
the
IPthe
routing 5know
filtering
Type LSAs
table
R3(config)# ip
R3(config-router)#area
allLSAs
of
on LSAs,
used
awe
single
prefix-list
0
orexternal
inside the
anwhole
router.
block50
filter-list
area, SPF
routes).
deny
prefix
concept
specifically
block50
As
 Configuration fails,
the
a result
out---**
192.168.50.0/24 Type
IOS
Check
and routing
1 and
limits
that R4
Type
OSPF
is
loops
2route
LSAs.
filtering
area
Incase
GE &
mylist 1
LEwith
the
–
seq in
GE
10 command
filtering occurs
represents
permit & R3
at
minimumis
area
172.16.25.0/24 filtering
0, we area
have
prefix-length0
to with
put
to –out
be
This will allow (match) the exact network 172.16.25.0/24 to pass the list.outcommand.
&
match.for
  other
From Both
area
GE the
valueresult
have
to thewill
to be
put -
prefix same.
in.
length value.  

ip prefix-list mylist seq 10 permit 172.16.0.0/16 ge 24 le 26

This will take
Forthe
172.16.0.0/16
up tolist
/32. entire
would class
actually
example: ip B network
fail thethe 172.16.0.0/16
list10.10.10.0/24
because it and
does apass
not haveonly
aForsubnets
prefix
orof with
/24, a/28
/25/24, /25
/32 orwill
orgreater.
/26. /26allow.
prefix. So the exact network
This
subnet
specified specifies any
10.10.10.0/24
will pass. is,prefix-list
subnet
would
That within
lefail mylist
all because
the way itseq
does
down 10 permit
tonot
the have 10.10.10.0/24
range
prefix that
prefix
listed.has
of /28ge 28
aexample:
prefix of /28
greater. or to Again, the exact

ip prefix-list
This
10.64.0.0/16 mylist
list specifies
would seq
any 10because
pass permit
subnet 10.64.0.0/16
within
it the le in
has10.64.0.0/16
a prefix 23therange
rangethat
/16has a prefix
to /23 between
but any range /16
lessand /23.
than /16Inwill
thisnot
case theThe
pass. exact subnet
"permit any

ip prefix-list mylist seq 200 permit 0.0.0.0/0 le 32

 

Filtering
If
cananonly
area OSPF
has
filter Routes
20
the LSA Added
routers and
from to the
the
being Routing
engineer
flooded Table----
wants to filter
throughout thefive of
entire the
area. routers, Type
Filtering &3table
LSA affected.
filtering
with distribute cannot
lists allowsbeindividual
used.adding
Type 3 them
LSAtofiltering
has
that been
router’s
**The
want ipIPconfigured
routing
distribute-list
itroute
learn through
40.0 from
prefix-list
prefix-list
with
table.
must
LSDB.
area a distribute-list
However
combine
2In&
block-rtable
block-rtable the
2.0
seq the
above
seqfrom
15 10 anin OSPF
LSDB
with example
area
deny
deny –router
doesn’t affect
access-list
R1
1 (same or subcommand,
leby
routing
area)
192.168.40.0/24
192.168.2.0/24 to this
prefix-list
le
25 table
be25
ip only
or
has
filtered
ip that
the
all
prefix-list
router
onrouting
route-map
the
R1.route
So then filters
permit
R3exceptor50.0the
deny
configuration routes
which is before
Claus.
should filter
be –at  R3routers
& R4. Now filter
to that
we
  router ospf 1  network 192.168.0.0
0.0.0.255 area 1  network 192.168.1.0
0.0.0.255 area 1  distribute-list prefix
block-rtable in

R1#show ip route
O IA 192.168.30.0/24 [110/138] via 192.168.1.2, 00:10:39, Serial1/1
                     [110/138] via 192.168.0.2, 00:10:39, Serial1/0
O IA 192.168.10.0/24 [110/74] via 192.168.1.2, 00:10:39, Serial1/1
                     [110/74] via 192.168.0.2, 00:10:39, Serial1/0
O IA 192.168.20.0/24 [110/74] via 192.168.1.2, 00:10:39, Serial1/1
                     [110/74] via 192.168.0.2, 00:10:39, Serial1/0
C    192.168.0.0/24 is directly connected, Serial1/0
C    192.168.1.0/24 is directly connected, Serial1/1
         192.168.3.0/24 [110/128] via 192.168.1.2, 00:10:41, Serial1/1  
 
towards a router that connected to ISP router (for internet).  

ASBR
choose
Secondconnected
aadefault
design
advertise to thefor
route
– remote
default route Internet. The
internet.
routers
to in ASBR
area could
a 1type
use learnroute
3default routes with
to to
reachBGP. Rather
enterprise, than
ABR redistribute
usethe
the area all BGP routes
0external
range into the
0.0.0.0 Enterprise,
0.0.0.0 command the
to
The other
OSPF tool itanlike
is default-informationarea
subcommand default-information
route–0.0.0.0/0–and flood as
anyoriginate, a
other LSA.
default route
originate tells
Type 5 LSA. OSPF be
to flooded
create athroughout
Type 5 LSA OSPF
(used fordomain. As a result,
routes) for it
a is most useful
default
ISP advertising a default route. All the routers then learn a default route, based on the Type 5 LSAs for 0.0.0.0/0 as flooded by
the ASBRs.
0.0.0.0/0.
Enterprise If a
ASBR2itsrouter
routers has withdraws
been
willexists configured
]forward its OSPF
traffic toto default
advertise route
its when
OSPF its
defaultownwithIP route
a lowerto 0.0.0.0/0
metric (1) fails,
than OSPF
doesa allows
ASBR1 to fail
(metricover to
30), the
so other
the
will
■
■ withdraw
[route-map 
only if a
With all map-name
default
default OSPF
the always parameter,
The metric-type keyword
((((((((“Redistribution
The decision of when
default
parameters,
route into to
route.
itthat
inbetween
OSPF”the
defines
advertise,
The
injects athe
router’s
default
whether
discusses
and
onlyInternet
defaultremaining
routing
routethe
OSPF
when is route
LSA
to
through
table.
advertised
is
external
OSPF
into
listed
withdraw,
ASBR2.
OSPF,default
even
as
route
the as However,
anroute
ifinformation
there
external
types.)))))))
default
will
External
is no
type
route 1
is
ifdefault
or
ISP1
be thequits
Type one
2onroute,
route
external
based
advertising
that
type
matching
leads
inusing
the
2
to
router’sthat
Type
(default).
the
default
ASBR1,
5
routing
 
with
making
LSA, with
table.BGP,
use
metric
referenced route-map with
ASBR2
of1,the
buta
permit
OSPF
external
(based action.
stub
routes
on the The
router difference
floods
(LSA5)
default & default
may
route), not
but routes
flood
the redistribute
inside
summary
routers an
require static
area.
routes
lessABRS & default
(LSA3).
memory in a stub
All
and area
routers in originate
advertise
the
processing. Stubstuba is,
default
area
area with
can redistribute
route
still
summary in stub
route
– to static
area
the & all the
don’t advertise
destinations
■
ABRs
■ ABRs do
Routers
All
based not
may
Therouters
default flood
not
inside
on this route Type
flood
stubhas
inmismatched
the area 5
areasLSAs
other
must Type
a metric
cannotinto3 the
LSAs
be configured
configuration. stub
into
of 1redistribute
unless to area.
the
be area.
otherwise
external
stubby; configured
routes
if not, into using the
the stubby
neighbor OSPF area,
relationships subcommand area 
because
cannotthat formwould area-num 
betweenrequire 5 LSAcost
default-cost 
a Typeneighbors
potential .
in the

Four types of stubby areas exist: stub, totally stubby, not-so-stubby areas (NSSA), and totally NSSA.
Lsa type Stubby Totally stubby NSSA Totally NSSA
ABR flood LSA3 into the area   Allow Block Allow Block
ABR floods LSA5 into the area Block Block Block Block
Stub router floods default route into the Allow Allow Block Block
area
ABR floods LSA7 into the area Block Block Allow Allow

Stub
route area configuration
 192.168.30.0/24 – 
[110/74]
O
C
O
C
O
IA 192.168.40.0/24
  IA 192.168.10.0/24
192.168.0.0/24 is directlyvia
[110/74]
directly
192.168.1.0/24 [110/138]
IA 192.168.50.0/24
192.168.3.0/24 is
[110/138]
via
via192.168.50.1,
192.168.40.1,
connected,
192.168.40.1,
connected,
via
00:46:05,
00:44:51,FastEthernet0/0
Serial0/0
00:44:51, Serial0/0
00:44:53, Serial0/0
FastEthernet0/0
192.168.40.1, Serial0/0

O*IA 0.0.0.0/0
A default route[110/65] via&192.168.40.1,
is created 00:46:07,
R6 & R7 learned Serial0/0
the other area route via lsa 3. However R5 ip route will not show any default route. 
 

Totally
The
R1#sh stubby
default-cost
extra
ip area configuration
500
R1(config-router)#area
keyword no-summary refers
route –   to the   fact
1 stubconnected,
no-summary  00:00:06,
     that
       ABRs
   Serial1/0
    R2(config-router)#area 1 stub
in totally stubby areas do no-summary Type
not create/flood          3   summary
  LSAs. area 34
C
O    192.168.0.0/24
 192.168.1.0/24
 192.168.2.0/24 is directly
[110/128] via Serial1/0
Serial1/1
192.168.0.2,

O*IA
As no0.0.0.0/0 [110/65]
type 3 LSA via 192.168.0.2,
is created 00:00:06,
so the ip route commandSerial1/0
only tells about the default route.
 

NSSA area –  
R1(config-router)#area
R3(config)#router ospf
R3(config-router)#area 34 nssa no-summary         R2(config-router)#area
1 LSAs
                           R4(config)#router 34
ospf 1     doesn’t
 taking nssa no-summary 
To configure totally
Step
OSPF.
Step 2. Route
3. R3 floods
4. ABRs R1 Type
and R2734
redistribution nssa
NSSA just
then                  
configured
throughout
convert type         R4(config-router)#area
put no-summary after nssa command.
using redistribute command,
7stub
LSAs area 34type
into as stub
5 as area 34to
See
it’s carry nssa
the above
the
allow
area forimage
routes
0 lsa5.
the --- Step
learned with
subnet 1. ASBR
learned R3 area
EIGRP,from
and injecting them 0into
34. (Area is not a

OSPF
An virtual
OSPF
nonbackbone link
virtual -   even
link
area, allows twoseparated
when ABRs that by
connect to therouters
many other same nonbackbone
and subnets. area
This to formlink
virtual a neighbor
acts likerelationship through that
a virtual point-to-point

The ABRs connected to the virtual link has couple of difference than normal ABR. These are –  
1. ABRs send all OSPF messages as unicasts to the IP address of the router on the other end of the link.
2. The router
expect the also
lsa tosend the (DNA)over
be reflooded don’t age
the bit inlink
virtual theon
lsathe
which means
usual all router
30 minutes on the
refresh other side of the  virtual link will not
interval.

Configuration
R1 & area
side R3 abr
of R3) As–  
0. are aconnected to area
result in R4's 1 & 0. Default
database, ospf characteristics
only network don’t is
- 10.0,4.0,3.0,2.0,1.0 allow the left
added. side area -020.0,0.0,1.0,2.0,3.0.
R2 database to communicate with thewe
** So right

R3(config-router)#area
Now R4 will
ip get the rest1ofvirtual-link
the network192.168.1.1
 -  0.0,       (RID
       20.0 R2ofthe
& “In R1)
- 4.0, 10.0 Monitoring
R1#show
ospf neighbor
Neighbor
In the area ospf
viavirtual-links 
0 detail
192.168.4.2, 192.168.4.2 
interface
interface address
OSPF_VL0 192.168.3.1 ** area 0 via
exist 0 -  OSPF VL0,” confirming that the neighborship     doesn’t
interface
in area

There are scenario such as two normal area connected together without area 0 in between –  

 
With this R2
between
mentioned scenario it–requires
& R3 here.
earlier without the
Because
RID virtual
of twolink routers
is on area
established
routers in which to2the
arelink
virtual notestablish.
reachable
transit to areaa0backbone
or&even
area byR2’s-2.2.2.2
which area
area1&asa area 01should
normal
R3’s-3.3.3.3 2#area an area stay between
connect.
virtual-link 3.3.3.3As
R3# area 1 virtual-link 2.2.2.2
 
Difference of using area filter-list & distribute-list
  
Area 2prevent
prefix-list &prefix-list
Eigrp
& denynetwork
3.4 both
network. have
On 3.4/30
R4 to network
configure
          -ip inisrouting
Area table.
2   filter-list Now
prefix we this
need toin.filter
‘prefix-list’ This3.4 will network
filter soon
3.4  Area
–anetwork2. from
Now ifredistributed
we configure
routerouting table buta
 can’t
policy
R4#       ip
prefix-list
  EX
R7#sh
D it
ipcan
reaching
be reachable.
deny-3.4
  distribute-list
route deny-3.4
eigrp
 192.168.4.4
 192.168.4.0
 192.168.0.4
 192.168.1.0
seq
prefixto
20
| inc
3.4
So
seqnetwork.
EXwe
deny need Because
50.0.0.0/0
deny
deny-3.4
D
[170/284160] apply
192.168.3.4/30
in 192.168.100.1,
via
R1 configured
Distribute-list
prefix-list with
      deny-3.4
01:21:11,
01:21:11,
ip default
toFastEthernet0/1
overcome information
situation. originate
Here is how default
D
D*EXEX
getting
R7#ping  192.168.2.0
 192.168.3.0
0.0.0.0/0
the [170/284160]
[170/284160]
default
192.168.3.6 route but itvia via 192.168.100.1,
192.168.100.1,
can’t reach to 3.4 02:30:46, 02:30:56,
01:21:11,
network FastEthernet0/1
FastEthernet0/1   Although            it’s
               ***  No 3.4 network
U.U.U.

BGP

BGP on IOS & IOS XR by Sudeb

BGP basic characteristic – Border Gateway Protocol (BGP) as a standardized path vector routing protocol. BGP is the only
protocol used to exchange networks on the Internet. BGP does not advertise incremental updates or refresh network
advertisements like OSPF or IS-IS due to the large size of the BGP tables. BGP domain segregate by Autonomous systems (AS).
One AS doesn’t know about the IGP protocol of other AS. BGP doesn’t require the neighbor to be attached on the same subnet
or directly connected like IGP instead BGP routers use TCP connection to pass BGP messages between each other, whereas
neighbor can be on same subnet or different subnet connected directly or through IGP. Instead of choosing the best route by
using metric, BGP uses a more complex process, using a variety of information, called BGP path attributes. BGP use TCP port
number 179 for all communication.
 Difference with IGP (EIGRP, OSPF) & EGP (BGP) –
OSPF / EIGRP BGP
Forms neighbor relationship before sending routing SAME
information
Neighbors typically discovered using multicast packets Neighbor IP address is explicitly configured and may not be on
(224.0.0.x) on the connected subnets same subnet.
Does not use TCP Uses a TCP connection between neighbors (port 179).
Advertises prefix/length Advertises prefix/length, called Network Layer Reachability
Information (NLRI.)
Advertises metric information Advertises a variety of path attributes (PA) that BGP uses instead
of a metric to choose the best path.
Emphasis on fast convergence to the truly most efficient Emphasis on scalability; may not always choose the most
route efficient route.
Link state (OSPF) or distance vector (EIGRP) logic Path vector logic (similar to distance vector).
BGP messages –
BGP neighbors are defined by IP address & use to communicate through TCP port 179. BGP peer doesn’t send hello packet to
its neighbor because hello can’t cross network boundaries. BGP neighbor can be few hops away. IGP protocol or static route
helps to establish connectivity & session on port (show tcp brief). BGP communication uses four message types:
OPEN message -   The open message is used to establish a BGP adjacency. Open message contains BGP version number, ASN
of the
local router, hold time, BGP router-id or identifier.
Update message – Advertise, update or withdraw routes.
Notification – Indicate error condition to a BGP neighbor
Keepalive – Ensure BGP neighbors are still alive. Cisco default keepalive message sends every 60 seconds.
BGP Holdtime - Default holdtimer for Cisco router is 180 seconds, upon receipt of keepalive or update the timer reset to initial
value. If the value reaches 0 bgp neighbor declared down.  
BGP router id – A 32 Bit unique ID. Router-ID can be set manually. If not set then highest loopback ip for IOS & lowest loopback
ip for IOS-XR set as RID. If no loopback present then physical ip set as RID same way.  
EBGP & IBGP –         
A BGP router can establish 2 types of neighborship or peering. When peering with a neighbor in different AS is called Ebgp &
peering with a neighbor in same AS is called Ibgp. Ad value for ebgp is 20 & for ibgp 200
Ebgp peering : Ebgp neighbor can be multihop away. It’s TTL defaults to 1. For loop prevention it use AS_PATH attributes - IF
receive an update from an ebgp peer with its own ASN in the AS path, discard it.
Ibgp perring : Ibgp peers must be fully mesh & use same AS number for all. For Loop prevention - routes learned from an IBGP
peer can’t be advertise to another iBGP peer. It doesn’t advertise own AS path to IBGP neighbor. Ibgp peering calculation
formula –
x(x-1)/2. So 10 ibgp neighbors will create 45 sessions.  

R1 router is in AS 65512. It establish EBGP peer with R2 in AS 200 & R4 in AS 400 (via igp with R5).
R1 router establish IBGP neighborship with R6 & R7 in same AS. R6 & R7 also creates neighborship between them to make it a
full-mesh. Although they are fully meshed but R1 & R6 will not advertise lan subnet learn from R7 to each other to prevent loop.
BGP neighbor states –
IDLE, CONNECT, ACTIVE, OPEN-SENT, OPEN-CONFIRM, ESTABLISHED
Idle – BGP detects & tries to initiate a TCP connection to the BGP peer and listens for a new connect from a peer router.
Connect - BGP initiates the TCP connection. If the three-way TCP handshake completes, the BGP process sends the open
message to
the neighbor and changes to the OpenSent state. If tcp connection failed the state moved to Active.
Active – In this stage bgp starts a new 3-way handshake. If successful it moves to opensent. If fail it move back to connect.
OpenSent – Open message sent & once it receive open message from peer it checks for version, source ip, asn, rid, password,
ttl.  
OpenConfirm - BGP waits for a keepalive or notification message. After receiving a neighbor’s keepalive, the state moved to
established. If the hold timer expires or a notification message is received, the state is moved to idle.
Established - BGP session is established. Update and keepalive messages are received. BGP neighbors exchange routes.
  
Private & Public ASN -
1 to 64495 = For public use.         |        65512 to 65534 = for private use
Address-Family & MP BGP –
The normal version of BGP only supported IPv4 unicast. Which is activated by default. All the other stuff like IPv4 multicast,
IPv6 unicast/multicast, and VPN routes are disabled by default so that’s why we need to activate them. MBGP has the capability
of adding extensions called address family identifiers (AFIs). Every address family maintains a separate database and
configuration in BGP. MP-BGP routers can become neighbors using IPv4 addresses and exchange IPv6 prefixes. This allows for
a routing policy in one address family to differ from a routing policy in a different address family even though the router uses
the same BGP session to the other router.
BGP configure –                 
ON IOS with IPv4 address-family enable
router bgp 100
neighbor 10.12.1.2 remote-as 100
With IPv4 address-family Disable -
router bgp 100
  no bgp default ipv4-unicast                   (disable the default behavior)
  neighbor 10.12.1.1 remote-as 100
!
address-family ipv4
  neighbor 10.12.1.1 activate                (Activate the neighbor)
exit-address-family
ON IOS-XR –
router bgp 100
bgp router-id 192.168.1.1
address-family ipv4 unicast
!
neighbor 10.12.1.2                        (Don’t need to activate)
remote-as 100
address-family ipv4 unicast
BGP IPv4 session summary verification –

Network advertisement -
BGP network statements do not enable BGP for a specific interface; instead, they identify a specific network prefix to be
installed into the BGP table. The network prefix can be a connected network, secondary connected network, or any route which
is reachable through any routing protocol of that router. As the BGP prefix installs the following PA are set –
For connected network - Next HOP attribute is set to 0.0.0.0. Origin attribute is set to i (IGP). Weight is set to 32768.
For static or routing protocol - Next HOP attribute is set to next-hop ip address. Origin set to i (IGP). Weight is set to 32768.

BGP Path attributes –

In BGP, the network layer reachability information (NLRI) is the routing update that consists of the network prefix, prefix-length,
and any BGP path attributes for that specific route. BGP attaches path attributes (PAs) associated with each network path. The
BGP prefix attributes are classified as follows: Well-known mandatory & Well-known discretionary, Optional transitive & non
transitive. Well-known mandatory attributes must be included with every prefix advertisement. Whereas well-known
discretionary attributes may or may not include. Optional not supported for all implementation.
Well known mandatory attributes – NEXT-HOP, AS-PATH, ORIGIN, Well known discretionary - LOCAL_PREF
Optional – Weight, MED, Community.
BGP works through these attributes in this specific order when choosing a path.
BEST PATH SELECTION –
 (Remember)        NWLLA OMNI
N - Next hop reachable?, W – Weight, L - Local pref, L - Locally originated routes, A - AS_Path, O - Origin (I, E or ?), M - MED
N - Neighbor type (eBGP over iBGP), I - IGP metric to next-hop
Next-Hop-Reachibility –
First rule of BGP is for a route to be installed into the routing table, its must be able to reach the next hop. The reachability
requires by any routing protocol or static route.
Weight –
Cisco proprietary. Weight is a 16-bit value (0–65,535) assigned locally on the router and is not advertised to other routers.
The path with the higher weight is preferred. Default weight is 0. Weight is not advertised to peers and influences only outbound
traffic from a router it configured. Weight can be set for all prefixes received from a neighbor using the command
neighbor ip-address weight weight on IOS routers, and the command weight weight on IOS XR routers.
 XR4 R6
router bgp 400 router bgp 400
address-family ipv4 unicast no bgp default ipv4-unicast
! neighbor AS400 peer-group
neighbor-group AS400 neighbor AS400 remote-as 400
remote-as 400 neighbor AS400 update-source Loopback0
update-source Loopback0 neighbor 10.36.1.3 remote-as 300
address-family ipv4 unicast neighbor 192.168.4.4 peer-group AS400
next-hop-self neighbor 192.168.5.5 peer-group AS400
! !
neighbor 192.168.5.5 address-family ipv4
use neighbor-group AS400 neighbor AS400 next-hop-self
! neighbor 10.36.1.3 activate
neighbor 192.168.6.6 neighbor 10.36.1.3 route-map AS300 in
use neighbor-group AS400 neighbor 192.168.4.4 activate
! neighbor 192.168.5.5 activate
neighbor 10.24.1.2 exit-address-family
remote-as 200 !
address-family ipv4 unicast  ip prefix-list PRE172 permit 172.16.0.0/24
route-policy AS200 in !
!  route-map AS300 permit 10
route-policy AS200 match ip address prefix-list PRE172
if destination in (172.24.0.0/24) then set weight 333
set weight 222 route-map AS300 permit 20
endif
pass

Only R6 has got the weight of 333 for destination 172.16.0.0 as best path. R6 doesn’t inform that to R5.
Local Preference –
Local pref is multivendor supported. The local preference attribute is a 32-bit value (0–4,294,967,295) & it advertise throughout
the same AS. A higher value is preferred. Default Local preference is 100. The local preference is not advertised to eBGP peers.
It influence the outbound routes only. Local preference for specific routes can be set via a route map or route policy & Local
preference for all routes received by a neighbor can be set with the command neighbor ipaddress local-preference
preference on IOS routers. On IOS XR localpreference preference.                
  Xr4 R6
Config omitted ---- Config omitted ----
neighbor 10.24.1.2 neighbor 10.36.1.3 remote-as 300
remote-as 200 neighbor 10.36.1.3 route-map AS300 in
route-policy AS200 in !
! ip prefix-list PRE172 permit 172.16.0.0/24
route-policy AS200 !
if destination in (172.24.0.0/24) then route-map AS300 permit 10
set local-preference 222 match ip address prefix-list PRE172
endif set local-preference 333
pass route-map AS300 permit 20
end-policy

XR4 is learning 172.24.0.0 with local pref 222 & it’s updating it to neighbor XR5. For 172.16.0.0 route XR4 is preferring Ibgp peer
R6 over it’s ebgp peer R2 as local pref is set higher on R6 for destination 172.16.0.0.  
Locally originated routes –
Locally Originated via Network or Aggregate command. The preference given with following order -
Routes that were advertised locally, Routes that have been aggregated locally, Routes received from a BGP peer. Next hop will
show as 0.0.0.0 & Weight will show as 32768 on show ip bgp.

AS_Path –
The path length calculates to the autonomous system hop count. A shorter AS_Path is preferred over a longer AS_Path.
We can manually increase the AS_Path hop count to make the path less preferable with the command set as-path prepend.  
 XR4 R6
Config omitted – Config omitted –
neighbor 10.24.1.2 neighbor 10.36.1.3 route-map AS300 in
route-policy AS200 in !
! ip prefix-list PRE172 permit 172.16.0.0/24
route-policy AS200 !
if destination in (172.24.0.0/24) then route-map AS300 permit 10
prepend as-path 200 match ip address prefix-list PRE172
endif set as-path prepend 300
pass route-map AS300 permit 20
end-policy
XR4 is getting 172.24.0.0 with prepend AS_path (200). XR5 is ignoring the high AS_path count route & reaching through R6 for
the destination 172.24.0.0.  
Origin Type –
BGP well-known mandatory attribute is origin. Networks that are advertised via the network statement are set with the IGP or
i origin, and route originated from a routing process other than BGP, and entered BGP through redistribution from an IGP
protocol, static route, or connected route are set with incomplete or ? origin attribute.          # i> e> ?
The origin preference order is as follows: IGP origin (most), EGP origin, Incomplete origin (least)
Origin can be set manually through the following command on IOS-XR & IOS –
neighbor 10.24.1.2 neighbor 10.36.1.3 route-map AS300 in
route-policy AS200 in !
! ip prefix-list PRE172 permit 172.16.0.0/24
route-policy AS200 !
if destination in (172.24.0.0/24) then route-map AS300 permit 10
set origin incomplete match ip address prefix-list PRE172
endif set origin incomplete
pass route-map AS300 permit 20
end-policy
XR4 is originating incomplete route as a result XR5 ignoring it in bgp table.
Multi-Exit Discriminator – (MED)
 is the non-transitive BGP. MED uses a 32-bit value (0–4,294,967,295) called a metric. MED’s purpose is to influence Inbound
traffic from a different autonomous system. If the MED is received from an eBGP router, it can be advertised to other iBGP
peers but should not be sent outside of the autonomous system. A lower MED is preferred over a higher MED. If no MED set
then IOS routers will advertise a MED of 0 to iBGP peers, and IOS XR advertises without a MED to ibgp peers.

R4 Config -
access-list 1 permit 10.4.0.0 0.0.255.255 router bgp 65502
route-map setMED-R3 permit 10 neighbor 192.168.30.3 route-map setMED-R3 out
 match ip address 1 neighbor 192.168.20.2 route-map setMED-R2 out
 set metric 200
!
route-map setMED-R2 permit 10
 match ip address 1
 set metric 100

 
R4 advertise 10.4.0.1 with med 100 to R2 & med 200 to R3, So All Ibgp neighbor R1, R3 will learn 10.4.0.1 from R2 IBGP.
Bgp deterministic-med and bgp always-compare-med –
Enabling the bgp deterministic-med command ensures the comparison of the MED accurately when choosing routes advertised
by different peers in the same autonomous system. Enabling the bgp always-compare-med ensures the comparison of the MED
for paths from neighbors in different autonomous systems. MED can not be compared if there are two routes from different AS
for same destination. So the next thing is the oldest route.

Med set for 5.5.5.5 subnet. Deterministic-med configure on R2. It will set 2 different group for 2 different AS 3 & 4. It will
1st check group 1 AS3 & select R3 (Med 100), then group 2 AS4 & select R4. Due to different AS the group 1 & 2 comparison
won’t happen & R2 will select ebgp route (AS 4) over Ibgp.    
R2 will learn 5.5.5.5 from AS-4. After configuring always-compare-med on R2 it will learn 5.5.5.5 from R1 with lowest med.
With deterministic-MED enable With Always-Compare-Med enable

MED config on IOS-XR-

route-policy AS200
if destination in (172.24.0.0/24) then
set med 40
endif
pass
end-policy
!
neighbor 10.24.1.2
route-policy AS200 in
!
bgp bestpath med always
** ** ** On IOS –XR deterministic MED is enable by default & can’t be disable.
EBGP OVER IBGP –
whether the route comes from an iBGP, eBGP, or confederation member autonomous system (sub-autonomous system)
peering. The best path selection order is as follows:
1. eBGP peers (most desirable)     2. Confederation member autonomous system peers  3. iBGP peers (least desirable)
IGP METRIC –
Prefer the path with the lowest IGP metric to the BGP next hop. IOS and IOS XR routers can disable the lowest IGP metric step
with the BGP address family configuration command bgp bestpath igp-metric ignore.
Prefer the Oldest EBGP Path –
BGP maintain large routing tables, and unstable sessions result in the BGP best path calculation
to execute frequently. BGP maintains stability in a network by preferring the oldest (established) BGP session. This step can be
skipped on IOS and IOS XR routers with the BGP configuration command bgp bestpath compare-routerid.
Router ID –
The next step for is to select the best path using the lowest router ID (RID) of the advertising eBGP router. If the route was
received by a route reflector (RR), the originator ID is substituted for the RID.
Minimum Cluster list length –
 If 2 or more route reflector exist in an IBGP network the client router sends update to both the RR. RR receive the path from less
cluster list length neighbor only.  It’s locally significant to an AS only.
Lowest Neighbor Address –
The last step of the BGP best path algorithm selects the path that comes from the lowest BGP neighbor address. This step is
limited to iBGP peerings because eBGP peerings use the oldest received path as the tiebreaker.
EBGP
Peering with different AS is called Ebgp peering. Following are the difference of EBgp & IBgp session. –

1. Time-To-Live (TTL) on BGP packets is set to 1. BGP packets will drop if BGP session is multihop away. (TTL on iBGP
packets is set to 255 which allows for sessions multihop away.
2. The advertising router modifies the BGP next hop to the IP address sourcing the BGP connection.
3. The advertising router prepends or add its own ASN to the existing AS_Path. (in front)
4. The receiving router verifies that the AS_Path does not contain it’s own local ASN. BGP discards if it found local asn in
path.

IOS XR requires a routing policy to be associated with an eBGP peers as a security measure to ensure that routes are not
accidentally accepted or advertised. If a route policy is not configured in the appropriate address family, routes are discarded
upon receipt, and no routes are advertised to eBGP peers. Ebgp Config –
XR IOS
router bgp 200 router bgp 100
neighbor 10.12.1.1 no bgp default ipv4-unicast
remote-as 100 neighbor 10.12.1.2 remote-as 200
address-family ipv4 unicast
route-policy PASSALL in
route-policy PASSALL out
!
route-policy PASSALL
pass
end-policy
EBGP Multihop –
 Ebgp session uses default TTL to 1. So if the peer address is multihop away e.g. peering with neighbor loopback address BGP
session could not be established. To change the TTL value following command requires –
XR IOS
neighbor 192.168.2.2 neighbor 192.168.1.1 ebgp-multihop 2
remote-as 200 neighbor 192.168.1.1 update-source Loopback 0
ebgp-multihop 2
neighbor 192.168.2.2
update-source Loopback 0
IBGP
BGP SPLIT HORIZON rule –
IBGP Split Horizon Rule states that do not send routing updates back into the same AS that you got them from. So IBGP routes
are never propagated to other IBGP peers and hence the peers need to be fully meshed.
IBGP full mesh –
 BGP routers within a single autonomous system must be fully meshed to provide a complete loop-free routing table and
prevent traffic blackholing. They must be connected through static route or routing protocol.

Peering via loopback or update-source loopback –

 if 2 IBGP neighbors connected with redundant link then best idea would be to peer with loopback interface. The loopback
interface will always stay up. In the event of link failure, the session stays intact while the IGP finds another path to the
loopback address.
XR IOS
neighbor 192.168.2.2 neighbor 192.168.1.1 remote-as 100
remote-as 100 neighbor 192.168.1.1 update-source Loopback0
update-source Loopback0
Next-hop-self –
When a router receive a route from an Ebgp peer the router advertise the route to all its Ibgp peers. The next-hop remains same
(ebgp peer ip) as it received by all IBgp neighbors. If the other Ibgp routers don’t have reachability or route to that Ebgp peer
they didn’t update it in their routing table & display in BGP table without the bestpath > sign. So we need to apply next-hop-self
command on the edge Ibgp router from which the route enters in AS.
Route reflector –
RR helps to configure less Ibgp session & thus saving router memory. All client routers establish IBGP session with RR which
reflects received routes to all RR client & secondary RR. The router reflecting routes is known as a route reflector (RR), and the
router receiving reflected routes is a route reflector client. More than 1 RR can be kept redundancy.
3 Rules involve in route reflection. Client are not aware of RR setup.

1. If an RR receives a route from a non-RR client, the RR will advertise the route to an RR client. It will not advertise the
route to a non-RR client.
 2. If a RR receives a route from a RR client, it will advertise the route to RR clients and non-RR clients. Even the RR client
that sent the advertisement will receive a copy of the route, but it discards the route because it sees itself as the route
originator.
3. If a RR receives a route from an eBGP peer, it will advertise the route to RR clients and non-RR clients.

Route reflector cluster –

Cluster ID is a 4 byte BGP attribute and it uses a BGP router ID by default. If two RR share the same BGP cluster ID, they belong
to the same cluster. Clients will only establish Ibgp session with these RRs only. If 1 RR or link to RR is down then alternate link
or 2nd RR will provide reflection. For loop prevention RR follows these rules -  

1. Before reflecting a route, Route reflectors append its cluster ID (if not set then RID will be cluster-id) to the Cluster list. If
an RR receives a route with its own cluster ID in the cluster list attribute, the route is discarded.
2. If the route is sent to EBGP peer , RR removes the cluster list attribute.
3. If the route is received from EBGP peer, RR doesn’t create a cluster list attribute. Config-----

XR IOS
neighbor 10.12.1.1 neighbor 10.34.1.4 route-reflector-client
route-reflector-client bgp cluster-id 1.1.1.1      
bgp cluster-id 1.1.1.1   or 100 (32 bit format)

RR1 & RR2 sharing same Cluster-id 1.1.1.1, Client 1 & 2 peering with RR1 & 2. Client 2 subnet 172.16.0.0 will be advertise by
both RR1 & 2. RR1 & RR2 will advertise 172.16.0.0 to each other but they will discard it as they will see the same cluster-id for
that prefix.  
 Confederations –
 A confederation include sub-autonomous systems, which combine into a larger autonomous system & represent as a single AS
to EBgp peer. Member autonomous systems normally uses ASNs from the private ASN range (64512–65,534). eBGP peers
from the confederation have no knowledge that they are peering with a confederation.
There are 2 commands related to Confederation. 1. BGP confederation id - which will be represent to different ISP.
2.  Bgp confederation peers - On routers that directly peer with another private member autonomous system.  
Config -
XR1 XR2
router bgp 65100 router bgp 65100
bgp confederation identifier 200 bgp confederation peers 65200
neighbor 172.16.1.1 bgp confederation identifier 200
remote-as 100 neighbor 10.23.1.3 remote-as 65200
R3 R4
router bgp 65200 router bgp 65200
bgp confederation identifier 200 bgp confederation identifier 200
bgp confederation peers 65100 neighbor 172.16.2.1 remote-as 300
neighbor 10.23.1.2 remote-as 65100
AS100# show bgp ipv4 unicast

RP/0/0/CPU0:XR1#show bgp ipv4 unicast

Route Summarization –
Summarizing prefixes save router resources & reduce the size of BGP table. It also provide benefits by hiding the route flaps as
it’s summarize a master network. We can summarize prefixes by following way –

1. Static - Create a static route to Null 0 for the prefix, and then advertise the network via a network statement. The
problem

with this technique is that the summary route will always be advertised even if the networks are not available.

2. Dynamic - Configure an aggregation network range. When routes that match the network range enter the BGP table, an
aggregate route is created. On the originating router, the aggregated prefix sets the next hop to Null0. The route to Null0
is automatically created by BGP as a loop-prevention mechanism.
Aggregate address – Aggregate address command with the network & mask require for summarization. Summary-only
command can be added to suppress the small subnets. BGP considers aggregated addresses as local routes.

AS-5 is hosting 172.16.1.0 & 2.0. AS-4 is summarizing 172.16.0.0/16 with the keyword summary-only. Now R2 will get the
summarize subnet 172.16.0.0. On R4 bgp table 172.16.1.0 & 2.0 will show as (s>) suppress route. R4 will have a bgp route to
172.16.0.0/16 via null 0 interface in it’s routing table for loop prevention.
If the summary-only keyword was not use then R4 would not have suppress 1.0 & 2.0 subnet. R2 will then get the 172.16.1.0, 2.0
as well as 0.0 on bgp table.  

We can unsuppressed any desired route so that neighbor can get exact prefix along with summary. Config -  
XR (R4) IOS (R4)
router bgp 4 router bgp 4
aggregate-address 172.16.0.0/16 summary-only address-family ipv4
neighbor 24.24.24.2 aggregate-address 172.16.0.0 255.255.0.0 summary-only
route-policy PASSALL in neighbor
route-policy UNSUPPRESS out 24.24.24.2 unsuppress-map UNSUPPRESS-MAP
! !
route-policy UNSUPPRESS route-map UNSUPPRESS-MAP permit 10
if destination in (172.16.1.0/24) then match ip address prefix-list UNSUPPRESS-LIST
unsuppress-route !
else ip prefix-list UNSUPPRESS-LIST seq 5 permit
pass 172.16.1.0/24
endif
Default Route Advertisement –
Default route into the BGP table requires the default route to exist in RIB & default-information-originate command is use.
XR IOS
router bgp 100 router bgp 100
default-information originate network 0.0.0.0
network 0.0.0.0/0 default-information originate
Default route advertisement as per neighbor basis –
XR IOS
neighbor 10.12.1.1 neighbor 10.35.1.5 default-originate
default-originate
Outbound Route Filtering –
 ORF allows the CE device to provide the filter to the PE router dynamically. So that on CE’s request route can be filter on PE
before it’s comes to CE. ORF is a session capability that is established when BGP establishes the peering between the two
neighbors. Each peer must support route refresh and advertises its capability to send, receive, or send and receive (both) ORFs.
The ORF senders will then send the prefix list used to filter the route advertisements.
neighbor ip-address capability orf prefix {both | send | receive}
XR IOS
neighbor 10.12.1.2 neighbor 10.12.1.1 capability orf prefix-list both
orf route-policy ORF neighbor 10.12.1.1 prefix-list ORF-PREFIXLIST in
capability orf prefix both !
! ip prefix-list ORF-PREFIXLIST seq 5 deny 172.20.0.0/13
route-policy ORF ge 14
if orf prefix in (172.16.0.0/12 le 32) then ip prefix-list ORF-PREFIXLIST seq 10 permit 0.0.0.0/0 le
drop 32
endif
if orf prefix in (0.0.0.0/0 le 32) then
pass
endif
Backdoor –
As EBGP has less AD value it will be prefer over IGP.  Occasionally, a route learned via IGP needs to take preference over a route
learned via eBGP. This can be done by using the BGP backdoor network feature. Backdoor network treated as a local network &
raise the AD value to 200 and the router prohibits the advertisement of the backdoor network to eBGP peers. Config -  

XR2 - network 10.5.5.0/24 backdoor

R4 -  network 10.1.1.0 mask 255.255.255.0 backdoor
Maximum Autonomous System –
The AS_Path is often prepended to influence traffic patterns. In some cases the prepending policies have led to problems with
routers that could not handle routes with more than 100 ASNs in the AS_Path. The solution required filtering prefixes with an
excessive number of ASNs in the AS_Path. So we set maximum as-path length or max as limit.
XR IOS
route-policy MAXAS-LIMIT router bgp 200
if as-path length ge 3 then bgp maxas-limit 3
drop
Now in the BGP table those routes which have more than 3 AS_Path length will be filtered.
Maximum Prefix –
Sometimes a router received more routes than it could handle. Prefix limits are typically set for BGP peers on low-end routers as
a safety mechanism to ensure they do not become overloaded. When a peer advertises more routes than the maximum prefix
count, the peer moves the neighbor to the idle (PfxCt) state & sends a syslog. The BGP session will not reestablish
automatically by default. The parameter for max prefix are – max prefix count, warning percentage, restart time, warning only.
E.g. –
Neighbor 1.1.1.1 maximum-prefix 100 75 restart 10 – with this command max prefix set to 100 & at 75% it will send a syslog
once it reach over 100 prefix threshold it will close the BGP session. After 10 minutes it will restart the BGP session. With
the warning only keyword it will not close the BGP session instead it will send a syslog message & discard the new learn routes
from neighbor.
Remove Private AS –
Some companies may not have their own public ASN but still want to receive internet routing table. The service provider may
assign the organization a private ASN for peering. Private ASNs should not be advertised by the service provider to other ISPs
on the Internet. So the service provider removes the private as when it advertise to public peer.

R3 will receive the 192.168.1.1 route with AS_Path 100.

Allow AS in-
 As a loop-prevention mechanism, a router will discard BGP network if it sees its ASN in the AS_Path. The allow autonomous
system feature enables routes to be received even if the router detects its own ASN in the AS_Path.

R1 & R4 will accept routes from each other with AS_Path 100. We can limit the number of occurrence of allow as.
R1# neighbor 10.12.1.2 allowas-in 1.  It will just allow 1 occurrence of 100 to be in the AS_PATH
AS Override –
Allow-as is the option which we can set on customer router but as an alternate option we can configure As override on provider
router. The command will replace the customer AS with it’s own AS when advertising to other site of same customer. E.g.
R2# neighbor 10.12.1.1 as-override    R1 will see AS_Path 1 1 for the prefix 192.168.4.4
R3# neighbor 10.34.1.4 as-override   R4 will see As_path 1 1 for the prefix 192.168.1.1
Local AS –
When an organization has change it’s AS number but from ISP side the peering configured with previous AS number against
that organization.  The local AS feature is configured on a per-peer basis, and allows for BGP sessions to establish using an
alternate ASN from the ASN that the BGP process is running on. It works only with eBGP peerings.
XR2 was using AS 200 but now BGP AS change to AS 100 but AS 300 (ISP) setup peering with XR2 with remote peer AS 200. AS
300 won’t change the peering so XR2 & R5 has to manipulate their configuration. Config -
XR2 R5
router bgp 100 router bgp 400
neighbor 10.23.1.3 neighbor 10.35.1.3 remote-as 300
remote-as 300 neighbor 10.35.1.3 local-as 500
local-as 200
 Multipath –
Bgp multipath allow number of ebgp or ibgp path to be install in RIB. The following attribute must match before multipath
works. Weight, Local Preference, AS_Path length, As_Path content, Origin, Med, Ebgp or Ibgp, IGP cost. Command –
XR - maximum-paths {ebgp | ibgp} number of paths [unequal-cost] unequal-cost keyword allows for iBGP paths to install if the
metrics to the next hop do not match.
IOS - maximum-paths number of paths / maximum-paths ibgp number of path unequal-cost.
AS_Path Relax –
BGP multipath works if an organization uses the same service provider. However, if an organization uses different service
providers, the AS_Path will not be identical and will not meet the requirements for BGP multipath. The AS_Path relax feature
allows for BGP multipath to work when the AS_Path length is the same but the AS_Paths values are different.
XR IOS
router bgp 400 router bgp 400
bgp bestpath as-path multipath-relax bgp bestpath as-path multipath-relax
maximum-paths ebgp 2 maximum-paths 2
RP/0/0/CPU0:XR4# show route bgp
B         172.16.0.0/24         [20/0]         via         10.34.1.3,         00:03:04
[20/0]         via         10.24.1.2,         00:03:04
Peer Group –
  IOS peer groups simplify BGP configuration and reduces system resources (CPU and memory) by grouping BGP peers
together into BGP update groups. All members in the BGP update group share the same outbound policy. neighbor ip-address
command replaces with neighbor peer-group-name. Members of a peer-group can have a unique inbound routing policy. Config
–
router bgp 100
neighbor AS100 peer-group
neighbor AS100 remote-as 100
neighbor AS100 update-source Loopback0
neighbor 192.168.2.2 peer-group AS100
neighbor 192.168.3.3 peer-group AS100
neighbor 192.168.4.4 peer-group AS100
!
address-family ipv4
neighbor AS100 next-hop-self
neighbor 192.168.2.2 activate
neighbor 192.168.3.3 activate
neighbor 192.168.4.4 activate
exit-address-family
 SWITCHING
Switching by Sudeb
Difference between a L3 switch & router –

1. Router support wide range of interface types.

2. Switch uses ASCI method to approach wire speed throughput so it can forward data faster than router.
3. Router support more features than switch due to its advanced level of hardware.

Control Plane and Data Plane - Routing protocols operate in a router’s control plane, whereas the actual forwarding of data is handled
by a router’s data plane.
Monitoring Switching tables –   Cam table operation –
Switch# show mac address-table dynamic [address mac-address | interface type mod/num | vlan vlan-id]
Switch# show mac address-table dynamic interface gig1/0/49
Mac Address Table
------------------------------------------------
Vlan         Mac Address         Type                 Ports
---- ----------- ---- -----
580         0000.0c07.ac01         DYNAMIC         Gi1/0/49
580        0007.0e0b.f918         DYNAMIC         Gi1/0/49
580         000f.1f78.1094         DYNAMIC         Gi1/0/49
580         0011.43ac.b083         DYNAMIC         Gi1/0/49
Clearing mac address manually -
Switch# clear mac address-table dynamic [address mac-address | interface type mod/num | vlan vlan-id]
VLAN -- VLAN is a single broadcast domain. All devices connected to the VLAN receive broadcasts sent by any other VLAN members.
However, devices connected to a different VLAN will not receive those same broadcasts.
VLAN Membership --- When a VLAN is provided at an access-layer switch, an end user must have some means of gaining membership
to it. Two membership methods exist on Cisco Catalyst switches: -
■ Static VLAN configuration                  ■ Dynamic VLAN assignment
Static VLANs offer port-based membership, in which switch ports are assigned to specific VLANs. End-user devices become
members in a VLAN based on the physical switch port to which they are connected. VLANs 1 and 1002 through 1005 automatically
are created & can’t be deleted. Catalyst IOS switches also can support extended-range VLANs, in which the VLAN number can be 1 to
4094. The extended range is enabled only when the switch is configured for VTP transparent mode. Configured Vlans are stored in a
file named vlan.dat in switch flash memory. So total removing of the vlans can be achieved by deleting the vlan.dat file.  
Switch(config)# vlan vlan-num switch# show vlan id 20
Switch(config-vlan)# name vlan-name VLAN       Name                             Status    Ports
Switch(config)# interface fa0/11 ---- -------------------------------- --------- ------------------------------
Switch(config-if)# switchport mode access 20             marketing                      active    Fa0/11
Switch(config-if)# switchport access vlan 20
Dynamic VLANs provide membership based on the MAC address of an end-user device. When a device is connected to a switch port,
the switch must, in effect, query a database to establish VLAN membership. A network administrator also must assign the user’s
MAC address to a VLAN in the database of a VLAN Membership Policy Server (VMPS).With Cisco switches, dynamic VLANs are
created and managed using network-management tools such as CiscoWorks. Dynamic VLANs allow a great deal of flexibility and
mobility for end users but require more administrative overhead.
Vlan Trunk -  At the access layer, end-user devices connect to switch ports that provide simple connectivity to a single VLAN each. The
attached devices are unaware of any VLAN structure and simply attach to what appears to be a normal physical network segment.
Remember, sending information from an access link on one VLAN to another VLAN is not possible without the intervention of an
additional device—either a Layer 3 router (with router on a stick) or a layer 3 switch (ip routing enable).
A trunk link, however, can transport more than one VLAN through a single switch port. Trunk links are most beneficial when switches
are connected to other switches or switches are connected to routers. A trunk link is not assigned to a specific VLAN. Instead, one,
many, or all active VLANs can be transported between switches using a single physical trunk link. A trunk port is a port that sends and
receives tagged frames on all VLANs, except the native VLAN, if one is configured.

   

|
Encapsulation - When a network device sends a message, the message will take the form of a packet. Each OSI model layer adds a
header to the packet. The packet is then covered with some information directing it onward to a destination. Similarly the message in
the packet is encapsulated with some information such as the address of next node, protocol information, the type of data and the
source and destination addresses. The encapsulation type of the receiving device has to be same in order to decapsulate the packet.
As with Cisco ISL, IEEE 802.1Q protocol can be used for VLAN identification with Ethernet trunks.
802.1Q protocol - The IEEE 802.1Q protocol also can carry VLAN associations over trunk links. However, this frame-identification
method is standardized, allowing VLAN trunks to exist and operate between equipment from multiple vendors. 802.1Q also introduces
the concept of a native VLAN on a trunk. Frames belonging to this VLAN are not encapsulated with any tagging information. If an end
station is connected to an 802.1Q trunk link, the end station can receive and understand only the native
VLAN frames. Whenever a router connects to a switch trunk port the router interface must have 802.1q trunk enable. Otherwise they
won’t ping. In case the router connects with a switch access port then ping is possible.
Router(config)# interface f0/0.10  Router(config-if)#encapsulation dot1q 10.  Router(config-if)#ip add 1.1.1.1 255.0.0.0
NATIVE VLAN - if an untagged frame (CDP, STP) is received on a trunk port, the frame is associated with the native VLAN configured
on that port. Vlan 1 is the native vlan in cisco switches. The native vlan must match on both side of the trunk link.

In the switchport mode command, you can set the trunking mode to any of the following:  (DTP)
■ Trunk—This setting places the port in permanent trunking mode. DTP is still operational, so if the far-end switch port is configured
to trunk, dynamic desirable, or dynamic auto mode, trunking will be negotiated successfully.
■ Dynamic desirable (the default)—The port actively attempts to convert the link into trunking mode. In other words, it “asks” the
far-end switch to bring up a trunk. If the far-end switch port is configured to trunk, dynamic desirable, or dynamic auto
mode, trunking is negotiated successfully.
■ Dynamic auto—The port can be converted into a trunk link, but only if the far-end switch actively requests it. Therefore, if the far-end
switch port is configured to trunk or dynamic desirable mode, trunking is negotiated. Because of the passive negotiation
behavior, the link never becomes a trunk if both ends of the link are left to the dynamic auto default.

 
**Ports Fa0/1 & 0/2 is not showing here due to those are associated with trunk port & will show with the - show interface trunk.
Although native vlan is mentioned in trunk port but we have to add the native vlan on the allowed vlan list.
VLAN TRUNKING PROTOCOL (VTP) – Managing vlans with large number of switches are tough so cisco develop VTP. VTP manages
the addition, deletion, and renaming of VLANs across the network from a central point of control. Any switch participating in a VTP
exchange is aware of and can use any VLAN that VTP manages. Switches in a VTP domain advertise several attributes to their
domain neighbors. Each advertisement contains information about the VTP management domain, VTP revision number, known
VLANs, and specific VLAN parameters. When a VLAN is added to a switch in a management domain, other switches are notified of
the new VLAN through VTP advertisements.
VTP Modes - To participate in a VTP management domain, each switch must be configured to operate in one of several modes. The
VTP mode determines how the switch processes and advertises VTP information. You can use the following modes: -
■ Server mode—VTP servers have full control over VLAN creation and modification for their domains. All VTP information is
advertised to other switches in the domain, while all received VTP information is synchronized with the other switches. By default,
a switch is in VTP server mode.
■ Client mode—VTP clients do not allow the administrator to create, change, or delete any VLANs. Instead, they listen to VTP
advertisements from other switches and modify their VLAN configurations accordingly
■ Transparent mode—VTP transparent switches do not participate in VTP. While in transparent mode, a switch does not advertise its
own VLAN configuration, and a switch does not synchronize its VLAN database with received advertisements. In VTP version 1, a
transparent mode switch does not even relay VTP information it receives to other switches unless its VTP domain names and VTP
version numbers match those of the other switches. In VTP version 2, transparent switches do forward received VTP advertisements
out of their trunk ports, acting as VTP relays. This occurs regardless of the VTP domain name setting.
Configuration revision number - VTP switches use an index called the VTP configuration revision number to keep track of the most
recent information. Every switch in a VTP domain stores the configuration revision number that it last heard from a VTP
advertisement. The VTP advertisement process always starts with configuration revision number 0 (zero).  Each time a configuration
change occurs on the VTP server the configuration revision number increase by one & propagated to the VTP domain to all client
switches. Because of this, it is very important to always force any newly added network switches to have revision number 0 before
being attached to the network. Otherwise, a switch might have stored a revision number that is greater than the value currently in use
in the domain. Thus newly added switch’s vlans are propagated to the VTP domain & replaced with the current vlans in all switches.
Methods for changing the configuration to 0 – 1. Change the switch’s VTP mode to transparent and then change the mode back to
server. 2. Change the switch’s VTP domain to a bogus name (a nonexistent VTP domain), and then change the VTP domain back to
the original name.          ****  The VTP revision number is stored in NVRAM and is not altered by a power cycle of the switch.
Default VTP status before configuration VTP configuration
Switch#sh vtp status Switch(config)# vtp domain domain-name
VTP Version                                              : 2 Switch(config)# vtp mode {server | client | transparent}
Configuration Revision                           : 0 Switch(config)# vtp password password
Maximum VLANs supported locally    : 1005 Switch(config)# vtp version {1 | 2}
Number of existing VLANs                    : 5 Switch(config)# vtp pruning
VTP Operating Mode                               : Server
VTP Domain Name                                  :
VTP Pruning Mode                                  : Disabled
VTP V2 Mode                                            : Disabled     (default
ver 1)
VTP Traps Generation                            : Disabled
VTP pruning - By default, a trunk link transports traffic from all VLANs, unless specific VLANs are removed from the trunk. This
scenario causes the trunk links between switches to carry traffic from all VLANs, not just from the specific VLANs created.
          Broadcast traffic in a switched network without pruning                      Broadcast traffic in a switched network with pruning__
___

 
VTP pruning makes more efficient use of trunk bandwidth by reducing unnecessary flooded traffic. Broadcast and unknown unicast
frames on a VLAN are forwarded over a trunk link only if the switch on the receiving end of the trunk has ports in that VLAN.
VTP Pruning configuration - Switch(config)# vtp pruning                  
Switch(config)# interface type mod/num
Switch(config-if)# switchport trunk pruning vlan {{{add | except | remove}vlan-list} | none}
Spanning Tree protocol -

The process of forwarding a single frame around and around between two switches is known as a bridging loop. Neither switch is
aware of the other, so each happily forwards the same frame back and forth between its segments. Also note that because two
switches are involved in the loop, the original frame has been duplicated and now it is sent around in two counter-rotating loops.
Nothing will stop the looping as there is no TTL value mentioned as we found in routing. Even a simple unicast frame has caused a
bridging loop to form, and each switch’s bridge table is repeatedly corrupted with incorrect data. If a pc sends a broadcast then the
packet will receive by every device again & again which is called broadcast storm. To stop the loop we have to either shutdown one
switch port or unplug the redundant cable. Only spanning tree protocol can help us to prevent the loop without changing any config.
Basically, the protocol enables switches to become aware of each other so they can negotiate a loop-free path through the network.
Loops are discovered before they are made available for use, and redundant links are effectively shut down to prevent the loops from
forming. When redundant paths are found, the spanning-tree algorithm picks one path by which to forward frames and disables, or
blocks, forwarding on the other redundant paths. As its name implies, STP computes a tree structure that spans all switches in
a subnet or network. However, if a forwarding port fails or becomes disconnected, the spanning-tree algorithm recomputed the
spanning-tree topology so that the appropriate blocked links can be reactivated.
Spanning-Tree Communication:  Bridge Protocol Data Units (BPDU) –
STP operates as switches communicate with one another. Data messages are exchanged in the form of bridge protocol data units
(BPDU). A switch sends a BPDU frame out a port, using the unique MAC address of the port itself as a source address. The switch is
unaware of the other switches around it, so BPDU frames are sent with a destination address of the well-known STP multicast
address 01-80-c2-00-00-00.  BPDU contains information about – Root Bridge ID, Root path cost, Sender bridge id, port id etc.
Two types of BPDU exist:
■ Configuration BPDU, used for spanning-tree computation
■ Topology Change Notification (TCN) BPDU, used to announce changes in the network topology.
ROOT BRIDGE - For all switches in a network to agree on a loop-free topology, a common frame of reference must exist to use as a
guide. This reference point is called the root bridge. Each switch has a unique bridge ID that identifies it to other switches. The bridge
ID is an 8-byte value consisting of the following fields:
■ Bridge Priority (2 bytes)—The priority or weight of a switch in relation to all other switches. The Priority field can have a value of 0 to
65,535 and defaults to 32,768 (or 0x8000) on every Catalyst switch.
■ MAC Address (6 bytes)—The MAC address used by a switch can come from the Supervisor module, the backplane, or a pool of
1,024 addresses that are assigned to every supervisor or backplane, depending on the switch model. In any event, this address is
hard-coded and unique, and the user cannot change it.
The root bridge election process occurs the following way – 1. Lowest bridge id configured for native vlan in stp & for a particular vlan
in MSTP.  2. Lowest mac-address if all the switch have same bridge id defaults to 32768.

Root port – After root bridge election completes, the other switches try to find the way or path to reach the root bridge. It selects the
lowest path cost (highest bandwidth) to reach the root bridge. From the port that a non root bridge connects itself to the root bridge is
called root port of that switch. Remember Root Bridge doesn’t have any root port.
STP path cost -
Link bandwidth 4 Mbps 10 Mbps 100 Mbps 1 Gbps 10 Gbps
STP cost 250 100 19 4 2
Designated port - STP makes a final computation to identify one designated port on each network segment. It’s a forwarding port for
every LAN segment. Sometimes two or more links might have identical root path costs. This results in a tie condition, All tie breaking
STP decisions are based on the following sequence of four conditions:
1. Lowest root bridge ID
2. Lowest root path cost to root bridge
3. Lowest sender bridge ID
4. Lowest sender port ID
Blocked port - Every switch port that is neither a root nor a designated port will be put into the Blocking state.
Alternate port—Ports that are candidate root ports (they are also close to the root bridge) but are in the Blocking state. These ports are
identified for quick use by the STP UplinkFast feature.
STP states –       Disabled,Blocking, Listening, Learning, Forwarding.
■Disabled—Ports that are administratively shut down by the network administrator or by the system because of a fault condition.
■ Blocking—After a port initializes, it begins in the Blocking state so that no bridging loops can form. In the Blocking state, a port
cannot receive or transmit data and cannot add MAC addresses to its address table. Instead, a port is allowed to receive only BPDUs
so that the switch can hear from other neighboring switches
■ Listening—A port is moved from Blocking to Listening if the switch thinks that the port can be selected as a root port or designated
port. The port is on its way to begin forwarding traffic. The port still cannot send or receive data frames. However, the port is allowed
to receive and send BPDUs so that it can actively participate in the Spanning Tree topology process.
■ Learning—After a period of time called the Forward Delay in the Listening state, the port is allowed to move into the Learning state.
The port still sends and receives BPDUs as before. The switch now can learn new MAC addresses to add to its address table.
■ Forwarding—After another Forward Delay period of time in the Learning state, the port is allowed to move into the Forwarding state.
The port now can send and receive data frames, collect MAC addresses in its address table, and send and receive BPDUs.
The port is now a fully functioning switch port within the spanning-tree topology.
STP port state summary & port activity –
STP State The Port Can........ The Port Cannot......... Duration
Blocking Receive BPDUs Send or receive data or learn Indefinite if loop has been
MAC detected
addresses
Listening Send and receive BPDUs Send or receive data or learn Forward Delay timer (15 seconds)
MAC addresses
Learning Send and receive BPDUs and learn Send or receive data mac table Forward Delay timer (15 seconds)
MAC addresses populated.
Forwardin Send and receive BPDUs, learn MAC Indefinite as long as port
g addresses, and send and receive data is up and loop is not detected
Spanning tree types -                        1. Common spanning tree  2. Per-vlan spanning tree.  3. Per-Vlan spanning tree+
Common spanning-tree (CST) – IEEE 802.1Q standard multi vendor spanning tree protocol. All CST BPDUs are transmitted over trunk
links using the native VLAN. Having a single STP for many VLANs simplifies switch configuration and reduces switch
CPU load during STP calculations. However, having only one STP instance can cause limitations, too.
 Per-Vlan spanning tree (PVST) – Cisco proprietary  Per-VLAN Spanning Tree (PVST) operates a separate instance of STP for each
individual VLAN. This allows the STP on each VLAN to be configured independently, offering better performance and tuning for
specific conditions. Multiple spanning trees also make load balancing possible over redundant links when the links are assigned to
different VLANs. As Cisco’s proprietary PVST requires ISL trunking encapsulation. So using of CST & PVST in a network can create
problem because BPDus are not exchange due to different trunking method. To overcome this problem cisco release –
Per-Vlan spanning tree plus (PVST+) - Per-VLAN Spanning Tree Plus (PVST+) effectively supports three groups of STP operating in the
same campus network:  Catalyst switches running PVST,  Catalyst switches running PVST+, Switches running CST over 802.1Q.
*** Switch# show spanning-tree summary
ROOT BRIDGE CONFIGURATION –
■ Configure one switch as a root bridge in a determined fashion.
■ Configure another switch as a secondary root bridge, in case of a primary root bridge failure.
2 ways to configure a root bridge – 1. Switch(config)# spanning-tree vlan vlan-list priority bridge-priority
   2. Switch(config)# spanning-tree vlan vlan-id root {primary | secondary}
Bridge priority is default to 32768 & it can be configured from 0 to 65535, multiples of 4096. Root primary makes the bridge priority to
24576. Root secondary makes the bridge priority to 28672. An extended system-id value added with the priority which is the vlan id
value. E.g.- If the bridge id configure as 0 & spanning tree instance is running for vlan 10 then bridge priority will show as 10.
ML-2#sh spanning-tree vlan 10
VLAN0010
  Spanning tree enabled protocol ieee
  Root ID                 Priority                      24586
                                 Address                      00E0.B02A.72DB
                                 Cost                             0
                                 Port                             27(Port-channel 1)
                                 Hello Time                 2 sec       Max  Age  20  sec           Forward  Delay  15  sec
  Bridge ID              Priority                      28682  (priority 28672 sys-id-ext 10)
                                  Address                     0050.0F48.9810
                                  Hello Time                2 sec   Max Age   20 sec                 Forward Delay 15 sec
                                  Aging Time  20
Interface            Role     Sts      Cost      Prio.    Nbr Type
----------------   ----        ---     --------- -------- --------------------------------
Fa0/1                  Desg    FWD   19        128.1     P2p
Fa0/2                 Desg    FWD    19        128.2    P2p
Po1                      Root    FWD     0        128.27   Shr
Tuning spanning tree –
Tuning root path cost - As a switch receives a BPDU, the port cost of the receiving port is added to the root path cost in the BPDU. The
port or port path cost is inversely proportional to the port’s bandwidth (100mbps-19, 10mbps-100, 1gbps-4 etc.). If desired, a port’s
cost can be modified from the default value.Switch (config-if)# spanning-tree [vlan vlan-id] cost cost.
Tuning port id - The port ID value that a switch uses is actually a 16-bit quantity: 8 bits for the port priority and 8 bits for the port
number. The port priority is a value from 0 to 255 and defaults to 128 for all ports. The port number can range from 0 to 255 and
represents the port’s actual physical mapping. Above the port priority is 128. F0/1=1,
Switch(config-if)# spanning-tree [vlan vlan-list] port-priority port-priority
Bridge protocol data unit (BPDU) – Superior BPDU - A superior BPDU is one that has a lower Bridge ID. Receiving a superior BPDU
typically means that a switch received a BPDU with a lower Bridge ID than the Bridge ID of the currently elected root bridge.
Inferior BPDU - An inferior BPDU would have a higher Bridge ID. The BPDU is considered inferior, if it carries information about the root
bridge that is worse than the one currently stored for the port. Inferior BPDUs may appear when a neighboring switch suddenly loses
its uplink and claims itself the new root of the topology. By default, every switch should ignore inferior BPDUs, until the currently
stored BPDU expires Max age time. This feature intends to stabilize STP topology in situations where an uplink on some switch flaps
(goes down and up frequently for any malfunction), causing the switch to start sending inferior information. If a switch receives an
inferior BPDU, nothing changes. Receiving a superior BPDU will kick off a reconvergence of the STP topology
Link convergence in STP – Portfast, Uplinkfast, backbonefast
Portfast – With normal STP operation an workstation after booting has to wait 30 seconds (15 listening,15 learning) for transmit or
receive data. Portfast help the workstation to be online bypassing the listening & learning state of switch port.
Switch(config-if)#  spanning-tree portfast.   Alternate command with same result - Switch(config-if)# switchport host.
UplinkFast - An access-layer switch that has redundant uplink connections to two distribution-layer switches. Normally, one uplink
would be in the Forwarding state and the other would be in the Blocking state. If the primary uplink went down, up to 50 seconds could
elapse before the redundant uplink could be used. The UplinkFast feature on Catalyst switches enables leaf-node switches or
switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential
root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use.
Switch(config)# spanning-tree uplinkfast [max-update-rate pkts-per-second]
BackboneFast -  In the network backbone, or core layer, a different method is used to shorten STP convergence. BackboneFast works
by having a switch actively determine whether alternative paths exist to the root bridge, in case the switch detects an indirect link
failure. Indirect link failures occur when a link that is not directly connected to a switch fails. A switch detects an indirect link failure
when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port. (Inferior BPDUs are sent from a
designated bridge that has lost its connection to the root bridge, making it announce itself as the new root.)
Switch(config)# spanning-tree backbonefast. When used, BackboneFast should be enabled on all switches in the network because
BackboneFast requires the use of the RLQ Request and Reply mechanism to inform switches of Root Path stability. The RLQ protocol
is active only when BackboneFast is enabled on a switch. By default, BackboneFast is disabled.
Campus network setup –

1. Select the desired switch that needs to play the role of root bridge.
2. Create vlans on that switch with a native vlan as its better not to use the default vlan 1 as native vlan.
3. Create virtual interface on the root bridge for each corresponding vlan & configure ip address on the VI. This ip address will be
use as the client gateway address for their corresponding vlan.
4. Configure the desired native vlan on each switch manually with an ip address. VTP will communicate with each switch
through this vlan.  
5. Configure VTP domain on the root switch & configure other switchs as client.
6. Configure spanning tree mode pvst & configure the root bridge with – spanning tree vlan x,y,z root primary for configured
vlans & configure another switch as spanning tree root secondary for backup.
7. Configure trunk port with - switchport trunk native vlan to the newly configured native vlan. Allow desired vlans including
native vlan on the trunk port.
8. Configure access port for pcs with switchport mode access or switchport host command.  

Protecting spanning tree

Root Guard – Suppose that a new switch introduce into the existing STP network with a lower bridge priority than the current root
bridge. The switch can able to reconverge the STP process on all switches. Root guard prevents this to occur. If another switch
advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the
new switch to become the root. As long as the superior BPDUs are being received on the port, the port will be kept in the root
inconsistent STP state. When the superior BPDUs no longer are received, the port is cycled through the normal STP states to return to
normal use. Switch(config-if)# spanning-tree guard root
           Switch# show spanning-tree inconsistentports
BPDU Guard – During portfast command enable on a switchport & if mistakenly a switch connects to that port & the switch produce
inferior bpdu a bridging loop can occur. With BPDU guard If any BPDU (whether superior to the current root or not) is received on a
port where BPDU Guard is enabled, that port immediately is put into the errdisable state.
 Switch(config)# spanning-tree portfast bpduguard default
Protecting Against Sudden Loss of BPDUs   ---
In a loop free topology, BPDUs must be sent by the root bridge and must be relayed by every other switch in the STP domain. The STP
topology’s integrity then depends on a continuous and regular flow of BPDUs from the root. What happens if a switch doesn’t receive
BPDUs in a timely manner or when it doesn’t receive any? The switch can view that condition as acceptable—perhaps an upstream
switch or an upstream link is dead. In that case, the topology must have changed, so blocked ports eventually can be unblocked again.
However, if the absence of BPDUs is actually a mistake and BPDUs are not being received even though there is no topology change,
bridging loops easily can form. Cisco has added two STP features that help detect or prevent the unexpected loss of BPDUs:  -- ■
Loop Guard       ■ Unidirectional Link Detection (UDLD)
Loop Guard - When enabled, Loop Guard keeps track of the BPDU activity on nondesignated ports. While BPDUs are received,the port
is allowed to behave normally. When BPDUs go missing, Loop Guard moves the port into the loop-inconsistent state. The port is
effectively blocking at this point to prevent a loop from forming and to keep it in the nondesignated role. When BPDUs are received on
the port again, Loop Guard allows the port to move through the normal STP states and become active. In this fashion, Loop Guard
automatically governs ports without the need for manual intervention.    Switch(config)# spanning-tree loopguard default
Switch(config-if)# spanning-tree guard loop
Unidirectional Link detection (UDLD)  - Switches are connected by bidirectional links, where traffic can flow in two directions. What
would happen if just one side of the link (receive or transmit) had an odd failure, such as malfunctioning transmit circuitry in a gigabit
interface converter (GBIC) or small form factor pluggable (SFP) modules? In some cases, the two switches still might see a functional
bidirectional link, although traffic actually would be delivered in only one direction. This is known as a unidirectional link. A
unidirectional link poses a potential danger to STP topologies because BPDUs will not be received on one end of the link. A switch
interprets the absence of BPDUs to mean that the port can be moved safely through the STP states so that traffic can be forwarded.
However, if that is done on a unidirectional link, a bridging loop forms and the switch never realizes the mistake. To prevent this
situation, you can use the Cisco-proprietary Unidirectional Link Detection (UDLD) STP feature. When enabled, UDLD interactively
monitors a port to see whether the link is truly bidirectional. A switch sends special Layer 2 UDLD frames identifying its switch port at
regular intervals. UDLD expects the far-end switch to echo those frames back across the same link, with the far-end switch port’s
identification added. UDLD has two modes of operation:
■ Normal mode—When a unidirectional link condition is detected, the port is allowed to continue its operation. UDLD merely marks the
port as having an undetermined state and generates a syslog message.
■ Aggressive mode—When a unidirectional link condition is detected, the switch takes action to reestablish the link. UDLD messages
are sent out once a second for 8 seconds. If none of those messages is echoed back, the port is placed in the Errdisable
state so that it cannot be used.
Switch(config)# udld {enable | aggressive | message time seconds}              
Switch(config-if)# udld {enable | aggressive | disable}
BPDU filter – In portfast mode when you need to prevent BPDUs from being sent or processed on one or more switch ports, you can
use BPDU filtering to effectively disable STP on those ports.  Switch(config)# spanning-tree portfast bpdufilter default
Switch(config-if)# spanning-tree bpdufilter {enable | disable}
Reenable ports that UDLD aggressive mode has errdisabled.--- Switch# udld reset
Rapid Spanning Tree Protocol 
Ieee802.1D stp takes 30 seconds to move a port from blocking to forwarding state while a topology changes. The Ieee802.1W Rapid
spanning tree defines how switches must interact with each other to keep the network topology loop free in a very efficient manner.
RSTP can be applied as a single instance or multiple instances. RSTP also is used as part of the IEEE 802.1s Multiple Spanning Tree
(MST) operation.
The root bridge in a network using RSTP is elected just as with 802.1D—by the lowest Bridge ID. After all switches agree on the
identity of the root, the following port roles are determined:
■ Root port—The one switch port on each switch that has the best root path cost to the root.
■ Designated port—The switch port on a network segment that has the best root path cost to the root.
■ Alternate port—A port that has an alternative path to the root, different from the path the root port takes. This path is less desirable
than that of the root port. (An example of this is an access-layer switch with two uplink ports; one becomes the root port, and the
other is an alternate port.)
■ Backup port—A port that provides a redundant (but less desirable) connection to a segment where another switch port already
connects. If that common segment is lost, the switch might or might not have a path back to the root.
RSTP port roles –   no listening mode.
■ Discarding—Incoming frames simply are dropped; no MAC addresses are learned. (This state combines the 802.1D Disabled,
Blocking, and Listening states because all three did not effectively forward anything. The Listening state is not needed because RSTP
quickly can negotiate a state change without listening for BPDUs first.)
■ Learning—Incoming frames are dropped, but MAC addresses are learned.
■ Forwarding—Incoming frames are forwarded according to MAC addresses that have been (and are being) learned.
Rapid per-Vlan spanning tree protocol configuration –   Switch(config)# spanning-tree mode rapid-pvst  

Multiple Spanning Tree Protocol

The default spanning tree mode on Cisco Catalyst switches is PVST+ or, on newer models, Rapid PVST+. These protocols result in a
direct one-to-one mapping of spanning tree instances to VLANs. Multiple Spanning Tree (MST) was created to allow for multiple
spanning tree topologies while preserving scalability. MST enables an administrator to map an arbitrary number of VLANs to a single
MST instance, resulting in the minimum number of instances needed to satisfy a design. If, for example, you have six VLANs but only
two unique layer two topologies, you need only two MST instances. MST maps one or more VLANs to a single STP instance.
MST configuration -  By default all vlans are assigned to instance 0.  So we need to define the second instance to map desire Vlans.

1. Enable MST with -- spanning-tree mst configuration in config mode.

2. Add vlans to the first instance with – instance 1 vlan vlan numbers.
3. Apply show pending command to check the added vlans are in instance 1 & rest of them are in instance 0
4. Configure a region name with – region region name
5. Revision number – unlike vtp the revision number doesn’t increment after any changes so it has to be manually added after
every configuration change occur. Also the configuration revision number must match on all switches in the region.

Configure – revision revision number. The number must be increase manually in all switches after every config change.
S1# vlan10, vlan 20, vlan 30, vlan 40
interface Vlan10 ip address 192.168.10.1 255.255.255.0
interface Vlan20 ip address 192.168.20.1 255.255.255.0
interface Vlan30 ip address 192.168.30.1 255.255.255.0
interface Vlan40 ip address 192.168.40.1 255.255.255.0
S2# vlan10, vlan 20, vlan 30, vlan 40
interface Vlan10 ip address 192.168.10.2 255.255.255.0
interface Vlan20 ip address 192.168.20.2 255.255.255.0
interface Vlan30 ip address 192.168.30.2 255.255.255.0
interface Vlan40 ip address 192.168.40.2 255.255.255.0
S3# vlan10, vlan 20, vlan 30, vlan 40
interface Vlan10 ip address 192.168.10.3 255.255.255.0
interface Vlan20 ip address 192.168.20.3 255.255.255.0
interface Vlan30 ip address 192.168.30.3 255.255.255.0
interface Vlan40 ip address 192.168.40.3 255.255.255.0
S1(config-mst)#   name  Region1
S1(config-mst)#   revision   1
S1(config-mst)#   exit
#### These configurations must be applied to all three switches.
Finally, we change the spanning tree mode from the default of PVST+ to MST on all three switches:
S1(config)#   spanning-tree  mode  mst
S2(config)#   spanning-tree  mode  mst
S3(config)#   spanning-tree  mode  mst
configure S1 to become the root for instance 0 (VLANs 10 and 30), and S2 will be the root for instance 1 (VLANs 20 and 40):
 S1(config)#   spanning-tree  mst  0  priority  0
S1(config)#    spanning-tree  mst  1   priority 4096
S2(config)#   spanning-tree  mst  0  priority 4096
S2(config)#   spanning-tree  mst  1  priority 0

 
Aggregating switch link – EtherChannel
Spanning tree blocks redundant paths to make the layer 2 topology loop free.  So a high speed link stay idle for years with one end
blocked by stp & until the primary link goes down the alternate link stays inactive. To utilize that link & increase bandwidth between
trunk ports cisco develop etherchannel technology. Two to eight links of either Fast Ethernet or Gigabit Ethernet or 10-Gigabit Ethernet
are bundled as one logical link. This bundle provides a full-duplex bandwidth of up to 1600 Mbps (eight links of Fast Ethernet), 16
Gbps (eight links of Gigabit Ethernet), or 160 Gbps (eight links of 10-Gigabit Ethernet).  (Throughput bandwidth)
Understanding Port-Channel Interfaces -  Each EtherChannel has a port-channel interface, numbered from 1 to 64. Configuration
applied to the port-channel interface applies to all physical interfaces those associate with the port-channel interface.
Etherchannel can be either layer 2 or layer 3. Two types of negotiation protocols use in etherchannel configuration- PAGP & LACP
Etherchannel requirements - If improperly configured, some EtherChannel interfaces are disabled automatically to avoid network
loops and other problems. Follow these guidelines to avoid configuration problems:
• All Ethernet interfaces on all modules, including those on a standby supervisor engine, support EtherChannel (maximum of eight
interfaces) with no requirement that interfaces be physically contiguous or on the same module.
• Configure all interfaces in an EtherChannel to operate at the same speed and duplex mode.
• Enable all interfaces in an EtherChannel. If you shut down an interface in an EtherChannel, it is treated as a link failure and its    traffic
is transferred to one of the remaining interfaces in the EtherChannel.
• EtherChannel negotiation protocol must match on both sides of the link. Either PAGP or LACP
• For Layer 3 EtherChannels: Assign Layer 3 addresses to the port-channel logical interface, not to the physical interfaces in the
channel.
• For Layer 2 EtherChannels: Assign all interfaces in the EtherChannel to the same VLAN, or configure them as trunks. If you configure
an EtherChannel from trunk interfaces, verify that the trunking mode is the same on all the trunks
• An EtherChannel supports the same allowed range of VLANs on all the interfaces in a trunking Layer 2 EtherChannel. If the allowed
range of VLANs is not the same, the interfaces do not form an EtherChannel even when set to the auto or desirable mode.
• Interfaces with different Spanning Tree Protocol (STP) port path costs can form an EtherChannel as long they are otherwise
compatibly configured. Setting different STP port path costs does not, by itself, make interfaces incompatible for the formation of an
EtherChannel.
EtherChannel Negotiation Protocols -- EtherChannels can be negotiated between two switches to provide some dynamic link
configuration. Two protocols are available to negotiate bundled links in Catalyst switches. The Port Aggregation Protocol (PAgP) is a
Cisco-proprietary solution, and the Link Aggregation Control Protocol (LACP) is standards based. Table 6-4 summarizes the
negotiation protocols and their operation.
Negotiation Mode Negotiation packets sent Characteristics
????
PAGP LACP
ON ON NO All ports channeling
AUTO PASSIVE YES Waits to channel until asked
DESIRABLE ACTIVE YES Actively ask to form a
channel
Configuring layer 2 EtherChannel - To configure Layer 2 EtherChannels, configure the Ethernet interfaces with the channel-group
command, which creates the port-channel logical interface. Which is called interface port-channel
Switch(config)# Interface range gig0/1 – 4
Switch(config-if)# channel-protocol  pagp | lacp
Switch(config-if)# channel-group number mode on | auto | desirable | passive | active
Switch(config)#  interface port-channel channel number
Switch(config-if)# ** add the trunk base configuration command that applied on the associated physical ports of etherchannel.
                          e.g. – switchport mode trunk, switchport trunk native vlan etc.
Configuring layer 3 EtherChannel - To move an IP address from a physical interface to an EtherChannel, you must delete the
IP address from the physical interface before configuring it on the port-channel interface.
Same configuration as layer2 etherchannel but we need to add the associated physical ports with no switchport command
Switch(config)# interface port-channel 1
Switch(config-if)# no switchport
Switch (config-if)# ip address 172.32.52.10 255.255.255.0
Verification – verify etherchannel state with show etherchannel-summary –
 Port Security
Catalyst switches offer the port security feature to control port access based on MAC addresses. To configure port security on an
access-layer switch port, begin by enabling it on a per-interface basis with the following interface-configuration command:
Switch(config-if)# switchport port-security          (default port-security disable)
Next assign how many mac-address you want to grant access. By default one mac-address is allowed but we can assign 1 – 1024
mac-address per port. These mac-address can be statically assigned or dynamically learned.
Switch(config-if)# switchport port-security maximum number of mac-addres (e.g.-2)
To statically assign mac-address on a port we need to mention the physical mac-address of the device. The mac-address format
should be in dotted-triple format. following interface configuration command to define a static address:
Switch(config-if)# switchport port-security mac-address mac-addr  (e.g.- aaaa.1111.bbbb)  48 bits / 6 bytes
You can configure an interface to convert the dynamic MAC addresses to sticky secure MAC addresses and to add them to the
running configuration. The interface converts all the dynamic secure MAC addresses, including those that were dynamically learned
before sticky learning was enabled, to sticky secure MAC addresses. To enable sticky learning-
Switch(config-if)# switchport port-security mac-address sticky 
The switch learned those maximum dynamic mac-address & added to the running-config.  
Finally you must define how a switchport reacts if any violation occurred –
Switch(config-if)# switchport port-security violation {shutdown | restrict |protect }                   (default-shutdown)
A violation occurs if more than the maximum number of MAC addresses are learned or if an unknown (not statically defined) MAC
address attempts to transmit on the port. The switch port takes one of the following configured actions when a violation is detected:
■ Shutdown—This is the default behavior of the port during violation. The port immediately is put into the Errdisable state, which
effectively shuts it down. It must be reenabled manually or through errdisable recovery to be used again.
■ Restrict—The port is allowed to stay up, but all packets from violating MAC addresses are dropped. The switch keeps a running
count of the number of violating packets and can send an SNMP trap and a syslog message as an alert of the violation.
■ Protect—The port is allowed to stay up, as in the restrict mode. Although packets from violating addresses are dropped, no record
of the violation is kept. As an example of the restrict mode, a switch interface has received the following configuration commands:
If an interface is undergoing the restrict or protect condition, you might need to clear the learned MAC addresses so that a specific
host can use the switch port. You can clear a MAC address or the complete port cache with the following command:
Switch# clear port-security dynamic [address mac-addr | interface type mod/num]
In the shutdown mode, the following command indicates that the port has been shut down in the Errdisable state:
Switch# show interfaces status err-disabled
Port         Name                 Status                 Reason
Gi0/11         Test port         err-disabled         psecure-violation
In this situation the – shutdown & no-shutdown command needs to apply.
Mitigating Spoofing Attacks
Malicious users sometimes can send spoofed information to trick switches or other hosts into using a rogue machine as a gateway.
The attacker’s goal is to become the man in the middle, with a naive user sending packets to the attacker as if it were a router. The
attacker can glean information from the packets sent to it before it forwards them normally. This section describes three Cisco
Catalyst features—DHCP snooping, IP Source Guard, and dynamic ARP inspection—that prevent certain types of spoofing attack.
DHCP SNOOPING - Suppose that an attacker could bring up a rogue DHCP server on a machine in the same subnet as that same
client PC. Now when the client broadcasts its DHCP request, the rogue server could send a carefully crafted DHCP reply with its own
IP address substituted as the default gateway. When the client receives the reply, it begins using the spoofed gateway address.
Packets destined for addresses outside the local subnet then go to the attacker’s machine first. The attacker can forward the packets
to the correct destination, but in the meantime, it can examine every packet that it intercepts. In effect, this becomes a type of
man-in-the-middle attack; the attacker is wedged into the path and the client doesn’t realize it. Cisco Catalyst switches can use the
DHCP snooping feature to help mitigate this type of attack. When DHCP snooping is enabled, switch ports are categorized as trusted
or untrusted. Legitimate DHCP servers can be found on trusted ports, whereas all other hosts sit behind untrusted ports.
You can configure DHCP snooping first by enabling it globally on a switch with the following configuration command:
Switch(config)# ip dhcp snooping
Next identify the VLANs where DHCP snooping should be implemented with the following command:
Switch(config)# ip dhcp snooping vlan vlan-id [vlan-id]
The trusted DHCP server connected port should be configured with the following command:
Switch(config-if)# ip dhcp snooping trust
For untrusted ports, an unlimited rate of DHCP requests is accepted. If you want to rate-limit DHCP traffic on an untrusted port, use
the following interface configuration command:
Switch(config-if)# ip dhcp snooping limit rate rate        (The rate can be 1 to 2048 DHCP packets per second)
You can enable or disable option-82 globally with the following configuration command:
Switch(config)# ip dhcp snooping information option
Configuration example & verification -
 
IP SOURCE GUARD - Address spoofing is one type of attack that can be difficult to mitigate. Normally, a host is assigned an IP
address and is expected to use that address in all the traffic it sends out. IP addresses are effectively used where hosts are trusted to
use their own legitimate source addresses. A rogue or compromised host PC doesn’t necessarily play by those rules. It can use its
legitimate address, or it can begin to use spoofed addresses—borrowed from other hosts or used at random. Spoofed addresses are
often used to disguise the origin of denial-of-service attacks. If the source address doesn’t really exist, no return traffic will find its way
back to the originator. Routers or Layer 3 devices can perform some simple tests to detect spoofed source addresses in packets
passing through. For example, if the 10.10.0.0 network is known to exist on VLAN 10, packets entering from VLAN 20 should never
have source addresses in that subnet. However, it is difficult to detect spoofed addresses when they are used inside the VLAN or
subnet where they should already exist. Cisco Catalyst switches can use the IP source guard feature to detect and suppress address
spoofing attacks—even if they occur within the same subnet. A Layer 2 switch, and a Layer 2 port in turn, normally learns and stores
MAC addresses. The switch must have a way to look up MAC addresses and find out what IP address are associated with them. IP
Source Guard does this by making use of the DHCP snooping database and static IP source binding entries. If DHCP snooping is
configured and enabled, the switch learns the MAC and IP addresses of hosts that use DHCP. Packets arriving on a switch port can be
tested for one of the following conditions:--
■ The source IP address must be identical to the IP address learned by DHCP snooping or a static entry. A dynamic port ACL is used
to filter traffic. The switch automatically creates this ACL, adds the learned source IP address to the ACL, and applies the ACL to the
interface where the address is learned.
■ The source MAC address must be identical to the MAC address learned on the switch port and by DHCP snooping. Port security is
used to filter traffic. If the address is something other than the one learned or statically configured, the switch drops the packet. To
configure IP Source Guard, first configure and enable DHCP snooping, as presented in the previous section. If you want IP Source
Guard to detect spoofed MAC addresses, you also need to configure and enable port security. For the hosts that do not use DHCP,
you can configure a static IP source binding with the following configuration command:
Switch(config)# ip source binding mac-address vlan vlan-id ip-address interface type mod/num
Here, the host’s MAC address is bound to a specific VLAN and IP address, and is expected to be found on a specific switch interface.
Next, enable IP source guard on one or more switch interfaces with the following configuration commands:
Switch(config-if)# ip verify source [port-security]
The ip verify source command inspects the source IP address only. You can add the port security keyword to inspect the source MAC
address, too. To verify the IP source guard status, you can use the following EXEC command:
Switch# show ip verify source [interface type mod/num]
Dynamic ARP inspection -  Hosts normally use the Address Resolution Protocol (ARP) to resolve an unknown MACaddress when the
IP address is known. If a MAC address is needed so that a packet can be forwarded at Layer 2, a host broadcasts an ARP request that
contains the IP address of the target in question. If any other host is using that IP address, it responds with an ARP reply containing its
MAC address. The ARP process works well among trusted and well-behaved users. However, suppose that an attacker could send its
own crafted ARP reply when it hears an ARP request being broadcast. The reply could contain its own MAC address, causing the
original requester to think that it is bound to the IP address in question. The requester would add the bogus ARP entry into its own
ARP cache, only to begin forwarding packets to the spoofed MAC address. In effect, this scheme places the attacker’s machine right
in the middle of an otherwise legitimate path. Packets will be sent to the attacker instead of another host or the default
gateway. The attacker can intercept packets and (perhaps) forward them on only after examining the packets’ contents. This attack is
known as ARP poisoning or ARP spoofing, and it is considered to be a type of man-in-the-middle attack. Cisco Catalyst switches can
use the dynamic ARP inspection (DAI) feature to help mitigate this type of attack. DAI works much like DHCP snooping. All switch
ports are classified as trusted or untrusted. The switch intercepts and inspects all ARP packets that arrive on an untrusted port; no
inspection is done on trusted ports. When an ARP reply is received on an untrusted port, the switch checks the MAC and IPaddresses
reported in the reply packet against known and trusted values. A switch can gather trusted ARP information from statically configured
entries or from dynamic entries in the DHCP snooping database. In the latter case, DHCP snooping must be enabled in addition to DAI.
If an ARP reply contains invalid information or values that conflict with entries in the trusted database, it is dropped and a log
message is generated. This action prevents invalid or spoofed ARP entries from being sent and added to other machines’ ARP
caches. You can configure DAI by first enabling it on one or more client VLANs with the following configuration command:
Switch(config)# ip arp inspection vlan vlan-range
The VLAN range can be a single VLAN ID, a range of VLAN IDs separated by a hyphen, or a list of VLAN IDs separated by commas.
By default, all switch ports associated with the VLAN range are considered to be untrusted. You should identify trusted ports as those
that connect to other switches. In other words, the local switch will not inspect ARP packets arriving on trusted ports;
Switch(config-if)# ip arp inspection trust
If you have hosts with statically configured IP address information, there will be no DHCP message exchange that can be inspected.
Instead, you can configure an ARP access list that defines static MAC-IP address bindings that are permitted. Use the following
configuration commands to define the ARP access list and one or more static entries:
Switch(config)# arp access-list acl-name
Switch(config-acl)# permit ip host sender-ip mac host sender-mac [log]
[Repeat the previous command as needed]
Now the ARP access list must be applied to DAI with the following configuration command:
Switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [static]
When ARP replies are intercepted, their contents are matched against the access list entries first. If no match is found, the DHCP
snooping bindings database is checked next. You can give the static keyword to prevent the DHCP bindings database from being
checked at all. In effect, this creates an implicit deny statement at the end of the ARP access list; if no match is found in the access
list, the ARP reply is considered invalid. Below example - DAI is enabled for all switch ports associated with VLAN 104 on an
access-layer switch. The uplink to a distribution switch is considered to be trusted. show ip arp inspection command will display DAI
status.

Securing with Vlan

Vlan access-list - VLAN Access Control Lists (VACLs) provide access control for all packets that are bridged within a VLAN or that are
routed into or out of a VLAN. Unlike regular Cisco IOS access control lists that are configured on router interfaces and applied on
routed packets only, VACLs apply to all packets. VACLs are configured as a VLAN access map in much the same way as a route-map.
Vlan access-map can be configure for matching ip, ipx &  mac-address.
Switch(config)# vlan access-map map-name [sequence-number]
Switch(config-access-map)# match ip address {acl-number | acl-name}
Switch(config-access-map)# match ipx address {acl-number | acl-name}
Switch(config-access-map)# match mac address acl-name
Switch(config-access-map)# action {drop | forward [capture] | redirect type mod/num}    -- (Redirect to another interface)

Private Vlans – Vlan access-list is good in a small network but to segregate users of same vlans in a large network can be done by
Private vlans. It gives us an option to separate couple of devices from communicating between each other in a group while everyone
can communicate with the router. Another application is a service provider might want to use a single VLAN to connect to several
customer networks. Each customer needs to be able to contact the provider’s gateway on the VLAN. While the customer sites do not
need to interact with each other. Private VLANs (PVLAN) solve this problem. A normal, or primary, VLAN can be logically associated
with secondary VLANs. Hosts associated with a secondary VLAN can communicate with ports on the primary VLAN (a router, for
example), but not with another secondary VLAN. A secondary VLAN is configured as one of the following types:
■ Isolated—Any switch ports associated with an isolated VLAN can reach the primary VLAN but not any other secondary VLAN. In
addition, hosts associated with the same isolated VLAN cannot reach each other.
■ Community—Any switch ports associated with a common community VLAN can communicate with each other member and with
the primary VLAN but not with any other secondary VLAN. This provides the basis for server farms.
VLAN Trunking Protocol (VTP) does not pass any information about the private VLAN configuration. Therefore, private VLANs are only
locally significant to a switch. Each of the private VLANs must be configured locally on each switch that interconnects them.
You must configure each physical switch port that uses a private VLAN with a VLAN association.
You also must define the port with one of the following modes:
■ Promiscuous—The switch port connects to a router, firewall, or other common gateway device. This port can communicate with
anything else connected to the primary or any secondary VLAN. In other words, the port is in promiscuous mode, in which the rules of
private VLANs are ignored.
■ Host—The switch port connects to a regular host that resides on an isolated or community VLAN. The port communicates only with
a promiscuous port or ports on the same community VLAN.
Private Vlan configuration -    In order to configure private vlan we need to make the VTP mode to transparent.
Switch(config)#vtp mode transparent
Enable private vlan –
switch(config)# feature private-vlan
Configuring a VLAN as a Private VLAN  -- assign VLAN 5 to a private VLAN as the primary VLAN
switch(config)# vlan 5
switch(config-vlan)# private-vlan primary  
Assign VLAN 100 to a private VLAN as a community VLAN
switch(config)# vlan 100
switch(config-vlan)# private-vlan community  
Assign VLAN 109 to a private VLAN as an isolated VLAN)
switch(config)# vlan 109
switch(config-vlan)# private-vlan isolated
Associating Secondary VLANs with a Primary Private VLAN
switch(config)# vlan 5
switch(config-vlan)# private-vlan association 100,109
Configuring an Interface as a Private VLAN Host Port
switch(config)# interface range f0/10 - 15
switch(config-if)# switchport mode private-vlan host
switch(config-if)# switchport private-vlan host-association 5 100
switch(config)# interface range f0/16 - 21
switch(config-if)# switchport mode private-vlan host
switch(config-if)# switchport private-vlan host-association 5 109
Configuring an Interface as a Private VLAN Promiscuous Port
switch(config)# interface f0/1
switch(config-if)# switchport mode private-vlan promiscuous
switch(config-if)# switchport private-vlan mapping 5 100, 109
Verifying Private VLAN Configuration      ---- Switch#sh vlan private-vlan

 
DHCP SERVER

DHCP configuration with relay-agent –

R1# ip host-routing                    **** Without this the relay agent won’t able to provide ip to other subnet
ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp excluded-address 172.16.0.1 172.16.0.10
!    
ip dhcp pool NET192
   network 192.168.0.0 255.255.255.0
   dns-server 192.168.0.1 192.168.0.2
   domain-name sudeb.com
   default-router 192.168.0.254
!
ip dhcp pool NET172
   network 172.16.0.0 255.255.255.0
   dns-server 192.168.0.1 192.168.0.2
   default-router 172.16.0.254
   domain-name cisco.com
!
interface FastEthernet0/0
 ip address 192.168.0.254 255.255.255.0
R2# show run
interface FastEthernet1/0
 no switchport
 ip address 192.168.0.253 255.255.255.0
!
interface FastEthernet1/1
 no switchport
 ip address 172.16.0.2 255.255.255.0
 ip helper-address 192.168.0.254
Cisco 6500 VSS configuration
The Cisco Catalyst 6500 Series Virtual Switching System (VSS) allows the clustering of two chassis together into a single, logical
entity. This technology allows for enhancements in all areas of network design, including high availability, scalability, management,
and maintenance.
The Virtual Switching System is created by converting two standalone Catalyst 6500 systems to a Virtual Switching System. The
conversion is a one-time process that requires a few simple configuration steps and a system reload. Once the individual chassis
reload, they are converted into the Virtual Switching System. All control plane functions are centrally managed by the active supervisor
engine of the active virtual switch chassis, including:
Management (Simple Network Management Protocol [SNMP], Telnet, Secure Shell [SSH] Protocol, etc.)
Layer 2 Protocols (bridge protocol data units [BPDUs], protocol data units [PDUs], Link Aggregation Control Protocol [LACP], etc.)
Layer 3 Protocols (routing protocols, etc.)
Software data path
The requirements to convert the 6500 into a Virtual Switching System are:
The VSS requires Supervisor Engine 720 with 10-Gigabit Ethernet ports. You must use either two VS-S720-10G-3C or two
VS-S720-10G-3CXL supervisor engine modules.
The VSS requires 67xx series switching modules.
The VSL EtherChannel supports only 10-Gigabit Ethernet ports.
To convert two standalone chassis into a VSS, perform the following activities:
Configure each chassis as a VSS
Convert to a VSS
Configure the dual-active detection (optional)
Configure the switch priority (optional)
1. Configure each chassis as a VSS
Define a switch virtual domain ID to identify the VSS. The ID must be the same on each 6500; in this example the ID ‘100’ is used:

  

Configure the VSL port channel and member ports

The Virtual Switch Link (VSL), like the VPC peer-link in VPC, is clearly a vital part of the VSS. It provides the signaling path used for
synchronizing the two supervisor engines’ control planes, as well as providing the data path for any user data traffic needing to pass
between the two chassis.

Choose unique port-channel IDs for each chassis to form the VSL and configure them with the corresponding switch ID:
  

2. Convert to a VSS
Convert both switches to virtual switch mode. During these phases:
The running configuration of the individual switch is converted into a three-level virtual switch interface notation. Two-level interface
configurations (such as 10 GigabitEthernet 5/4) are converted into three-level interfaces (such as 10 GigabitEthernet 1/5/4 in Switch 1
and 10 GigabitEthernet 2/5/4 in Switch 2) like in a stack.
The startup configuration is updated with the three-number notation.
A copy of the original startup configuration converted to three-number notation is written to the bootflash of the respective switch.
Both switches reload.
Wait more or less five minutes, then convert the second switch.
 
After the conversion, you will notice three things:
The name of the VSS is CiscozineA; rename it to “CiscozineVSS”.
The interface name is converted into three-level interface. The first number (one or two) identify the switch.
By default, the console port on the standby switch is locked; if you try to use it, this message will be displayed:

If needed, enable the standby console:

3. Configure the dual-active detection (optional)

The VSLs can be configured with up to eight links between the two switches across any combination of line cards or supervisor ports
to provide a high level of redundancy. If for some rare reason all VSL connections are lost between the virtual switch members leaving
each virtual switch assumes the role as the active virtual switch, and each virtual switch controls only its local ports. Duplication of
this configuration can possibly have adverse effects to the network topology and traffic.
To avoid this disruptive scenario, Cisco has implemented different mechanisms to address this dual-active scenario:
Enhancement to PAgP used in MEC with connecting Cisco switches
L3 Bidirectional Forwarding Detection (BFD) configuration on a directly connected link (besides VSL) between virtual switch members
or through an L2 link through an access layer switch
L2 Fast-Hello Dual-Active Detection configuration on a directly connected link (besides VSL) between virtual switch members
(supported with 12.2(33)SXI)
In this tutorial, “fast-hello” is implemented.
Note: If the dual-active detection is not configured, the system will suggest to implement it!
%DUAL_ACTIVE-SW1_SP-4-CONFIG: No dual-active detection methods configured - it is recommended to have at least one configured

*Sep 15 13:01:20.747: %VSDA-SW2_SPSTBY-5-LINK_UP: Interface Gi2/2/1 is now dual-active detection capable

*Sep 15 13:01:21.759: %VSDA-SW1_SP-5-LINK_UP: Interface Gi1/2/1 is now dual-active detection capable
4. Configure the switch priority (optional) -
My suggestion is to statically define the switch priority (an higher-priority value assumes the active virtual switch role):
CiscozineVSS(config)#switch virtual domain 100
CiscozineVSS(config-vs-domain)#switch 1 priority 110
CiscozineVSS(config-vs-domain)#switch 2 priority 90
Changing the priority, a log message is generated:
%VSLP-SW1_SP-5-RRP_RT_CFG_CHG: Configured priority value is different from operational value.
Change will take effect after config is saved and switch 1 is reloaded.
%VSLP-SW2_SPSTBY-5-RRP_RT_CFG_CHG: Configured priority value is different from operational value
Change will take effect after config is saved and switch 1 is reloaded.
Note: the switch priorities affect role determination if both virtual switches are initiated simultaneously. If either switch (regardless of
priority) is initiated prior to the subsequent switch, it always assumes the role of the active virtual switch.
After these steps, the VSS configuration is completed!
Multichassis EtherChannel -
The multichassis EtherChannel (MEC) is another term to identify an etherchannel that allows a connected node to terminate the
EtherChannel across the two physical Cisco Catalyst 6500 Series. In this example the “Ciscozine-L2” switch is connected to the
CiscozineVSS using a MEC.
From the point of view of the Ciscozine-L2, the CiscozineVSS is a single device (like a stack):

For these reasons, on the Ciscozine-L2 is possible define the port-channel10 with the interfaces Gi0/1 and Gi0/2.
Useful show commands
To show basic VSS informations:
CiscozineVSS#show switch virtual
Switch mode : Virtual Switch
Virtual switch domain number : 100
Local switch number : 1
Local switch operational role: Virtual Switch Active
Peer switch number : 2
Peer switch operational role : Virtual Switch Standby
CiscozineVSS#
To find informations about fast-hello detection:
CiscozineVSS#show switch virtual dual-active fast-hello
Fast-hello dual-active detection enabled: Yes
Fast-hello dual-active interfaces:
Port       Local State    Peer Port    Remote State
---------------------------------------------------
Gi1/2/1    Link up        Gi2/2/1      Link up  
CiscozineVSS#
To identify the role/priority of the two switches:

To find more informations about the VSS status:

CiscozineVSS#show switch virtual redundancy
Note: After the VSS conversation, some “show” commands have the feature to view the output of individual switch! For instance, to
see the modules of the second switch use “show module switch 2”.
Reload commands:
To reload a single unit:
redundancy reload shelf
where either Switch 1 or Switch 2 can be specified.
 To force a switchover:
redundancy force-switchover
HSRP-VRRP-GLBP

Redundancy & high availability at layer 3  by Sudeb

Multilayer switches & routers can act as IP gateways for connected hosts by providing gateway addresses at VLAN SVIs and Layer 3
physical interfaces. These switches can also participate in routing protocols, just as traditional routers do. For high availability,
multilayer switches should offer a means of preventing one switch (gateway) failure from isolating an entire VLAN or network.  
3 protocol those are capable for redundancy are -
■ Hot Standby Router Protocol (HSRP)
■ Virtual Router Redundancy Protocol (VRRP)
■ Gateway Load Balancing Protocol (GLBP)
Hot Standby Router Protocol -  HSRP is a Cisco-proprietary protocol developed to allow several routers (or multilayer
switches) to appear as a single gateway IP address. HSRP rules –

1. Basically, each of the routers that provides redundancy for a given gateway address is assigned to a common HSRP group.
2. One router is elected as the primary, or active, HSRP router; another is elected as the standby HSRP router; and all the others
remain in the listen HSRP state.
3. HSRP sends its hello messages to the multicast destination 224.0.0.2 (“all routers”) using UDP port 1985.
4. Each HSRP router shares a common ip address between them for a particular group. These groups are locally significant.
5. Each HSRP router has their priority & highest configured priority router selected as active (highest 255). If all priority same
then highest ip address router became active.

Disabled Init Listen Speak Standby Active

HSRP states  ----
                        
HSRP hello & failover - Only the standby (the one with the second-highest priority) router monitors the hello messages from the active
router. By default, hellos are sent every 3 seconds. If hellos are missed for the duration of the holdtime timer (default 10 seconds, or
three times the hello timer), the active router is presumed to be down. The standby router is then clear to assume
the active role. At that point, if other routers are sitting in the Listen state, the next-highest priority router is allowed to become the new
standby router.
HSRP preempt - Normally, after the active router fails and the standby becomes active, the original active router cannot immediately
become active when it is restored. Means if a router is not already active, it cannot become active again until the current active router
fails—even if its priority is higher than that of the active router.You can configure a router to preempt or immediately take over the
active role if its priority is the highest at any time. Use the following interface configuration command to allow
preemption: Switch(config-if)# standby group preempt [delay [minimum seconds] [reload seconds]]
HSRP authentication – Plain text authentication - Switch(config-if)# standby group authentication string
Switch(config)# key chain chain-name
Switch(config-keychain)# key key-number
Switch(config-keychain-key)# key-string [0 | 7] string
Switch(config)# interface type mod/num
Switch(config-if)# standby group authentication md5 key-chain chain-name
MD5 authentication –
HSRP Tracking –
For tracking the preempt must be enable. HSRP provide us redundancy not only with device level but with interface & route level also.
Means in case a gateway is up but one interface of the gateway is down or a route from the routing table is down then it can down the
active router to passive & make the other alternate router to become active & provide the desired connectivity.
An HSRP router can track – 1. Interface   2. Reachability to a route from routing table.  
In both cases a HSRP active router configured with a decrement value which will decrease by that amount if the above objects down.
Client gateway configuration – The clients are configured with hsrp virtual ip address as their gateway. The mac address against the
ip will be - 0000.0c07.ac01 where last value 1 is the group number 1. arp command on the client can show the mac address.
Load balancing with HSRP – Only one router (active) can send traffic for the virtual ip configure in HSRP & other standby router stays
idle. Load balancing traffic across two uplinks to two HSRP routers with a single HSRP group is not possible. The trick is to use two
HSRP groups:
■ One group assigns an active router to one switch.
■ The other group assigns another active router to the other switch.
Each router is active for one group and standby for the other group. The clients or end users also must have their default gateway
addresses configured as one of the two virtual HSRP group addresses.
Configuration with 2 groups (load balancing) -           Default priority is 100. Default preempt is 20 seconds

CatalystA is not only the active router for HSRP Group 1 (192.168.1.1), but it is also the standby router for HSRP Group 2
(192.168.1.2). CatalystB is configured similarly, but with its roles reversed. The remaining step is to configure half of the client PCs
with the HSRP Group 1 virtual router address and the other half with the Group 2 address. For verification – show standby

HSRP track configuration -  Suppose catalystA & catalystB connected with different ISPs. Users are getting internet from both ISPs
now if ISP connected to catA goes down or the interface connected to ISP of catA shuts down then the users using gateway
192.168.1.1 are unable to reach internet. Because an interface or a route down on a switch doesn’t mean that the device is down
hence both switches will maintain their configured priority & users using gateway address 192.168.1.1 will not have internet access.
This is how we can solve the problem –
R1#
interface FastEthernet0/1
ip address 10.1.1.1 255.255.255.0
 standby 1 ip 10.1.1.254
 standby 1 priority 110
 standby 1 preempt
 standby 1 track FastEthernet0/0 65
standby 1 track 100 decrement 65         (See next page for
reffere)
R2#
interface FastEthernet0/1
 description LAN
 ip address 10.1.1.2 255.255.255.0
 standby version 2
 standby 1 ip 10.1.1.254
 standby 1 preempt
 standby 1 track FastEthernet0/0 50

Now configure tracking an object. Which will ping 192.168.1.1 every 5 seconds and never stop. If it gets a reply, consider the SLA
successful. If it get don’t get response, consider it a failure & switch to other router (R2)
ip sla monitor 10
 type echo protocol ipIcmpEcho 192.168.1.1
 frequency 5
ip sla monitor schedule 10 life forever start-time now
track 100 rtr 10
VRRP – VRRP has the same capabilities as HSRP. The configurations are same & differences are mentioned below –
Roles HSRP VRRP
Vendor Cisco proprietary Multi vendor support
Default preempt 20 seconds 0 sec
Mac-address of group 1 0000.0c07.ac01  0000.5e00.0101
State Active - Standby Master - Backup
Hello sent every 3 sec 1 sec
Multicast destination 224.0.0.2 224.0.0.18
Tracking Interface, RTR, route reachability through track RTR, route reachability through track
GLBP -  HSRP & VRRP provide full redundancy but for load-balancing we need to create 2 different groups for these protocols. Also
clients are divided in two groups where one group will use gateway address of first hsrp group & other group will use the second.
GLBP allows us to overcome these extra configurations. All routers in the group can participate and offer load balancing by forwarding
a portion of the overall traffic. GLBP is cisco proprietary. The advantage is that none of the clients has to be pointed toward a specific
gateway address; they can all have the same default gateway set to the virtual router IP address. The load balancing is provided
completely through the use of virtual router MAC addresses in ARP replies returned to the clients. As a client sends an ARP request
looking for the virtual router address, GLBP sends back an ARP reply with the virtual MAC address of a selected router in the group.
The result is that all clients use the same gateway address but have differing MAC addresses for it.
How GLBP works – Active virtual gateway (AVG) -   One router is elected the active virtual gateway (AVG). This router has the highest
priority value, or the highest IP address in the group, if there is no highest priority. The AVG answers all ARP requests for
the virtual router ip  address. Which MAC address it returns depends on which load-balancing algorithm it is configured to use. The
AVG also assigns the virtual MAC addresses to each of the routers participating in the GLBP group. Up to four virtual MAC addresses
can be used in any group. Each of these routers is referred to as an active virtual forwarder (AVF), forwarding traffic received on its
virtual MAC address. Other routers in the group serve as backup or secondary virtual forwarders, in case the AVF fails. The AVG also
assigns secondary roles. Assign the GLBP priority to a router with the following interface configuration command:
Switch(config-if)# glbp group priority level    (group numbers can be from 0 to 1023 & priority 0to 255, default priority - 100)
Active virtual forwarder (AVF) - Each router participating in the GLBP group can become an AVF, if the AVG assigns it that role, along
with a virtual MAC address. Even AVG is the first AVF for the group.The virtual MAC addresses always have the form 0007.b4xx.xxyy.
 xx.xx represents six zero bits followed by a 10-bit GLBP group number. The 8-bit yy value is the virtual forwarder number. AVFs
forwarding virtual mac-address reply for each other AVFs means if there are four AVFs, one AVF can forward with the mac-address of
the other AVFs & vice versa.  If hellos from the AVF are not received by the AVG before its holdtime timer expires, the AVG assumes
that the current AVF has failed. The AVG then assigns the AVF role to another router. Naturally, the router that is given the new AVF
role might already be an AVF with a different virtual MAC address. For example if the router holding the mac address-0002 fails then
the router holding the mac address-0003 will have to take the role & mac-address of the down router 0002.  Although a router can
masquerade as two different virtual MAC addresses to support the two AVF functions, it does not make much sense to continue
doing that for a long period of time. The AVG maintains two timers that help resolve this condition. The redirect timer is used to
determine when the AVG will stop using the old virtual MAC address in ARP replies. When the timeout timer expires, the old MAC
address and the virtual forwarder using it are flushed from all the GLBP peers. The AVG assumes that the previously failed AVF will
not return to service, so the resources assigned to it must be reclaimed. At this point, clients still using the old MAC address in their
ARP caches must refresh the entry to obtain the new virtual MAC address. Switch(config-if)# glbp group timers redirect redirect
timeout
GLBP timers – Hellos sent to & between every router in the GLBP group. Default hello is 3 seconds & holddown timers is 10 sec.
The redirect timer is 600 sec (10 mins), timeout timer is 4 hours.
GLBP Preempt – As like hsrp, glbp preempt should be configure to take over the avg role. Default preempt delay is 30 seconds.
GLBP load balancing -  AVG first must inform the AVFs in the group of the virtual MAC address that each should use. Up to four virtual
MAC addresses, assigned in sequential order, can be used in a group.
■ Round robin—Each new ARP request for the virtual router address receives the next available virtual MAC address in reply. Traffic
load is distributed evenly across all routers participating as AVFs in the group, this is the default method used by GLBP.
■Weighted—The GLBP group interface’s weighting value determines the proportion of traffic that should be sent to that AVF. A higher
weighting results in more frequent ARP replies containing the virtual MAC address of that router.
■ Host dependent—Each client that generates an ARP request for the virtual router address always receives the same virtual MAC
address in reply. This method is used if the clients have a need for a consistent gateway MAC address.
On the AVG router use the following interface configuration command to define the method:
Switch(config-if)# glbp group load-balancing [round-robin | weighted | host dependent]  
GLBP tracking – GLBP tracking is different than hsrp & vrrp. The GLBP configured priority remain same for all routers. The configured
weighting value decides which router will leave the AVF role if track object is down.  
GLBP configuration – R1, R2, R3,R4 connected to access layer switch & all clients are using gateway address of 192.168.1.1.
With core layer ISP router connected with them via ospf & a network of 200.200.200.200 will be track. Weighting value
 R1 R2
interface FastEthernet1/1 interface FastEthernet1/2
ip address 192.168.1.101 255.255.255.0 ip address 192.168.1.102 255.255.255.0
 glbp 1 ip 192.168.1.1  glbp 1 ip 192.168.1.1
 glbp 1 priority 101  glbp 1 priority 102
 glbp 1 preempt  glbp 1 preempt
glbp 1 forwarder preempt glbp 1 forwarder preempt
glbp 1 weighting 100 lower 90 upper 99 glbp 1 weighting 100 lower 90 upper 99
 glbp 1 weighting track 1 decrement 11  glbp 1 weighting track 1 decrement 11
glbp 1 load-balancing weighted glbp 1 load-balancing weighted
ip sla monitor 10 ip sla monitor 10
 type echo protocol ipIcmpEcho 200.200.200.200 source-    type echo protocol ipIcmpEcho 200.200.200.200 source-  
 interface FastEthernet0/0  interface FastEthernet0/0
ip sla monitor schedule 10 life forever start-time now ip sla monitor schedule 10 life forever start-time now
track 1 rtr 10 reachability track 1 rtr 10 reachability
R3 R4  (AVG)
interface FastEthernet1/3 interface FastEthernet1/4
 ip address 192.168.1.103 255.255.255.0 ip address 192.168.1.104 255.255.255.0
 glbp 1 ip 192.168.1.1  glbp 1 ip 192.168.1.1
 glbp 1 priority 103  glbp 1 timers redirect 60 660
 glbp 1 preempt  glbp 1 priority 104
glbp 1 forwarder preempt  glbp 1 preempt
glbp 1 weighting 100 lower 90 upper 99 glbp 1 forwarder preempt
glbp 1 weighting track 1 decrement 11 glbp 1 weighting 100 lower 90 upper 99
glbp 1 load-balancing weighted glbp 1 weighting track 1 decrement 11
ip sla monitor 10 glbp 1 load-balancing weighted
 type echo protocol ipIcmpEcho 200.200.200.200 source-   ip sla monitor 10
 interface FastEthernet0/0  type echo protocol ipIcmpEcho 200.200.200.200 source-  
ip sla monitor schedule 10 life forever start-time now  interface FastEthernet0/0
track 1 rtr 10 reachability ip sla monitor schedule 10 life forever start-time now
track 1 rtr 10 reachability
R1 is the AVG because its priority configured to 104 highest of them all & R3 is standby AVG as it has 2nd highest priority.
Redirect timers need to configure only on AVG (R4) & rest of them will update themselves with the configured value of AVG.
Weighting value configured to 100 & it tells the router to track the object & if the object is down by the configured decrement value
then the weighting value drops below 90 then release itself as an AVF. If the weighting value becomes above 99 then again be an AVF
Forwarder preempt must be configure otherwise the avf s won’t preempt the forwarder role & the forwarding AVF will continue its AVF
role so even if the tracked object goes down the AVF will not decrement its weighting value thus try to forward client queries.
Forward preempt will not show in sh run
 Load-balancing must be configure to weighted
Verifying GLBP
 ←Forwarding for IP 192.168.1.1
←Redirect & forwarder flush timeout
←Normal preempt enable
← Active R4 standby R3
← Local AVF’s mac-address
← 1 active means the router is an AVF. O
active means the router is  
               no longer an AVF & will flush after
configured 660 seconds
← Forwarder 1, State is active means R4 is
forwarding on behalf of
                 R1’s mac-address. Next line –
showing mac-address of R1.
← Redirection enable means forwarder
preempt configured.

 
← R3 is forwarding for itself. (State is
active)
← R2 is forwarding on behalf of R4 (State
is active)
 ←R1 sending on behalf of R2

Now if the reachability of the tracked route is down from one AVF. The forwarder preempt command configured on the routers 60
seconds. So if the tracked object of R4 is down it will decrement it’s configured weighting priority to 100 – 11 = 89. For granting the
AVF role R4 needs to have at least the lower threshold of 90. So R4 will release the AVF role after 60 sec & flush after 660 seconds.
Now the route 200.200.200.200 is unreachable from R4. After 60 seconds the show GLBP value on all routers –
 ←Track object 1 state is down,
decrement 11. So the weight is
100-11=89. Lower threshold is 90
So it will release the avf role
←Still there are 4 forwarders but
showing 0 active because R4’s AVF
role is assigned to some other
router after 60 seconds & if after
660
Seconds the R4 doesn’t reclaim its
AVF role then R4’s mac-address
will flush with its AVF designation &
no router will forward on behalf of
R4’s mac-address.

 
 ←R3 is active for 2 AVFs. R1 & R3. (state is
active for 2 forwarders)

 
  
R1 holding the role for R2’s mac-address.                         R2 holding the role for R4’s mac-address but for 660 seconds only
IP SERVER LOAD BALANCING (IPSLB)
Client from different networks are trying to access the website hosted on 80 port. They are accessing to 10.10.10.10 IP in which they
believe the webserver hosted but it is a virtual IP & 3 servers are running in the backend & they all are resolving client queries.
Configuration –
ip slb serverfarm WEBSERVERS
 nat server                                                        
 real 10.10.10.1 80
  inservice
 real 10.10.10.2 80
  inservice
 real 10.10.10.3 80
  inservice
!
ip slb vserver VIRTUALSERVER
 virtual 10.10.10.10 tcp www
 serverfarm WEBSERVERS
 sticky 1
 delay 1
 client 192.168.0.0 255.255.0.0
 inservice
!
interface FastEthernet0/0
 ip address 10.10.10.254 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.0.1 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 172.16.0.2
 Monitoring –
Real servers are replying one by one. In case one got down client can get to port 80 through other servers.
VPN & TUNNLEING

GRE, MGRE, DMVPN & IPSEC TUNNEL by Sudeb

Generic Router encapsulation (GRE) – Tunneling provides a mechanism to transport packets of one protocol within another protocol.
The protocol that is carried is called as the passenger protocol, and the protocol that is used for carrying the passenger protocol is
called as the transport protocol. Generic Routing Encapsulation (GRE) is one of the available tunneling mechanisms which uses IP as
the transport protocol and can be used for carrying many different passenger protocols. The tunnels behave as virtual point-to-point
links that have two endpoints identified by the tunnel source and tunnel destination addresses at each endpoint.  
Tunneling consists of three main components:
Passenger protocol—The protocol that you are encapsulating. For example, IPv4 and IPv6 protocols.
Carrier protocol—The protocol that encapsulates. For example, generic routing encapsulation (GRE) and Multiprotocol Label Switching
(MPLS).
Transport protocol--The protocol that carries the encapsulated protocol. The main transport protocol is IP.
  Configuration – 

1. Create a GRE tunnel with tunnel ID

2. Set an IP address of the GRE tunnel interface. This (private) ip address will be on same network with other end of tunnel.
3. Provide a tunnel source which will be the public ip address of the router exit interface connected with internet.
4. Provide a tunnel destination which will be the public ip address of the remote end router’s exit interface public ip.
5. A static route for remote end internal network needs to be specify through the next-hop of remote tunnel ip address.  

Left side ROUTER Right Side ROUTER

R1(Config)# interface tunnel 1 R2(Config)# interface tunnel 1
R1(Config-if)# ip address 172.16.1.1   255.255.255.0 R2(Config-if)# ip address 172.16.1.2   255.255.255.0
R1(Config-if)# Tunnel Source 1.1.1.1 R2(Config-if)# Tunnel Source 2.2.2.2
R1(Config-if)# Tunnel Destination 2.2.2.2 R2(Config-if)# Tunnel Destination 1.1.1.1
R1(Config)# )# ip route 192.168.2.0 255.255.255.0 R2(config)# ip route 192.168.1.0 255.255.255.0
172.16.1.2   172.16.1.1   
Now both networks (192.168.1.0/24 and 192.168.2.0/24) are able to freely communicate with each other over the GRE Tunnel .  We
can configure any dynamic routing protocol also.
GRE with dynamic routing protocol – Instead of static route if we have dynamic routing protocol configure on our internal network.
Routers are running OSPF between then on WAN part. On internal network we have 10.0.0.248/30 & 252/30 which we need to send
through tunnel
 interface Tunnel0 interface Tunnel0
 ip address 192.168.0.1 255.255.255.252  ip address 192.168.0.2 255.255.255.252
 tunnel source 10.0.0.1  tunnel source 10.0.0.10
 tunnel destination 10.0.0.10  tunnel destination 10.0.0.1
! !
router eigrp 100 router eigrp 100
 network 10.0.0.248 0.0.0.3  network 10.0.0.252 0.0.0.3
 network 192.168.0.0 0.0.0.3  network 192.168.0.0 0.0.0.3
We can’t advertise or distribute eigrp onto ospf. We need to advertise tunnel subnet & lan subnet on Eigrp.
IOU4# show ip route eigrp.                   10.0.0.248/30 [90/27008000] via 192.168.0.1, 00:35:10, Tunnel0
Dynamic multipoint VPN (DMVPN) - Consider a hub-and-spoke VPN topology in which multiple remote sites have a site-to- site VPN
connection to a headquarters location. If one remote site wanted to communicate securely with another remote site, the traffic would
travel between the sites through the headquarters location, rather than directly between the sites. One fix for this would be to create a
full mesh of IPsec site-to-site VPN connections, which would provide a direct IPsec VPN connection between any two remote sites.
Such a solution, however, could be complex and expensive to configure and maintain. A more economical solution is the Dynamic
Multipoint VPN (DMVPN). DMVPN allows a VPN tunnel to be dynamically created and torn down between two remote sites on an
as-needed basis.
Multipoint GRE (MGRE) - The scalability offered by DMVPN is made possible by multipoint GRE, which allows a router to support
multiple GRE tunnels on a single GRE interface. mGRE’s characteristics are as follows:
1.  Like traditional GRE, mGRE can transport a wide variety of protocols (for example, IP unicast, multicast, and broadcast).
2.  In a hub-and-spoke topology, a hub router can have a single mGRE interface, and multiple tunnels can use that single interface.
3.  An interface configured for mGRE is able to dynamically form a GRE tunnel by using Next Hop Resolution Protocol (NHRP) to
discover the IP    
     address of the device at the far end of the tunnel.
NHRP - DMVPNs require that routers run Next Hop Resolution Protocol (NHRP), which uses a client-server model. A router designated
as a hub router acts as a server. The remaining routers, designated as spokes, act as clients. NHRP spokes are configured with the IP
address of the NHRP hub, and when a spoke comes online, it informs the hub of both physical IP address and a Tunnel IP address.
MGRE Config – 3 branches connected with HUB through ISP.  They are communicating to each other’s lan subnet through the tunnel
interface
HUB R1 R2
interface Tunnel0 interface Tunnel0 interface Tunnel0
 ip address 10.0.0.254 255.255.255.0  ip address 10.0.0.1 255.255.255.0  ip address 10.0.0.2 255.255.255.0
 ip nhrp network-id 10  ip nhrp map 10.0.0.254 90.0.0.1  ip nhrp map 10.0.0.254 90.0.0.1
 tunnel source 90.0.0.1  ip nhrp network-id 10  ip nhrp network-id 10
 tunnel mode gre multipoint  ip nhrp nhs 10.0.0.254  ip nhrp nhs 10.0.0.254
 tunnel source 90.0.0.6  tunnel source 90.0.0.10
 tunnel mode gre multipoint  tunnel mode gre multipoint
Ip nhrp network-id – The network id has to be identical on every router.
Ip nhrp map – On spoke (client) router we’ve to map the HUB router’s tunnel IP with hub router’s corresponding physical ip. This is a
static mapping.  
IP nhrp nhs – it’s the next hop server which is the HUB router tunnel ip.

Now between Spoke to HuB communication – a static route needs to be create

HUB# Ip route 192.168.1.0 0.0.0.255 10.0.0.1, Ip route 192.168.2.0 0.0.0.255 10.0.0.2, Ip route 192.168.3.0 0.0.0.255 10.0.0.3
R1, R2, R3 - # ip route 192.168.0.0 0.0.0.255 10.0.0.254
Spoke can communicate each other with a static route between them. In that case a spoke will query to HUB for destination spoke
nhrp mapping.
Instead of static route dynamic protocol can be configure between HUB & Spokes. Below is an example of OSPF configure between
HUB & spokes –
HUB R1
Interface Tunnel 0 Interface Tunnel 0
ip nhrp map multicast dynamic ip nhrp map multicast 90.0.0.6
ip ospf network point-to-multipoint non-broadcast ip ospf network point-to-multipoint
! non-broadcast
router ospf 1 !
network 192.168.0.0 0.0.0.255 area 100 Router ospf 1
network 10.0.0.0 0.0.0.255  area 100 network 192.168.1.0 0.0.0.255 area 100
neighbor 10.0.0.1 network 10.0.0.0 0.0.0.255  area 100
neighbor 10.0.0.2
neighbor 10.0.0.3
 As the ospf network is p2p NBMA we’ve to manually configure neighbor on either side.
SITE TO SITE IPsec VPN ON CISCO ROUTERS
ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to building and encrypting the VPN
tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the negotiation protocol that allows two hosts to agree on how to build an
IPsec security association. ISAKMP negotiation consists of two phases: Phase 1 and Phase 2.  
Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.
 IPSec then comes into play to encrypt the data using encryption algorithms and provides authentication, encryption and anti-replay
services. IPSec VPN Requirements
To help make this an easy-to-follow exercise, we have split it into two steps that are required to get the Site-to-Site IPSec VPN Tunnel
to work. These steps are:
(1)  Configure ISAKMP (ISAKMP Phase 1)
(2)  Configure IPSec  (ISAKMP Phase 2, ACLs, Crypto MAP)
Our example setup is between two branches of a small company, these are Site 1 and Site 2. Both the branch routers connect to the
Internet and have a static IP Address assigned by their ISP as shown on the diagram:

Site 1 is configured with an internal network of 10.10.10.0/24, while Site 2 is configured with network 20.20.20.0/24. The goal is to
securely connect both LAN networks and allow full communication between them, without any restrictions.
Configure ISAKMP (IKE) - (ISAKMP Phase 1)  IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this,
IKE must negotiate an SA (an ISAKMP SA) relationship with the peer. First step is to configure an ISAKMP Phase 1 policy:
R1(config)#  crypto isakmp policy 1
R1(config-isakmp)# encr 3des
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)# lifetime 86400
The above commands define the following (in listed order):
3DES - The encryption method to be used for Phase 1.
MD5 - The hashing algorithm
Pre-share - Use Pre-shared key as the authentication method
Group 2 - Diffie-Hellman group to be used
86400 – Session key lifetime. Expressed in either kilobytes (after x-amount of traffic, change the key) or seconds. Value set is the
default value.
We should note that ISAKMP Phase 1 policy is defined globally. This means that if we have five different remote sites and configured
five different ISAKMP Phase 1 policies (one for each remote router), when our router tries to negotiate a VPN tunnel with each site it
will send all five policies and use the first match that is accepted by both ends.
Next we are going to define a pre shared key for authentication with our peer (R2 router) by using the following command:
R1(config)# crypto isakmp key firewallcx address 1.1.1.2
The peer’s pre shared key is set to firewallcx and its public IP Address is 1.1.1.2. Every time R1 tries to establish a VPN tunnel with R2
(1.1.1.2), this pre shared key will be used.
Configure IPSec
To configure IPSec we need to setup the following in order:
- Create extended ACL
- Create IPSec Transform
- Create Crypto Map
- Apply crypto map to the public interface
Creating Extended ACL
R1(config)# ip access-list extended VPN-TRAFFIC
R1(config-ext-nacl)# permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
Create IPSec Transform (ISAKMP Phase 2 policy)
Next step is to create the transform set used to protect our data. We’ve named this TS:
R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
The above command defines the following:  
- ESP-3DES - Encryption method                    - MD5 - Hashing algorithm
Create Crypto Map
The Crypto map is the last step of our setup and connects the previously defined ISAKMP and IPSec configuration together:
R1(config)# crypto map CMAP 10 ipsec-isakmp
R1(config-crypto-map)# set peer 1.1.1.2
R1(config-crypto-map)# set transform-set TS
R1(config-crypto-map)# match address VPN-TRAFFIC
We’ve named our crypto map CMAP. The ipsec-isakmp tag tells the router that this crypto map is an IPsec crypto map. Although there
is only one peer declared in this crypto map (1.1.1.2), it is possible to have multiple peers within a given crypto map.
Apply Crypto Map to the Public Interface
The final step is to apply the crypto map to the outgoing interface of the router. Here, the outgoing interface is FastEthernet 0/1.
R1(config)# interface FastEthernet0/1
R1(config- if)# crypto map CMAP
As soon as we apply crypto map on the interface, we receive a message from the router that confirms isakmp is on: “ISAKMP is ON”.
We now move to the Site 2 router to complete the VPN configuration. The settings for Router 2 are identical, with the only difference
being the peer IP Addresses and access lists:
R2(config)# crypto isakmp policy 1
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# group 2
R2(config-isakmp)# lifetime 86400
R2(config)# crypto isakmp key firewallcx address 1.1.1.1
R2(config)# ip access-list extended VPN-TRAFFIC
R2(config-ext-nacl)# permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R2(config)# crypto map CMAP 10 ipsec-isakmp
R2(config-crypto-map)# set peer 1.1.1.1
R2(config-crypto-map)# set transform-set TS
R2(config-crypto-map)# match address VPN-TRAFFIC
R2(config)# interface FastEthernet0/1
R2(config- if)# crypto map CMAP
Network Address Translation (NAT) and IPSec VPN Tunnels
Network Address Translation (NAT) is most likely to be configured to provide Internet access to internal hosts. When configuring a
Site-to-Site VPN tunnel, it is imperative to instruct the router not to perform NAT (deny NAT) on packets destined to the remote VPN
network(s). This is easily done by inserting a deny statement at the beginning of the NAT access lists as shown below:
For Site 1’s router:
R1(config)# ip nat inside source list 100 interface fastethernet0/1 overload
R1(config)# access-list 100 remark -=[Define NAT Service]=-
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
R1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)# access-list 100 remark
And Site 2’s router:
R2(config)# ip nat inside source list 100 interface fastethernet0/1 overload
R2(config)# access-list 100 remark -=[Define NAT Service]=-
R2(config)# access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0  0.0.0.255
R2(config)# access-list 100 permit ip 20.20.20.0 0.0.0.255 any
R2(config)# access-list 100 remark
R1# ping 20.20.20.1 source fastethernet0/0
 Sending 5, 100-byte ICMP Echos to 20.20.20.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 44/47/48 ms
To verify the VPN Tunnel, use the show crypto session command:
R1# show crypto session
Crypto session current status
           Interface: FastEthernet0/1
Session status: UP-ACTIVE    
Peer: 1.1.1.2 port 500
    IKE SA: local 1.1.1.1/500 remote 1.1.1.2/500 Active
    IPSEC FLOW: permit ip 10.10.10.0/255.255.255.0 20.20.20.0/255.255.255.0
Active SAs: 2, origin: crypto map
** Tracert will not show the full network path that is being use while travelling from one lan to another. It will show the remote network
as a next hop.
ISIS

ISIS on IOS & IOS-XR by Sudeb Das

AD value – 115
Hello 10 seconds, dead 30 seconds, DR sends hello every 3 seconds.
IS-IS routers share an area topology through link-state packets (LSPs) that allows them to build an LSPDB. IS-IS uses NET addresses to build
the LSPDB topology.

NET Addressing – For ISIS the AFI uses values between 00 and 99, and the AFI 49 is a private number.

Read the NET address from right to left – 1st byte is SEL, Next 6-bytes as the system ID, and the remaining 1 to 13 bytes are the Area
Address including AFI.  49.0001.1234.AAAA.AAAA.AAAA.00  –
 Area address = 49.0001.1234, System ID = AAAA.AAAA.AAAA, NSEL = 00

 NET addressing guidelines -

Two adjacent IS-IS routers with the same area addresses belong to the same area.
Every device in the same area must have a unique system ID.
IS-IS routers can have multiple NET addresses assigned to them but can have only one system ID.

CLNS - The Connectionless Network Service (CLNS) provides the mechanism for transporting protocol data units (PDUs), also known as
packets, between nodes. In the OSI model, CLNS PDUs transport CLNP (connectionless network protocol) datagrams between CLNS peers.

ISIS neighbor states – 1. Down, 2. Initializing, 3. UP

Areas – OSPF provides connectivity between areas by allowing a router to participate in multiple areas, whereas IS-IS places the entire router
and all its interfaces in a specific area.

IS-IS Router Types:

L1 routers:  Level 1 routers have no direct connectivity with another area. These routers maintain L1 link-state database. To route a packet to
another area, an L1 router must forward the packet to L1-L2 router. They are equals to OSPF nonbackbone internal routers.

L2 routers: Level 2 routers are connecting the areas. These routers maintain a L2 link-state database. These routers are equals to OSPF
backbone routers. L2 router can communicate with L2 routers in the same or a different area.

L1/L2 routers: L1/L2 routers maintain a separate L1 & L2 link-state database. These routers can connect to L1 and L2 routers. L1/L2 routers
are equal to OSPF ABRs. L1/L2 routers do not advertise L2 routes to L1 routers.

ISIS Configuration – on IOS

Router(config)# router isis
 Router(config)# net 49.0123.1921.6800.2002.00

Router(config)# Interface g0/0

Router(config-if)# Ip router isis

ISIS configuration – on IOS-XR   (ipv4)

RP/0/RP0/CPU0: router(config)# router isis SUDEB
RP/0/RP0/CPU0: router(config-isis)# net 49.0123.0000.0000.0001.00
RP/0/RP0/CPU0: router(config-isis)# interface  GigabitEthernet 0 /3/0/0
RP/0/RP0/CPU0: router(config-isis-if)# address-family ipv4 unicast
L1 router with L1-L2 router - Creates L1 adjacency at both end.

L1-L2 router with L1-L2 router – Creates L1 & L2 (two) adjacencies between them.

L2 router with L1-L2 router – Creates L2 adjacency between them.

L1-L2 Router will receive all the L1 & L2 routes in routing table in respective of L1 or L2 –  

L2 router will receive all the L1 & L2 routes in routing table as L2 

L1 router will receive only L1 route & will not receive any L2 route in routing table. 
Show clns neighbors detail will show the area which the router belongs

– 

Show clns interface will show the circuit type, level, metric, priority, DR id, l1 & l2 hellos. 

DIS (Designated intermediate system) –

On broadcast multi-access networks, a single router is elected as the DIS. There is no backup DIS elected. The DIS is the router that creates
the pseudonode and acts on behalf of the pseudonode.
What is the Pseudonode (PSN)?
In order to reduce the number of full mesh adjacencies between nodes on multiaccess links, the multiaccess link itself is modeled as a
pseudonode. This is a virtual node, as the name implies. The DIS creates the pseudonode. All routers on the broadcast link, including the DIS,
form adjacencies with the pseudonode.
 In IS-IS, a DIS does not synchronize with its neighbors. After the DIS creates the pseudonode for the LAN, it sends hello packets for each
Level (1 and 2) every three seconds and CSNPs (Complete sequence number PDU) every ten seconds. The hello packets indicate that it is the
DIS on the LAN for that level, and the CSNPs describe the summary of all the LSPs, including the LSP ID, sequence number, checksum, and
remaining lifetime.

Election of the DIS - On a LAN

1.       One of the router elects itself the DIS, based on interface priority (the default is 64).
2.       If all interface priorities are the same, the router with the highest MAC address on a LAN, and the local data link connection identifier (DLCI)
on a Frame Relay network.
Every IS-IS router interface is assigned both a L1 priority and a L2 priority in the range from 0 to 127. The DIS election is preemptive (unlike
OSPF). If a new router boots on the LAN with a higher interface priority, the new router becomes the DIS. It purges the old pseudonode LSP
and floods a new set of LSPs.

ISIS Database – LSPDB (The link-state packet database) –

The LSPDB contains all the LSPs, for a specific level, and L1-L2 routers will have two LSPDBs. All routers within the same level maintain an
identical LSPDB.
LSPDB are shown with the command - show isis database [level-1 | level-2]
There are six LSPs and five routers in the topology. This is because five of the LSPs are non-pseudonode LSPs, and one of the LSPs
(R5.02-00) is a pseudonode LSP for the 10.235.1.0/24 broadcast network.

LSP Holdtime – The remaining lifetime that the LSP remains valid on the router.
ATT: (Attachment bit) - Indicate if the originating router is attached to more than one areas.
Overload (OL) bit: If the originating router is experiencing a memory over-utilization, it will set this bit to the receiving router will then not use
this router as the transit.

Link-State Packets -
LSPs are similar to OSPF LSAs, where they advertise neighbors and attached networks, except that IS-IS uses only two types of LSPs. L1 LSP
& L2 LSP.IS-IS defines an LSP type for each level. L1 LSPs are flooded throughout the area from which they originate, and L2 LSPs are
flooded throughout the L2 network. New LSP sends every 15 minutes & Max age value for a LSP is 20 minutes.
LSP ID contains – System ID, Pseudeonode ID, fragment ID.

LSP sequence –
IS router increments the sequence number to 1 every time it floods a LSP. A router will process only LSPs that contain a sequence
number greater than the one in the LSPDB. Same as OSPF LSA seq.   

ISIS splitting into multiple levels & areas -

Level 1–Level 2 (L1-L2) routers maintain a separate LSPDB for both levels. L1-L2 routers set the attached bit to their L1 LSPs, providing L1
routers connectivity to networks in a different area. If an L1 router does not have a route for a destination network, it searches for the closest
router with the attached bit set in the LSP to forwarding traffic. Dividing routing into multiple domain & areas (for L1 router) will – Shrink the
LSPDB, Shorten the SPF calculation, Allow summarization between ISIS levels.

Route Leaking - A technique that redistributes the L2 level routes into the L1 level. Route leaking normally uses a restrictive route map or
route policy to control which routes are leaked. Leaked routes are interarea and external to the L1 area

Route leaking on XR –
route-policy PASS-ALL
pass
end-policy

router isis SUDEB

propagate level 2 into level 1 route-policy PASS-ALL

Route leaking on IOS -

router isis
redistribute isis ip level-2 into level-1 route-map PASS-ALL

route-map PASS-ALL permit 10

Passive interface –
Making the network interface passive still adds the network segment into the LSPDB, but prohibits the interface from forming IS-IS
adjacencies. A passive interface does not send out IS-IS traffic and will not process any received ISIS packets.

XR1 router isis

router isis CISCO net 49.0012.0000.0000.0002.00

net 49.0012.0000.0000.0001.00 passive-interface GigabitEthernet0/0

interface Loopback0 interface GigabitEthernet0/0

passive ip router isis

address-family ipv4 unicast

ISIS authentication – ISIS supports plaintext & MD5 hash authentication.

ISIS Circuit type –

ISIS supports different circuit type than the specific level configure globally for a router. If the router level set at L1-L2 & we configure one
interface as level 1 or level 2 it will form the level 1 only or level 2 only adjacencies with neighbor. If the router level configure as L2 or L1 only
then setting one interface as L1 or L2 or L1-L2 will not override the router level & restrict the interface as per router level.

ISIS route types –

L2 routes from same area doesn’t advertise to L1 router. Once L1-L2 router connects to a different area router, the L1 router receive a default
route from L1-L2 router which helps it to reach the same area as well as different area L2 & L1 routes.
Intra-area routes are routes that are learned from another router within the same level and area address.
Interarea routes are routes that are learned from another L2 router that came from an L1 router or from an L2 router from a different area
address.
External routes are routes that are redistributed into the IS-IS domain. External routes can choose between two metric types:
Internal metrics are less value. External metrics cannot be comparable with internal path metrics and must be set in a route
map or route policy during redistribution. Internal metrics are always preferred to external metrics.
IS-IS best-path selection -
identifying the route with the lowest path metric for each stage:
1. L1 intra-area routes
L1 external routes with internal metrics
2. L2 intra-area routes
L2 external routes with internal metric
L1 --> L2 interarea routes
L1 --> L2 interarea external routes with internal metrics
3. Leaked routes (L2 --> L1) with internal metrics
4. L1 external routes with external metrics
5. L2 external routes with external metric
L1 --> L2 interarea external routes with external metrics
6. Leaked routes (L2 --> L1) with external metrics

Metric & Metric style –

Every interface has by default cost set to 10. You can change metric from range 1 – 63 and total max. cost of the path can be 1023.
Two types of metric : narrow and wide. Narrow is default and has limitations. Interface metric can be maximum of 63 (6 bits) and total cost
cannot be more than 1023 (10 bits). Wide metric increases number of bits to 24. So cost can be set up to 1677214.
There is also transition type, where router accepts both narrow and wide metric style. If 1 side has narrow & other has wide then it can create
problem.  Configuration –
XR & Router -
router isis Sudeb
metric-style narrow level 1                          
metric-style wide level 2
metric 50 level 1                                                               *for narrow we can’t set more than 63
metric 5000 level 2

Overload Bit -
The overload bit indicates when a router is in an overloaded condition. During the IS-IS SPF calculation, routers avoid sending traffic through
routers that set the overload bit in LSPDB. Configuring overload-bit on an advertising router manually will prevent neighbor from learning
other area routes through it. The overloaded-Bit will show as 1 on the neighbor router. Configuration -
XR & Router -
router isis Sudeb
set-overload-bit

Summarization -
Because all routers within a level must maintain an identical copy of the LSPDB, summarization occurs when routers enter an IS-IS level, such
as -
L1 routes entering the L2 backbone | L2 routes leaking into the L1 backbone | Redistribution of routes into an area
XR -
router isis CISCO
summary-prefix 172.16.0.0/16

Router -
router isis
summary-address 172.31.0.0 255.255.0.0

Default route –
IS-IS uses the attached bit to provide a route of last resort for L1 routers to locate an L1-L2 router attached to the backbone.
In case L2 router needs to send a default route – the default-information originate command required.
XR -
router isis SUDEB
default-information originate

Router -
router isis
default-information originate