OSPF

Overview
OSPF (Open Shortest Path First)
OSPF is a standardized Link-State routing protocol, designed to scale efficiently to
support larger networks.
OSPF adheres to the following Link State characteristics:
 OSPF employs a hierarchical network design using Areas.
 OSPF will form neighbor relationships with adjacent routers in the same
Area.
 Instead of advertising the distance to connected networks, OSPF advertises
the
status of directly connected links using Link-State Advertisements (LSAs).
 OSPF sends updates (LSAs) when there is a change to one of its links, and
will only
send the change in the update. LSAs are additionally refreshed every 30
minutes.
 OSPF traffic is multicast either to address 224.0.0.5 (all OSPF routers) or
224.0.0.6 (all Designated Routers).
 OSPF uses the Dijkstra Shortest Path First algorithm to determine the
shortest
path.
 OSPF is a classless protocol, and thus supports VLSMs.
 Build the Protocol Run Routing
Database Algorithm

Form Neighbour Populate the

Relationship IP Routing
Table
Other characteristics of OSPF include:
 OSPF supports only IP routing.
 OSPF routes have an administrative distance is 110.
 OSPF uses cost as its metric, which is computed based on the bandwidth of
the link. OSPF has no hop-count limit.
The OSPF process builds and maintains three separate tables:
 A neighbor table – contains a list of all neighboring routers.
 A topology table – contains a list of all possible routes to all known
networks
within an area.
 A routing table – contains the best route for each known network.
 OSPF
• Areas
Link State protocol
• Uses a 2 level hierarchical model Area 3
• Areas defined with 32 bit number
Defined in IP address format or single
decimal value (i.e., Area 0.0.0.0, or Area Area 0
0)
Area 2
• 0.0.0.0 (0) reserved for the Area 1
backbone area
• Area 0 has to contiguous
The OSPF Hierarchy

OSPF is a hierarchical system that separates an Autonomous System into individual

areas. OSPF traffic can either be intra-area (within one area), inter-area (between
separate areas), or external (from another AS).
OSPF routers build a Topology Database of all links within their area, and all routers
within an area will have an identical topology database. Routing updates between these
routers will only contain information about links local to their area. Limiting the topology
database to include only the local area conserves bandwidth and reduces CPU loads.
Area 0 is required for OSPF to function, and is considered the “Backbone” area. As a
rule, all other areas must have a connection into Area 0, though this rule can be bypassed
using virtual links (explained shortly). Area 0 is often referred to as the transit area to
connect all other areas.
OSPF routers can belong to multiple areas, and will thus contain separate Topology
databases for each area. These routers are known as Area Border Routers (ABRs).
Consider the above example. Three areas exist: Area 0, Area 1, and Area 2. Area 0, again,
is the backbone area for this Autonomous System. Both Area 1 and Area 2 must directly
connect to Area 0.
Routers A and B belong fully to Area 1, while Routers E and F belong fully to Area 2.
These are known as Internal Routers.
Router C belongs to both Area 0 and Area 1. Thus, it is an ABR. Because it has an
interface in Area 0, it can also be considered a Backbone Router.
The same can be said for Router D, as it belongs to both Area 0 and Area 2.
Now consider the above example. Router G has been added, which belongs to Area 0.
However, Router G also has a connection to the Internet, which is outside this Autonomous
System.
This makes Router G an Autonomous System Border Router (ASBR). A router can
become an ASBR in one of two ways:
 By connecting to a separate Autonomous System, such as the Internet
 By redistributing another routing protocol into the OSPF process.
ASBRs provide access to external networks. OSPF defines two “types” of external routes:
  Type 2 (E2) – Includes only the external cost to the destination network. External cost
is the metric being advertised from outside the OSPF domain. This is the default type
assigned to external routes.
 Type 1 (E1) – Includes both the external cost, and the internal cost to reach the ASBR,
to determine the total metric to reach the destination network. Type 1 routes are always
preferred over Type 2 routes to the same destination.
Thus, the four separate OSPF router types are as follows:
 Internal Routers – all router interfaces belong to only one Area.
 Area Border Routers (ABRs) – contains interfaces in at least two separate areas
 Backbone Routers – contain at least one interface in Area 0
 Autonomous System Border Routers (ASBRs) – contain a connection to a
separate Autonomous System
OSPF LSAs – OSPFv2

• Router and Network LSA’s within an

area (Type 1 and Type 2) Area 3
• Summary LSA Type 3 outside the
area. Generated by ABR.
• Summary LSA Type 4 generated by Area 0
ABR to describe route to ASBR
Area 2
• Type 5 for redistributed routes Area 1
generated by ASBR
• Partial SPF for summary and
External LSA’s
OSPF, as a link-state routing protocol, does not rely on routing-by-rumor as RIP and IGRP
do.
Instead, OSPF routers keep track of the status of links within their respective areas. A link is
simply a router interface. From these lists of links and their respective statuses, the
topology database is created. OSPF routers forward link-state advertisements (LSAs) to
ensure the topology database is consistent on each router within an area.
Several LSA types exist:
 Router LSA (Type 1) – Contains a list of all links local to the router, and the status and
“cost” of those links. Type 1 LSAs are generated by all routers in OSPF, and are flooded
to all other routers within the local area.
 Network LSA (Type 2) – Generated by all Designated Routers in OSPF, and contains a
list of all routers attached to the Designated Router.
 Network Summary LSA (Type 3) – Generated by all ABRs in OSPF, and contains a list
of all destination networks within an area. Type 3 LSAs are sent between areas to allow
inter-area communication to occur.
 ASBR Summary LSA (Type 4) – Generated by ABRs in OSPF, and contains a route to
any ASBRs in the OSPF system. Type 4 LSAs are sent from an ABR into its local area, so
that Internal routers know how to exit the Autonomous System.
 External LSA (Type 5) – Generated by ASBRs in OSPF, and contain routes to
destination networks outside the local Autonomous System. Type 5 LSAs can also take
the form of a default route to all networks outside the local AS. Type 5 LSAs are
flooded to all areas in the OSPF system.
Multicast OSPF (MOSPF) utilizes a Type 6 LSA, but that goes beyond the scope of this
guide.
Later in this section, Type 7 NSSA External LSAs will be described in detail.
From the above example, the following can be determined:
 Routers A, B, E, and F are Internal Routers.
 Routers C and D are ABRs.
 Router G is an ASBR.
All routers will generate Router (Type 1) LSAs. For example, Router A will generate a
Type 1 LSA that contains the status of links FastEthernet 0/0 and FastEthernet 0/1.
This LSA will be flooded to all other routers in Area 1.
Designated Routers will generate Network (Type 2) LSAs. For example, if Router C was
elected the DR for the multi-access network in Area 1, it would generate a Type 2 LSA
containing a list of all routers attached to it.
Area Border Routers (ABRs) will generate Network Summary (Type 3) LSAs. For
example, Router C is an ABR between Area 0 and Area 1. It will thus send Type 3 LSAs
into both areas. Type 3 LSAs sent into Area 0 will contain a list of networks within Area 1,
including costs to reach those networks. Type 3 LSAs sent into Area 1 will contain a list
of networks within Area 0, and all other areas connected to Area 0. This allows Area 1 to
reach any other area, and all other areas to reach Area 1.
ABRs will also generate ASBR Summary (Type 4) LSAs. For example, Router C will
send Type 4 LSAs into Area 1 containing a route to the ASBR, thus providing routers in
Area 1 with the path out of the Autonomous System.
ASBRs will generate External (Type 5) LSAs. For example, Router G will generate Type 5
LSAs that contain routes to network outside the AS. These Type 5 LSAs will be flooded to
routers of all areas.
Each type of LSA is propagated under three circumstances:
 When a new adjacency is formed.
 When a change occurs to the topology table.
 When an LSA reaches its maximum age (every 30 minutes, by default).
Thus, though OSPF is typically recognized to only send updates when a change occurs,
LSA’s are still periodically refreshed every 30 minutes.
OSPF Neighbors
OSPF forms neighbor relationships, called adjacencies, with other routers in the same Area by
exchanging Hello packets to multicast address 224.0.0.5. Only after an adjacency is formed can routers
share routing information.
Each OSPF router is identified by a unique Router ID. The Router ID can be determined in one of three
ways:
 The Router ID can be manually specified.
 If not manually specified, the highest IP address configured on any
Loopback interface on the router will become the Router ID.
 If no loopback interface exists, the highest IP address configured on any Physical interface will
become the Router ID.
By default, Hello packets are sent out OSPF-enabled interfaces every 10 seconds for broadcast and
point-
to-point interfaces, and 30 seconds for non- broadcast and point-to-multipoint interfaces.
OSPF also has a Dead Interval, which indicates how long a router will wait without hearing
any hellos before announcing a neighbor as “down.” Default for the Dead Interval is 40
seconds for broadcast and point-to-point interfaces, and 120 seconds for non-broadcast and
point-to-multipoint interfaces. Notice that, by default, the dead interval timer is four times
the Hello interval.
These timers can be adjusted on a per interface basis:
Router(config-if)# ip ospf hello-interval 15
Router(config-if)# ip ospf dead-interval 60
OSPF routers will only become neighbors if the following parameters within a Hello packet
are identical on each router:
 Area ID
 Area Type (stub, NSSA, etc.)
 Prefix
 Subnet Mask
 Hello Interval
 Dead Interval
 Network Type (broadcast, point-to-point, etc.)
 Authentication
The Hello packets also serve as keepalives to allow routers to quickly discover if a neighbor is down.
Hello packets also contain a neighbor field that lists the Router IDs of all neighbors the router is
connected to.
A neighbor table is constructed from the OSPF Hello packets, which includes the following
information:
 The Router ID of each neighboring router
 The current “state” of each neighboring router
 The interface directly connecting to each neighbor
 The IP address of the remote interface of each neighbor
OSPF Designated Routers
In multi-access networks such as Ethernet, there is the
possibility of many neighbor relationships on the same
physical segment. In the above example, four routers are
connected into the same multi-access segment. Using the
following formula (where “n” is the number of routers):
n(n-1)/2
…..it is apparent that 6 separate adjacencies are needed for a fully meshed network.
Increase the number of routers to five, and 10 separate adjacencies would be required. This
leads to a considerable amount of unnecessary Link State Advertisement (LSA) traffic.
If a link off of Router A were to fail, it would flood this information to all neighbors.
Each neighbor, in turn, would then flood that same information to all other neighbors.
This is a waste of bandwidth and processor load.
To prevent this, OSPF will elect a Designated Router (DR) for each multi- access
networks, accessed via multicast address 224.0.0.6. For redundancy purposes, a Backup
Designated Router (BDR) is also elected.
OSPF routers will form adjacencies with the DR and BDR. If a change occurs to a link,
the update is forwarded only to the DR, which then forwards it to all other routers. This
greatly reduces the flooding of LSAs.
DR and BDR elections are determined by a router’s OSPF priority, which is configured
on a per-interface basis (a router can have interfaces in multiple multi-access networks).
The router with the highest priority becomes the DR; second highest becomes the BDR.
If there is a tie in priority, whichever router has the highest Router ID will become the
DR. To change the priority on an interface:
Router(config-if)# ip ospf priority 125
Default priority on Cisco routers is 1. A priority of 0 will prevent the router from being
elected DR or BDR. Note: The DR election process is not preemptive. Thus, if a router
with a higher priority is added to the network, it will not automatically supplant an existing
DR. Thus, a router that should never become the DR should always have its priority set to
0.
OSPF Neighbor States
Neighbor adjacencies will progress through several states, including:
Down – indicates that no Hellos have been heard from the neighboring router.
Init – indicates a Hello packet has been heard from the neighbor, but two- way
communication has not yet been initialized.
2Way – indicates that bidirectional communication has been established. Recall that
Hello packets contain a neighbor field. Thus, communication is considered 2-Way once a
router sees its own Router ID in its neighbor’s Hello Packet. Designated and Backup
Designated Routers are elected at this stage.
ExStart – indicates that the routers are preparing to share link state information.
Master/slave relationships are formed between routers to determine who will begin
the exchange.
Exchange – indicates that the routers are exchanging Database Descriptors (DBDs).
DBDs contain a description of the router’s Topology Database. A router will examine a
neighbor’s DBD to determine if it has information to share.
Loading – indicates the routers are finally exchanging Link State Advertisements,
containing information about all links connected to each router. Essentially, routers are
sharing their topology tables with each other.
Full – indicates that the routers are fully synchronized. The topology table of all routers in
the area should now be identical. Depending on the “role” of the neighbor, the state may
appear as:
 Full/DR – indicating that the neighbor is a Designated Router (DR)
 Full/BDR – indicating that the neighbor is a Backup Designated Router (BDR)
 Full/DROther – indicating that the neighbor is neither the DR or BDR
On a multi-access network, OSPF routers will only form Full adjacencies with DRs and
BDRs. Non-DRs and non-BDRs will still form adjacencies, but will remain in a 2-Way
State. This is normal OSPF behavior.
OSPF Neighbour Adjacency Process
10.1.1.1 10.2.2.2

R1 R2

{
Hello
RID =10.1.1.1 Init on R2
• Init
Hello
RID =10.2.2.2 Init on R1

{
Hello
RID =10.1.1.1
2-Way on R2
N =10.2.2.2
• 2-
Way Hello
RID =10.2.2.2
2-Way on R1
N =10.1.1.1
OSPF Neighbour Adjacency Process
10.1.1.1 10.2.2.2

R1 R2

DBD
• EXSTAR MTU = 1500
T Flag = 0x7
Seq = 0x2499

DBD
• EXCHANGE MTU = 1500
Flag = 0x3
Seq = 0x837
OSPF Neighbour Adjacency Process
10.1.1.1 10.2.2.2

R1 R2

LS Request
LS Type
• LOADIN Link State
G ID
Advertising Router

LS Update
# LSA’s
• FULL LSA’s
LSA ..
•3.2.a Compare routing concepts of EIGRP and
OSPF (advanced distance vector vs. linked state,
load balancing, path selection, path operations,
metrics)

• 3.2.b Configure and verify simple OSPF

environments, including multiple normal
areas, summarization, and filtering
(neighbor adjacency, point-to-point and
broadcast network types, and passive
interface)
OSPF Network Type
| Metric | Passive-
Interface
OSPF Network Types
OSPF’s functionality is different across several different network topology types.
OSPF’s interaction with Frame Relay will be explained in another section
Broadcast Multi-Access – indicates a topology where broadcast occurs.
 Examples include Ethernet, Token Ring, and ATM.
 OSPF will elect DRs and BDRs.
 Traffic to DRs and BDRs is multicast to 224.0.0.6. Traffic from DRs and BDRs
to other routers is multicast to 224.0.0.5.
 Neighbors do not need to be manually specified.
Point-to-Point – indicates a topology where two routers are directly connected.
 An example would be a point-to-point T1.
 OSPF will not elect DRs and BDRs.
 All OSPF traffic is multicast to 224.0.0.5.
 Neighbors do not need to be manually specified.
Point-to-Multipoint – indicates a topology where one interface can connect to multiple
destinations. Each connection between a source and destination is treated as a point-to-
point link.
 An example would be Point-to-Multipoint Frame Relay.
 OSPF will not elect DRs and BDRs.
 All OSPF traffic is multicast to 224.0.0.5.
 Neighbors do not need to be manually specified.
Non-broadcast Multi-access Network (NBMA) – indicates a topology where one
interface can connect to multiple destinations; however, broadcasts cannot be sent
across a NBMA network.
 An example would be Frame Relay.
 OSPF will elect DRs and BDRs.
 OSPF neighbors must be manually defined, thus All OSPF traffic is unicast
instead of multicast.
Remember: on non-broadcast networks, neighbors must be manually specified,
as
multicast Hello’s are not allowed.
Configuring OSPF Network Types
The default OSPF network type for basic Frame Relay is Non-broadcast Multi-access
Network (NBMA). To configure manually:
Router(config)# interface s0
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay map ip 10.1.1.1 101
Router(config-if)# ip ospf network non-broadcast
Router(config)# router ospf 1
Router(config-router)# neighbor 10.1.1.1
Notice that the neighbor was manually specified, as multicasting is not allowed on an
NBMA. However, the Frame-Relay network can be tricked into allowing broadcasts,
eliminating the need to manually specify neighbors:
Router(config)# interface s0
Router(config-if)# encapsulation frame-relay
Router(config-if)# frame-relay map ip 10.1.1.1 101 broadcast
Router(config-if)# ip ospf network broadcast
Notice that the ospf network type has been changed to broadcast, and the broadcast
parameter was added to the frame-relay map command. The neighbor no longer
needs to
be specified, as multicasts will be allowed out this map.
The default OSPF network type for Ethernet and Token Ring is Broadcast Multi-Access.
To configure manually:
Router(config)# interface e0
Router(config-if)# ip ospf network broadcast
The default OSPF network type for T1’s (HDLC or PPP) and Point-to-Point Frame Relay
is Point-to-Point. To configure manually:
Router(config)# interface s0
Router(config-if)# encapsulation frame-relay
Router(config)# interface s0.1 point-to-point
Router(config-if)# frame-relay map ip 10.1.1.1 101 broadcast
Router(config-if)# ip ospf network point-to-point
Configuring OSPF Network Types (continued)
The default OSPF network type for Point-to-Multipoint Frame Relay is still Non-broadcast
Multi-access Network (NBMA). However, OSPF supports an additional network type
called Point-to-Multipoint, which will allow neighbor discovery to occur automatically. To
configure:
Router(config)# interface s0
Router(config-if)# encapsulation frame-relay
Router(config)# interface s0.2 multipoint
Router(config-if)# frame-relay map ip 10.1.1.1 101 broadcast
Router(config-if)# ip ospf network point-to-multipoint
Additionally, a non-broadcast parameter can be added to the ip ospf network
command when specifying point-to-multipoint.
 Router(config)# interface s0
Router(config-if)# encapsulation frame-relay
Router(config)# interface s0.2 multipoint
Router(config-if)# frame-relay map ip 10.1.1.1 101
Router(config-if)# ip ospf network point-to-multipoint non-broadcast
Router(config)# router ospf 1
Router(config-router)# neighbor 10.1.1.1
Notice the different in configuration. The frame-relay map command no
longer has the broadcast parameter, as broadcasts and multicasts are
not allowed on a non-broadcast network.
Thus, in the OSPF router configuration, neighbors must again be manually
specified. Traffic to those neighbors will be unicast instead of multicast.
OSPF network types must be set identically on two “neighboring”
routers, otherwise they will never form an adjacency.
The OSPF Metric
OSPF determines the best (or shortest) path to a destination network using a cost metric,
which is based on the bandwidth of interfaces. The total cost of a route is the sum of all
outgoing interface costs. Lowest cost is preferred.
Cisco applies default costs to specific interface types:

Type Cost

Serial (56K) 1785

Serial (64K) 1562
T1 (1.544Mbps) 64
Token Ring (4Mbps) 25
Ethernet (10 Mbps) 10
Token Ring (16 Mbps) 6
Fast Ethernet 1
Configuring Basic
OSPF

Routing protocol configuration occurs in Global Configuration mode. On

Router A, to configure OSPF:
RouterA(config)# router ospf 1
RouterA(config-router)# router-id 1.1.1.1
RouterA(config-router)# network 172.16.0.0 0.0.255.255 area 1
RouterA(config-router)# network 172.17.0.0 0.0.255.255 area 0
The first command, router ospf 1, enables the OSPF process. The “1” indicates the
OSPF process ID, and can be unique on each router. The process ID allows
multiple OSPF processes to run on the same router. The router-id command assigns
a unique OSPF ID of 1.1.1.1 for this router.
Note the use of a wildcard mask instead of a subnet mask in the network statement. With
OSPF, we’re not telling the router what networks to advertise; we’re telling the router to
place certain interfaces into specific areas, so those routers can form neighbor
relationships. The wildcard mask 0.0.255.255 tells us that the last two octets can match any
number.
The first network statement places interface E0 on Router A into Area 1. Likewise, the
second network statement places interface S0 on Router A into Area 0. The network
statement could have been written more specifically:
RouterA(config)# router ospf 1
RouterA(config-router)# network 172.16.1.2 0.0.0.0 area 1
RouterA(config-router)# network 172.17.1.1 0.0.0.0 area 0
In order for Router B to form a neighbor relationship with Router A, its connecting
interface must be put in the same Area as Router A:
RouterB(config)# router ospf 1
RouterA(config-router)# router-id 2.2.2.2
RouterB(config-router)# network 172.17.1.2 0.0.0.0 area 0
RouterB(config-router)# network 172.18.1.1 0.0.0.0 area 2
If Router B’s S0 interface was placed in a different area than Router A’s S0 interface, the
two routers would never form a neighbor relationship, and never share routing updates.
OSPF Passive-Interfaces

It is possible to control which router interfaces will participate in the OSPF process. Just as
with EIGRP and RIP, we can use the passive-interface command.
However, please note that the passive-interface command works differently with OSPF
than with RIP or IGRP. OSPF will no longer form neighbor relationships out of a “passive”
interface, thus this command prevents updates from being sent or received out of this
interface:
RouterC(config)# router ospf 1
RouterC(config-router)# network 10.4.0.0 0.0.255.255 area 0
RouterC(config-router)# network 10.2.0.0 0.0.255.255 area 0
RouterC(config-router)# passive-interface s0
Router C will not form a neighbor adjacency with Router
B.
It is possible to configure all interfaces to be passive using the passive- interface default
command, and then individually use the no passive- interface command on the interfaces
that neighbors should be formed on:
RouterC(config)# router ospf 1
RouterC(config-router)# network 10.4.0.0 0.0.255.255 area 0
RouterC(config-router)# network 10.2.0.0 0.0.255.255 area 0
RouterC(config-router)# passive-interface default
RouterC(config-router)# no passive-interface e0

Always remember, that the passive-interface command will prevent OSPF (and EIGRP)
from forming neighbor relationships out of that interface. No routing updates are passed in
either direction.
OSPF Authentication & Virtual Link
OSPF
Authentication

OSPF supports authentication to secure routing updates. However, OSPF authentication is

configured differently than RIP or EIGRP authentication.
Two forms of OSPF authentication exist, using either clear-text or an MD5 hash. To
configure clear-text authentication, the first step is to enable authentication for the area,
under the OSPF routing process:
RouterA(config)# router ospf 1
RouterA(config-router)# network 172.17.0.0 0.0.255.255 area 0
RouterA(config-router)# area 0 authentication
Then, the authentication key must be configured on the interface:
RouterA(config)# interface s0
RouterA(config-if)# ip ospf authentication
RouterA(config-if)# ip ospf authentication-key MYKEY
To configure MD5-hashed authentication, the first step is also to enable
authentication for the area under the OSPF process:
RouterA(config)# router ospf 1
RouterA(config-router)# network 172.17.0.0 0.0.255.255 area 0
RouterA(config-router)# area 0 authentication message-digest
Notice the additional parameter message-digest included with the area 0
authentication command. Next, the hashed authentication key must be configured
on the interface:
RouterA(config)# interface s0
RouterA(config-router)# ip ospf message-digest-key 10 md5 MYKEY
Area authentication must be enabled on all routers in the area, and the form

of
authentication must be identical (clear-text or MD5). The authentication keys do
not
need to be the same on every router in the OSPF area, but must be the same on
interfaces connecting two neighbors.
Please note: if authentication is enabled for Area 0, the same authentication must
be
configured on Virtual Links, as they are “extensions” of Area 0.
OSPF Virtual Links

Earlier in this guide, it was stated that all areas must directly connect into Area 0, as a
rule. In the above example, Area 2 has no direct connection to Area 0, but must transit
through Area 1 to reach the backbone area. In normal OSPF operation, this shouldn’t be
possible.
There may be certain circumstances that may prevent an area from directly connecting into
Area 0. Virtual links can be used as a workaround, to logically connect separated areas to
Area 0. In the above example, a virtual link would essentially create a tunnel from Area 2
to Area 0, using Area 1 a transit area. One end of the Virtual Link must be connected to
Area 0.
Configuration occurs on the Area Border Routers (ABRs) connecting Area 1 to Area 2
(Router B), and Area 1 to Area 0 (Router C). Configuration on Router B would be as
follows:
RouterB(config)# router ospf 1
RouterB(config-router)# router-id 2.2.2.2
RouterB(config-router)# area 1 virtual-link 3.3.3.3
The first command enables the ospf process. The second command manually sets the
router-id for Router B to 2.2.2.2.
The third command actually creates the virtual-link. Notice that it specifies area 1, which is
the transit area. Finally, the command points to the remote ABR’s Router ID of 3.3.3.3.
Configuration on Router C would be as follows:
RouterC(config)# router ospf 1
RouterC(config-router)# router-id 3.3.3.3
RouterC(config-router)# area 1 virtual-link 2.2.2.2
OSPF Virtual Links (continued)

It is also possible to have two separated (or discontiguous) Area 0’s. In order for OSPF to
function properly, the two Area 0’s must be connected using a virtual link.
Again, configuration occurs on the transit area’s ABRs:
RouterB(config)# router ospf 1
RouterB(config-router)# router-id 2.2.2.2
RouterB(config-router)# area 1 virtual-link 3.3.3.3
RouterC(config)# router ospf 1
RouterC(config-router)# router-id 3.3.3.3
RouterC(config-router)# area 1 virtual-link 2.2.2.2
Always remember: the area specified in the virtual-link command is
the
transit
As area.
stated Additionally,
earlier, the transit
if authentication area cannot
is enabled be a0,stub
for Area thearea.
same authentication must be
configured on Virtual Links, as they are “extensions” of Area 0:
RouterB(config)# router ospf 1
RouterB(config-router)# area 1 virtual-link 3.3.3.3 message-digest-key 1 md5 MYKEY
RouterC(config)# router ospf 1
RouterC(config-router)# area 1 virtual-link 2.2.2.2 message-digest-key 1 md5 MYKEY
OSPF Summarization |
Area Types | Default
Routes
Inter-Area OSPF Summarization

Consider the above example. OSPF is a classless routing protocol, thus all of the listed
networks would be advertised individually. This increases the size of the topology
databases and routing tables on routers in the domain, and may be undesirable. Advertising
only a summary route for inter-area communication can reduce the load on router CPUs.
For example, all of the networks in Area 1 can be summarized as 10.1.0.0/21. Similarly,
all of the networks in Area 2 can be summarized as 10.1.8.0/21.
Inter-area summarization is configured on Area Border Routers (ABRs).
Configuration on Router A would be as follows:
RouterA(config)# router ospf 1
RouterA(config-router)# network 10.1.0.0 0.0.7.255 area 1
RouterA(config-router)# area 1 range 10.1.0.0 255.255.248.0
The network statement includes all of the 10.1.x.0 networks into Area 1. The
area 1 range command creates a summary route for those networks, which is
then advertised into Area 0, as opposed to each route individually.
Proper design dictates that a static route be created for the summarized
network, pointing to the Null interface. This sends any traffic destined
specifically to the summarized address to the bit-bucket in the sky, in order to
prevent routing loops:
RouterA(config)# ip route 10.1.0.0 255.255.248.0 null0

In IOS versions 12.1(6) and later, this static route is created automatically.
External OSPF
Summarization

Consider the above example. Router B is an Autonomous System Border Router

(ASBR). It is possible to redistribute the four “external” networks into the OSPF system.
However, a separate route for each network will be advertised.
Again, this is wasteful. The four external networks can be summarized as
15.0.0.0/14.
External Summarization is configured on ASBRs, and will only summarize external
routes learned by route redistribution. Configuration on Router B would be as follows:
RouterB(config)# router ospf 1
RouterB(config-router)# summary-address 15.0.0.0 255.252.0.0
This summarized route is now propagated to all routers in every OSPF
area.
Summarization can be used to filter certain
15.1.0.0 networks
routes . To as a summarized
force OSPF to advertise route, but not advertise the 15.2.0.0 and
the 15.0.0.0
15.3.0.0 prefixes:
and RouterB(config)# router ospf 1
RouterB(config-router)# summary-address 15.0.0.0 255.254.0.0
RouterB(config-router)# summary-address 15.2.0.0 255.255.0.0 not-advertise
RouterB(config-router)# summary-address 15.3.0.0 255.255.0.0 not-advertise

The first summary-address command summarizes the 15.0.0.0/16 and 15.1.0.0/16 networks
to 15.0.0.0/15, and advertises the summary as normal in the OSPF domain. The next two
summary-address commands specifically reference the 15.2.0.0/16 and 15.3.0.0/16
networks, with the not-advertise parameter. As implied, these networks will not be
advertised in OSPF.
OSPF Area Types
In order to control the propagation of LSAs in the OSPF domain, several area types
were developed.
Standard Area – A “normal” OSPF area.
 Routers within a standard area will share Router (Type 1) and Network (Type 2)
LSAs to build their topology tables. Once fully synchronized, routers within an
area will all have identical topology tables.
 Standard areas will accept Network Summary (Type 3) LSAs, which contain the
routes to reach networks in all other areas.
 Standard areas will accept ASBR Summary (Type 4) and External (Type
5) LSAs, which contain the route to the ASBR and routes to external networks,
respectively.
Configuration of standard areas is straight forward:
Router(config)# router ospf 1
Router(config-router)# network 10.1.0.0 0.0.7.255 area 1
Stub Area – Prevents external routes from flooding into an
area.  Like Standard areas, Stub area routers will share Type 1 and Type 2 LSAs to build
their topology tables.
 Stub areas will also accept Type 3 LSAs to reach other areas.
 Stub areas will not accept Type 4 or Type 5 LSAs, detailing routes to external
networks.
The purpose of Stub areas is to limit the number of LSAs flooded into the area, to
conserve
bandwidth and router CPUs. The Stub’s ABR will automatically inject a default
route into
the Stub area, so that those routers can reach the external networks. The ABR will be
the
next-hop for the default route.
Configuration of stub areas is relatively simple:
Router(config)# router ospf 1
Router(config-router)# network 10.1.0.0 0.0.7.255 area 1
Router(config-router)# area 1 stub
The area 1 stub command must be configured on all routers in the Stub area.
OSPF Area Types (continued)

Totally Stubby Area – Prevents both inter-area and external routes from flooding into
an area.
 Like Standard and Stub areas, Totally Stubby area routers will share Type 1 and
Type 2 LSAs to build their topology tables.
 Totally Stubby areas will not accept Type 3 LSAs to other areas.
 Totally Stubby areas will also not accept Type 4 or Type 5 LSAs, detailing routes
to external networks.
Again, the purpose of Totally Stubby areas is to limit the number of LSAs flooded into
the area, to conserve bandwidth and router CPUs. The Stub’s ABR will instead
automatically inject a default route into the Totally Stubby area, so that those routers
can reach both inter-area networks and external networks. The ABR will be the next-hop
for the default route.
Configuration of totally stubby areas is relatively
simple: Router(config)# router ospf 1
Router(config-router)# network 10.1.0.0 0.0.7.255 area 1
Router(config-router)# area 1 stub no-summary
The area 1 stub no-summary command is configured only on the ABR of the
Totally Stubby area; other routers within the area are configured with the area 1
stub command. No ASBRs are allowed in a Totally Stubby area.
In the above example, if we were to configure Area 1 as a Totally Stubby area, it
would not accept any external routes originating from the ASBR (Router G). It
also would not accept any Type 3 LSAs containing route information about
Area 0 and Area 2. Instead, Router C (the ABR) will inject a default route into
Area 1, and all routers within Area 1 will use Router C as their gateway to all
other networks.
 OSPF Area Types (continued)
External
Networks
More External
Networks

Area 1 Area 2
Router G

Router A Router E

Router C Router D

Router B Area 0 Router

F
Not So Stubby Area (NSSA) – Similar to a Stub area; prevents external routes from
flooding into an area, unless those external routes originated from an ASBR within the
NSSA area.
 Like Standard and Stub areas, NSSA area routers will share Type 1 and Type 2
LSAs to build their topology tables.
 NSSA areas will also accept Network Summary (Type 3) LSAs, which contain the
routes to reach networks in all other areas.
 NSSA areas will not accept Type 4 or Type 5 LSAs, detailing routes to external
networks.
  If an ASBR exists within the NSSA area, that ASBR will generate
Type 7 LSAs.
Again, NSSA areas are almost identical to Stub areas. If Area 1 was configured as an
NSSA, it would not accept any external routes originating from Router G (an ASBR
outside Area 1).
However, Area 1 also has an ASBR within the area (Router A). Those external routes will
be flooded into Area 1 as Type 7 LSAs. These external routes will not be forwarded to
other areas as Type 7 LSAs; instead, they will be converted into Type 5 LSAs by Area 1’s
ABR (Router C).
Configuration of NSSA areas is relatively simple:
Router(config)# router ospf 1
Router(config-router)# network 10.1.0.0 0.0.7.255 area 1
Router(config-router)# area 1 nssa
The area 1 nssa command must be applied to all routers in the NSSA area.
 OSPF Area Types (continued)
External
Networks
More External
Networks

Area 1 Area 2
Router G

Router A Router E

Router C Router D

Router B Area 0 Router F

Totally Not So Stubby Area (TNSSA) – Similar to a Totally Stubby area; prevents both
inter-area and external routes from flooding into an area, unless those external routes
originated from an ASBR within the NSSA area.
 Like Standard and Stub areas, TNSSA area routers will share Type 1 and Type 2
LSAs to build their topology tables.
  TNSSA areas will not accept Type 3 LSAs to other areas.
 TNSSA areas will not accept Type 4 or Type 5 LSAs, detailing routes to external
networks.
 If an ASBR exists within the TNSSA area, that ASBR will generate Type 7
LSAs.
With the exception of not accepting inter-area routes, TNSSA areas are identical in
function to NSSA areas.
Configuration of TNSSA areas is relatively simple:
Router(config)# router ospf 1
Router(config-router)# network 10.1.0.0 0.0.7.255 area 1
Router(config-router)# area 1 nssa no-summary
The area 1 nssa no-summary command is configured only on the ABR of the TNSSA area;
other routers within the area are configured with the area 1 nssa command.
OSPF and Default Routes
We have learned about four types of OSPF areas:
 Standard areas  Totally Stubby areas
 Stub areas  Not So Stubby areas (NSSA)
The ABRs and ASBRs of Standard areas do not automatically generate (or inject)
default routes into the area. Consider the following example:

Area 1 Area 0

External
Networks
Router A Router C

Router B
Assume that Area 1 is configured as a Standard area. Router C will forward Type 3 LSAs
from all other areas into Area 1, allowing Router A and Router B to reach inter-area
networks.
Notice also that Router A is an ASBR, connecting to an external Autonomous System.
Thus, Router A will generate Type 5 LSAs, detailing the routes to these external networks.
To additionally force Router A to generate a default route (indicating itself as the next
hop) for the external networks, and inject this into Area 1. This default route will be
advertised as a Type 5 LSA to all other areas:
RouterA(config)# router ospf 1
RouterA(config-router)# default-information originate
Router A must have a default route in its routing table in order for the above command to
function. Router A’s default route would point to some upstream router in the external
Autonomous System.
If a default route does not exist in its routing table, Router A can still be forced
to advertise a default route using the always parameter:
RouterA(config)# router ospf 1
RouterA(config-router)# default-information originate always
OSPF and Default Routes (continued)
The ABRs of Stub and Totally Stubby areas automatically generate (and inject) a default
route (0.0.0.0/0) into the area. Routers in Stub areas use this default route to reach external
networks, while routers in Totally Stubby areas use the default route to reach both inter-
area and external networks.
To control the “cost” metric of the default route in Stub or Totally Stubby areas
(configured on the ABR):
Router(config)# router ospf 1
Router(config-router)# area 1 stub
Router(config-router)# area 1 default-cost 10

The ABRs of NSSA areas must be manually configured to generate (and inject) a
default route into the area:
Router(config)# router ospf 1
Router(config-router)# area 1 nssa default-information-originate
 EIGRP
Overview
EIGRP
Basics
• Advanced distance vector, TLV based
protocol
• Uses DUAL algorithm
• Runs directly on top of IP/IPv6 protocol
88
• Uses multicast capabilities(Neighbour
relationship &Updates) EIGRP AS
1
• Support unequal cost path load
balancing
• Metric is based on the
bandwidth and
delay
EIGRP (Enhanced Interior Gateway Routing Protocol)

EIGRP is a Cisco-proprietary Hybrid routing protocol, incorporating features of

both Distance-Vector and Link-State routing protocols.
EIGRP adheres to the following Hybrid characteristics:
 EIGRP uses Diffusing Update Algorithm (DUAL) to determine the best path
among all “feasible” paths. DUAL also helps ensure a loop- free routing
environment.
 EIGRP will form neighbor relationships with adjacent routers in the same
Autonomous System (AS).
 EIGRP traffic is either sent as unicasts, or as multicasts on address
224.0.0.10, depending on the EIGRP packet type.
 Reliable Transport Protocol (RTP) is used to ensure delivery of most
EIGRP
packets.
 EIGRP routers do not send periodic, full-table routing updates. Updates are sent
when a change occurs, and include only the change.
 EIGRP is a classless protocol, and thus supports VLSMs.
Other characteristics of EIGRP include:
 EIGRP supports IP, IPX, and Appletalk routing.
 EIGRP applies an Administrative Distance of 90 for routes originating
within the local Autonomous System.
 EIGRP applies an Administrative Distance of 170 for external routes coming from
outside the local Autonomous System
 EIGRP uses Bandwidth and Delay of the Line, by default, to calculate its distance
metric. It also supports three other parameters to calculate its metric: Reliability,
Load, and MTU.
 EIGRP has a maximum hop-count of 224, though the default maximum hop-
count is set to 100.
EIGRP, much like OSPF, builds three separate tables:
 Neighbor table – list of all neighboring routers. Neighbors must belong to
the
same Autonomous System
 Topology table – list of all routes in the Autonomous System
 Routing table – contains the best route for each known network
EIGRP Neighbors
EIGRP forms neighbor relationships, called adjacencies, with other routers in the same AS
by exchanging Hello packets. Only after an adjacency is formed can routers share routing
information. Hello packets are sent as multicasts to address 224.0.0.10.
By default, on LAN and high-speed WAN interfaces, EIGRP Hellos are sent
every 5
seconds. On slower WAN links (T1 speed or slower), EIGRP Hellos are sent every 60
seconds by default.
The EIGRP Hello timer can be adjusted on a per interface basis:
Router(config-if)# ip hello-interval eigrp 10 7

The above command allows us to change the hello timer to 7 seconds for Autonomous
System 10.
In addition to the Hello timer, EIGRP neighbors are stamped with a Hold timer. The
Hold timer indicates how long a router should wait before marking a neighbor inactive, if
it stops receiving hello packets from that neighbor.
By default, the Hold timer is three times the Hello timer. Thus, on high- speed links the
timer is set to 15 seconds, and on slower WAN links the timer is set to 180 seconds.
The Hold timer can also be adjusted on a per interface basis:
Router(config-if)# ip hold-interval eigrp 10 21

The above command allows us to change the hold timer to 21 seconds for Autonomous
System 10.
Changing the Hello timer does not automatically change the Hold timer. Additionally,
Hello and Hold timers do not need to match between routers for an EIGRP neighbor
relationship to form.
EIGRP Neighbors (continued)
A neighbor table is constructed from the EIGRP Hello packets, which includes the
following information:
 The IP address of the neighboring router.
 The local interface that received the neighbor’s Hello packet.
 The Hold timer.
 A sequence number indicating the order neighbors were learned.
Adjacencies will not form unless the primary IP addresses on connecting interfaces are on
the same subnet. Neighbors cannot be formed on secondary addresses.
If connecting interfaces are on different subnets, an EIGRP router will log the following
error to console when a multicast Hello is received:
00:11:22: IP-EIGRP: Neighbor 172.16.1.1 not on common subnet for Serial0
Always ensure that primary IP addresses belong to the same subnet between EIGRP
neighbors.
To log all neighbor messages and errors to console, use the following two
commands: Router(config)# router eigrp 10
Router(config-router)# eigrp log-neighbor-changes
Router(config-router)# eigrp log-neighbor-warnings
The EIGRP Topology Table

Once EIGRP neighbors form adjacencies, they will begin to share routing information.
Each router’s update contains a list of all routes known by that router, and the respective
metrics for those routes.
All such routes are added to an EIGRP router’s topology table. The route with the lowest
metric to each network will become the Feasible Distance (FD). The Feasible Distance
for each network will be installed into the routing table.

The Feasible Distance is derived from the Advertised Distance of the router
sending the update, and the local router’s metric to the advertising router.
Confused? Consider the following example:
Router A has three separate paths to the Destination Network, either through Router B, C, or D. If we add up the metrics
to form a “distance” (the metrics are greatly simplified in this example), we can determine the following:
 Router B’s Feasible Distance to the Destination Network is 8.
 Router C’s Feasible Distance to the Destination Network is 23.
 Router D’s Feasible Distance to the Destination Network is 9.
Router B sends an update to Router A, it will provide an Advertised Distance of 8 to the Destination Network.
Router C will provide an AD of 23, and D will provide an AD of 9.
Router A calculates the total distance to the Destination network by adding the AD of the advertising router, with its
own distance to reach that advertising router. For example, Router A’s metric to Router B is 8; thus, the total distance
will be 16 to reach the Destination Network through Router B.
Remember, however, that Router A’s Feasible Distance must be the route with the
lowest metric. If we add the Advertised Distance with the local metric between each
router, we would see that:
 The route through Router B has a distance of 16 to the destination
 The route through Router C has a distance of 27 to the destination
 The route through Router D has a distance of 11 to the destination
Thus, the route through Router D (metric of 11) would become the Feasible
Distance
for Router A, and is added to the routing table as the best route.
This route is identified as the Successor.
To allow convergence to occur quickly if a link fails, EIGRP includes backup routes in the
topology table called Feasible Successors (FS). A route will only become a Successor if its
Advertised Distance is less than the current Feasible Distance. This is known as a Feasible
Condition (FC).
For example, we determined that Router A’s Feasible Distance to the destination is 11,
through Router D. Router C’s Advertised Distance is 23, and thus would not become a
Feasible Successor, as it has a higher metric than Router A’s current Feasible
Distance. Routes that are not Feasible Successors become route Possibilities.
Router B’s Advertised Distance is 8, which is less than Router A’s current Feasible
Distance. Thus, the route through Router B to the Destination Network would become a
Feasible Successor.
Feasible Successors provide EIGRP with redundancy, without forcing routers to re-
converge (thus stopping the flow of traffic) when a topology change occurs. If no Feasible
Successor exists and a link fails, a route will enter an Active (converging) state until an
alternate route is found.
EIGRP Packet Types
&
Configuring EIGRP
Metrics
EIGRP Packet Types
EIGRP employs five packet types:
 Hello packets - multicast
 Update packets – unicast or multicast
 Query packets – multicast
 Reply packets – unicast
 Acknowledgement packets - unicast
Hello packets are used to form neighbor relationships, and were explained in detail
previously. Hello packets are always multicast to address 224.0.0.10.
Update packets are sent between neighbors to build the topology and routing tables.
Updates sent to new neighbors are sent as unicasts. However, if a route’s metric is
changed, the update is sent out as a multicast to address 224.0.0.10.
Query packets are sent by a router when a Successor route fails, and there are no
Feasible Successors in the topology table. The router places the route in an Active state,
and queries its neighbors for an alternative route. Query packets are sent as a multicast
to address 224.0.0.10.
Reply packets are sent in response to Query packets, assuming the responding router
has an alternative route (feasible successor). Reply packets are sent as a unicast to
the querying router.
Recall that EIGRP utilizes the Reliable Transport Protocol (RTP) to ensure reliable
delivery of most EIGRP packets. Delivery is guaranteed by having packets acknowledged
using…..Acknowledgment packets!
Acknowledgment packets (also known as ACK’s) are simply Hello packets with no data,
other than an acknowledgment number. ACK’s are always sent as unicasts. The following
packet types employ RTP to ensure reliable delivery via ACK’s:
 Update Packets
 Query Packets
 Reply Packets
Hello and Acknowledgments packets do not utilize RTP, and thus do not require
acknowledgement.
EIGRP Route States
An EIGRP route can exist in one of two states, in the topology table:
 Active state
 Passive State
A Passive state indicates that a route is reachable, and that EIGRP is fully converged. A
stable EIGRP network will have all routes in a Passive state.
A route is placed in an Active state when the Successor and any Feasible Successors fail,
forcing the EIGRP to send out Query packets and re- converge. Multiple routes in an Active
state indicate an unstable EIGRP network. If a Feasible Successor exists, a route should
never enter an Active state.
Routes will become Stuck-in-Active (SIA) when a router sends out a Query packet, but
does not receive a Reply packet within three minutes. In other words, a route will become
SIA if EIGRP fails to re-converge. The local router will clear the neighbor adjacency with
any router(s) that has failed to Reply, and will place all routes from that neighbor(s) in an
Active state.
To view the current state of routes in the EIGRP topology table:
Router# show ip eigrp topology
IP-EIGRP Topology Table for AS(10)/ID(172.19.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status,

s - sia Status

P 10.3.0.0/16, 1 successors, FD is 2297856

via 172.16.1.2 (2297856/128256), Serial0
P 172.19 . 0. 0 /1 6 , 1 successors, FD is 281600
S e r i a l 1
via Connected,

To view only active routes in the topology table:

Router# show ip eigrp topology active
IP-EIGRP Topology Table for AS(10)/ID(172.19.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status
A 172.19.0.0/16, 1 successors, FD is 23456056 1 replies, active 0:00:38,
query-origin: Multiple Origins
EIGRP Metrics
EIGRP can utilize 5 separate metrics to determine the best route to a destination:
 Bandwidth (K1) – Slowest link in the route path, measured in kilobits
 Load (K2) – Cumulative load of all outgoing interfaces in the path, given as a
fraction of 255
 Delay of the Line (K3) – Cumulative delay of all outgoing interfaces in the path in
tens of microseconds
 Reliability (K4) – Average reliability of all outgoing interfaces in the path, given as a
fraction of 255
 MTU (K5) – The smallest Maximum Transmission Unit in the path. The MTU value
is actually never used to calculate the metric
By default, only Bandwidth and Delay of the Line are used. This is identical to IGRP,
except that EIGRP provides a more granular metric by multiplying the bandwidth and
delay by 256. Bandwidth and delay are determined by the interfaces that lead towards
the destination network.
By default, the full formula for determining the EIGRP metric is:
[10000000/bandwidth + delay] * 256
The bandwidth value represents the link with the lowest bandwidth in the path, in kilobits.
The delay is the total delay of all outgoing interfaces in the path.
As indicated above, each metric is symbolized with a “K” and then a number. When
configuring EIGRP metrics, we actually identify which metrics we want EIGRP to
consider. Again, by default, only Bandwidth and Delay are considered. Thus, using on/off
logic:
K1 = 1, K2 = 0, K3 = 1, K4 = 0, K5 = 0
If all metrics were set to “on,” the full formula for determining the EIGRP metric would
be:
[K1 * bandwidth * 256 + (K2 * bandwidth) / (256 - load)
+ K3 * delay * 256] * [K5 / (reliability + K4)]
Remember, the “K” value is either set to on (“1”) or off (“0”).
Configuring EIGRP Metrics
EIGRP allows us to identify which metrics the protocol should consider, using the
following commands:
Router(config)# router eigrp 10
Router(config-router)# metric weights 0 1 1 1 0 0
The first command enables the EIGRP process for Autonomous System 10. The second
actually identifies which EIGRP metrics to use. The first number
(0) is for Type of Service, and should always be zero. The next numbers, in
order, are K1 (1), K2 (1), K3 (1), K4 (0), and K5 (0). Thus, we are instructing EIGRP to
use bandwidth, load, and delay to calculate the total metric, but not reliability or MTU.
Our formula would thus be:
[K1 * bandwidth * 256 + (K2 * bandwidth) / (256 - load) + K3 * delay * 256]
The actual values of our metrics (such as bandwidth or delay) must be configured
indirectly. To adjust the bandwidth (in Kbps) of an interface:
Router(config)# int s0/0
Router(config-if)# bandwidth 64
Router(config-if)# ip bandwidth-percent eigrp 10 30
However, this command does not actually dictate the physical speed of the interface. It
merely controls how EIGRP considers this interface. Best practice is to set the bandwidth
to the actual physical speed of the interface. By default, a serial interface will have a
bandwidth of 1.544 Mbps (1544).
The ip bandwidth-percent eigrp command limits the percentage of bandwidth EIGRP can
use on an interface. The percentage is based on the configured bandwidth value. By
default, EIGRP will use up to 50% of the bandwidth of an interface. The above command
adjusts this to 30% for Autonomous System 10. Percentages over 100% can be used.
If adjustments to the EIGRP metric need to be made, the delay metric (in tens of
microseconds) on an interface should be used:
Router(config)# int s0/0
Router(config-if)# delay 10000
Metric settings must be identical on the connecting interfaces of two routers;
otherwise they will not form a neighbor relationship.
 EIGRP Passive
Interfaces Auto-
Summarization &
Authentication
 Configuring Basic
EIGRP

Routing protocol configuration occurs in Global Configuration mode. On Router A, to

configure EIGRP, we would type:
RouterA(config)# router eigrp 10
RouterA(config-router)# network 172.16.0.0
RouterA(config-router)# network 10.0.0.0
The first command, router eigrp 10, enables the EIGRP process. The “10” indicates the
Autonomous System number that we are using. The Autonomous System number can
range from 1 to 65535.
Only other EIGRP routers in Autonomous System 10 will form neighbor adjacencies and
share updates with this router.
The network statements serve two purposes in EIGRP:
 First, they identify which networks you wish to advertise to other EIGRP routers
(similar to RIP).
 Second, they identify which interfaces on the local router to attempt to form neighbor
relationships out of (similar to OSPF).
Prior to IOS version 12.0(4), the network statements were classful, despite the fact that
EIGRP is a classless routing protocol. For example, the above network 10.0.0.0 command
would advertise the networks of directly- connected interfaces belonging to the 10.0.0.0/8
network and its subnets. It would further attempt to form neighbor relationships out of these
interfaces.
IOS version 12.0(4) and later provided us with more granular control of our network
statements. It introduced a wildcard mask parameter, which allows us to choose the
networks to advertise in a classless fashion:
RouterA(config)# router eigrp 10
RouterA(config-router)# network 172.16.0.0 0.0.255.255
RouterA(config-router)# network 10.1.4.0 0.0.0.255
 EIGRP Passive Interfaces

It is possible to control which router interfaces will participate in the EIGRP process. Just
as with RIP, we can use the passive-interface command.
However, please note that the passive-interface command works differently with EIGRP
than with RIP or IGRP. EIGRP will no longer form neighbor relationships out of a
“passive” interface, thus this command prevents updates from being sent or received out of
this interface:
RouterC(config)# router eigrp 10
RouterC(config-router)# network 10.4.0.0
RouterC(config-router)# network 10.2.0.0
RouterC(config-router)# passive-interface s0
Router C will not form a neighbor adjacency with Router
B. can configure all interfaces to be passive using the passive-interface default
We
command, and then individually use the no passive-interface command on the interfaces
we do want neighbors to be formed on:
RouterC(config)# router eigrp 10
RouterC(config-router)# network 10.4.0.0
RouterC(config-router)# network 10.2.0.0
RouterC(config-router)# passive-interface default
RouterC(config-router)# no passive-interface e0

Always remember, that the passive-interface command will prevent EIGRP (and OSPF)
from forming neighbor relationships out of that interface. No routing updates are passed in
either direction.
EIGRPAuto-Summarization

EIGRP is a classless routing protocol that supports Variable Length Subnet Masks
(VLSMs). The above example would pose no problem for EIGRP.
However, EIGRP will still automatically summarize when crossing major network
boundaries.
For example, when Router A sends an EIGRP update to Router B via Serial0, by default it
will still summarize the 10.1.0.0/16 network to 10.0.0.0/8. This is because the
10.1.0.0/16 and 192.168.123.0/24 networks do not belong to the same major network.
Likewise, the 66.115.33.0/24 network will be summarized to 66.0.0.0/8.
An auto-summary route will be advertised as a normal internal EIGRP route. The best
(lowest) metric from among the summarized routes will be applied to this summary route.
The router that performed the auto-summarization will also add the summary route to its
routing table, with a next hop of the Null0 interface. This is to prevent routing loops.
This auto-summarization can be disabled:
RouterA(config)# router eigrp 10
RouterA(config-router)# no auto-summary

The no auto-summary command will prevent Router A from summarizing the 10.1.0.0/16
and 66.115.33.0/24 networks.
EIGRP Manual Summarization

In some instances, it is necessary to manually summarize networks.

For example, you may not want certain networks to be auto-summarized, but other
specific networks should be summarized. In this instance, summarization can be manually
applied using the following interface configuration command:
RouterA(config)# int s0
RouterA(config-if)# ip summary-address eigrp 10 66.0.0.0 255.0.0.0
Recall that auto-summarization had been previously disabled on Router A to allow the
10.1.0.0/16 network to be advertised correctly. However, this would also mean that the
66.115.33.0/24 network would not be summarized as well.
The ip summary-address command allows us to manually summarize this network.
Notice that we configure this on the interface that will be advertising this network to the
other routers.
The manually-created summary route is not advertised as an internal EIGRP route, but
instead is classified as an EIGRP summary route. An EIGRP summary route has an
Administrative Distance of 5, as opposed to an AD of 90 for internal routes.
As with auto-summarization, the router performing manual summarization will add the
summary route to its routing table, with a next hop of the Null0 interface.
The summary route will only stay in the routing table if a more specific route still
exists.
EIGRPAuthentication

EIGRP supports authentication to secure routing

updates.
The first step is creating a shared authentication key that must be identical on both routers.
This is accomplished in global configuration mode:
RouterA(config)# key chain MYCHAIN
RouterA(config-keychain)# key 1
RouterA(config-keychain-key)# key-string MYPASSWORD
RouterB(config)# key chain MYCHAIN
RouterB(config-keychain)# key 1
RouterB(config-keychain-key)# key-string MYPASSWORD

The first command creates a key chain called MYCHAIN. We must then associate a key to
our keychain. Then we actually configure the shared key using the key-string command.
We then apply our key chain to the interface connecting to the other
router: RouterA(config)# interface s0
RouterA(config-if)# ip authentication key-chain eigrp 10 MYCHAIN
RouterB(config)# interface s0
RouterB(config-if)# ip authentication key-chain eigrp 10 MYCHAIN
If there was another router off of Router B’s Ethernet port, we could create a
separate key chain with a different key-string. Every router on the EIGRP domain
does not need to use the same key chain, only interfaces directly connecting two
(or more) routers.
The final step in configuring authentication is identifying which encryption to
use. Unlike RIP, EIGRP only supports MD5 encryption:
RouterA(config)# interface s0
RouterA(config-if)# ip authentication mode eigrp 10 md5

Please note that configuring authentication for EIGRP is similar to that of RIP,
but there are slight variations in the commands, including the addition of the
EIGRP Autonomous System Number.
 EIGRP Load-
Balancing Stub &
Authentication Lab
EIGRP Load-Balancing
By default, EIGRP will automatically load-balance across equal-metric routes (four by default, six maximum).
EIGRP also supports load-balancing across routes with an unequal metric.
Consider the following example:

Earlier in this section, we established that Router A would choose the route through Router
D as its Feasible Distance to the destination network. The route through Router B
became a Feasible Successor.
By default, EIGRP will not load-balance between these two routes, as their metrics are
different (11 through Router D, 16 through Router B). We must use the variance command
to tell EIGRP to load-balance across these unequal-metric links:
RouterA(config)# router eigrp 10
RouterA(config-router)# variance 2
RouterA(config-router)# maximum-paths 6
The variance command assigns a “multiplier,” in this instance of 2. We multiply this
variance value by the metric of our Feasible Distance (2 x 11
= 22). Thus, any Feasible Successors with a metric within twice that of our
Feasible Distance (i.e. 12 through 22) will now be used for load balancing by EIGRP.
Remember, only Feasible Successors can be used for load balancing, not Possibilities
(such as the route through Router C).
The maximum-paths command adjusts the number of links EIGRP can load- balance across.
 EIGRP Stubs

Consider the above hub-and-spoke environment. If Router C were to fail, Router A (the
hub router) would mark the 10.2.0.0/16 route as Active, and send out Query packets
to the spoke routers for an alternate path.
However, it is obvious that no other route exists to the 10.2.0.0/16 network. Thus, the
querying process is a waste of bandwidth and resources.
To prevent unnecessary querying, “spoke” routers in a hub-and-spoke environment can be
configured as Stub routers. A stub router builds a neighbor adjacency with its hub
router(s), and will inform neighbors of its stub status. The stub router will still build the
full topology table.
However, the stub router will immediately respond to any Query packets with an
Inaccessible message. Neighbors will eventually stop querying the stub router, which helps
EIGRP converge quicker and conserves bandwidth.
Configuration of an EIGRP stub is always performed on the spoke router:
RouterB(config)# router eigrp 10
RouterB(config-router)# eigrp stub connected
The eigrp stub command configures this router as Stub, and supports four possible
parameters:
 Receive-only – router will not share updates with neighbors
 Connected – router will only advertise connected networks
 Static – router will only advertise static networks
 Summary – router will only advertise summary routes
The connected and static parameters will only advertise those networks if they have been
injected into the EIGRP process, either using network statements or using route
redistribution. By default, EIGRP stubs will only send connected and summary routes to
neighbors.
Troubleshooting EIGRP
To view the EIGRP Neighbor Table:
Router# show ip eigrp neighbor
IP-EIGRP neighbors for process 10

H Address Interface Hold Uptime SRTT RTO Q Seq

Type
(sec) (ms) Cnt Num
0 172.16.1.2 S0 13 00:00:53 32 200 0 2
0 172.18.1.2 S2 11 00:00:59 32 200 0 3

To view the EIGRP Topology Table, containing all EIGRP route information:
 Router# show ip eigrp
topology Topology Table for AS(10)/ID(172.19.1.1)
IP-EIGRP

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status,

s - sia Status

P 10.3.0.0/16, 1 successors, FD is 2297856

via 172.16.1.2 (2297856/128256), Serial0
P 172.19.0.0/16, 1 successors, FD is 281600 via Connected,
Serial 1
P 172.18.0.0/16, 1 successors, FD is 128256 via Connected,
Serial
2
P 172.16.0.0/16, 1 successors, FD is 2169856
via Connected, Serial0

To view information on EIGRP traffic sent and received on a

router:
IP-EIGRP Traffic Statistics for process 10 Hellos
Router# show ip eigrp traffic
685/429 sent/received:
Updates sent/received: 4/3
Queries sent/received: 0/0 Replies
0/0 Acks sent/received: 1/2 sent/received:
Input queue high water
mark sent/received: 0/0 1, 0 drops SIA-Queries
SIA-Replies sent/received: 0/0
Troubleshooting EIGRP (continued)
To view the bandwidth, delay, load, reliability and MTU values of an interface:
Router# show interface s0
Serial0 is up, line protocol is up Hardware is HD64570
Internet address is 172.16.1.1/16
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255,
rxload 1/255

<irrelevant output removed>

To view information specific to the EIGRP protocol:

Router# show ip protocols
Routing Protocol is "eigrp 10"
Outgoing update filter list for all interfaces is not set Incoming update filter list
for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0,
K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1 Redistributing: eigrp 10
Automatic network summarization is not in effect
Maximum path: 4 Routing for Networks:
172.16.0.0
172.18.0.0
172.19.0.0
Routing Information Sources:
 Gateway Distance Last Update
(this router) 90 00:26:11
172.16.1.2 90 00:23:49
Distance: internal 90 external 170

This command provides us with information on EIGRP timers, EIGRP metrics, summarization, and the specific
networks RIP is advertising.

Troubleshooting EIGRP (continued)

To view the IP routing table:
Router# show ip route
Gateway of last resort is not set

C 172.16.0.0 is directly connected, Serial0

172.19.0.0 is directly connected, Serial1
C 10.3.0.0 [90/2297856] via 172.16.1.2, 00:00:15, Serial0

D
To view a specific route within the IP routing
table:
Router# show ip route 10.3.0.0
Routing entry for 10.3.0.0/16
Known via “eigrp 10”, distance 90, metric 2297856 type internal
Last update from 172.16.1.2 on Serial 0, 00:00:15 ago

To debug EIGRP in realtime:

Router# debug eigrp neighbors
Router# debug eigrp packet
Router# debug eigrp route
Router# debug eigrp summary
 - Border Gateway
Protocol -
3.2.c Configure and verify eBGP between directly connected neighbors
(best path selection algorithm and neighbor relationships)
Border Gateway Protocol (BGP)
BGP is a standardized exterior gateway protocol (EGP), as opposed to RIP, OSPF, and
EIGRP which are interior gateway protocols (IGP’s). BGP Version 4 (BGPv4) is the
current standard deployment.
BGP is considered a “Path Vector” routing protocol. BGP was not built to route within an
Autonomous System (AS), but rather to route between AS’s. BGP maintains a separate
routing table based on shortest AS Path and various other attributes, as opposed to IGP
metrics like distance or cost.
BGP is the routing protocol of choice on the Internet. Essentially, the Internet is a
collection of interconnected Autonomous Systems.
BGP Autonomous Systems are assigned an Autonomous System Number (ASN), which is
a 16-bit number ranging from 1 – 65535. A specific subset of this range, 64512 – 65535,
has been reserved for private (or internal) use.
BGP utilizes TCP for reliable transfer of its packets, on port 179.
When to Use BGP
Contrary to popular opinion, BGP is not a necessity when multiple connections to the
Internet are required. Fault tolerance or redundancy of outbound traffic can easily be
handled by an IGP, such as OSPF or EIGRP.
BGP is also completely unnecessary if there is only one connection to an external AS
(such as the Internet). There are over 100,000 routes on the Internet, and interior routers
should not be needlessly burdened.
BGP should be used under the following circumstances:
 Multiple connections exist to external AS’s (such as the Internet) via different
providers.
 Multiple connections exist to external AS’s through the same provider, but
connect via routing policy.
 The existing routing equipment can handle the additional demands.
BGP’s true benefit is in controlling how traffic enters the local AS, rather than how
traffic exits it.
BGP Peers (Neighbors)
For BGP to function, BGP routers (called speakers) must form neighbor relationships
(called peers).
There are two types of BGP neighbor relationships:
 iBGP Peers – BGP neighbors within the same autonomous system.
 eBGP Peers – BGP neighbors connecting separate autonomous systems.
Note: Do not confuse an IGP, such as OSPF, with iBGP!
In the above figure, RouterB and RouterC in AS 200 would form an iBGP peer
relationship. RouterA in AS 100 and RouterB in AS 200 would form an eBGP
peering.
Once BGP peers form a neighbor relationship, they share their full routing table.
Afterwards, only changes to the routing table are forwarded to peers.
By default, BGP assumes that eBGP peers are a maximum of one hop away. This
restriction can be bypassed using the ebgp-multihop option with the neighbor command
(demonstrated later in this guide).
iBGP peers do not have a hop restriction, and are dependent on the underlying IGP of
the AS to connect peers together. By default, all iBGP peers must be fully meshed
within the Autonomous System.
A Cisco router running BGP can belong to only one AS. The IOS will only allow one
BGP
process to run on a router.
The Administrative Distance for routes learned outside the Autonomous System (eBGP
routes) is 20, while the AD for iBGP and locally-originated routes is 200.
BGP Peers Messages
BGP forms its peer relationships through a series of messages. First, an OPEN message
is sent between peers to initiate the session. The OPEN message contains several
parameters:
 BGP Version – must be the same between BGP peers
 Local AS Number
 BGP Router ID
KEEPALIVE messages are sent periodically (every 60 seconds by default) to ensure that
the remote peer is still available. If a router does not receive a KEEPALIVE from a peer for
a Hold-time period (by default, 180 seconds), the router declares that peer dead.
UPDATE messages are used to exchange routes between peers.
Finally, NOTIFICATION messages are sent when there is a fatal error condition. If a
NOTIFICATION message is sent, the BGP peer session is torn down and reset.
As a BGP peer session is forming, it will pass through several states. This process is
known as the BGP Finite-State Machine (FSM):
 Idle – the initial BGP state
 Connect - BGP waits for a TCP connection with the remote peer. If
successful, an OPEN message is sent. If unsuccessful, the session is placed in an
Active state.
 Active – BGP attempts to initiate a TCP connection with the remote peer. If
successful, an OPEN message is sent. If unsuccessful, BGP will wait for a
ConnectRetry timer to expire, and place the session back in a Connect State.
 OpenSent – BGP has both established the TCP connection and sent an OPEN
Message, and is awaiting a reply OPEN Message. Once it receives a reply OPEN
Message, the BGP peer will send a KEEPALIVE message.
 OpenConfirm – BGP listens for a reply KEEPALIVE message.
 Established – the BGP peer session is fully established. UPDATE
messages containing routing information will now be sent.
If a peer session is stuck in an Active state, potential problems can include: no IP
connectivity (no route to host), an incorrect neighbor statement, or an access-list filtering
TCP port 179.
 Configuring BGP
Neighbors

The first step in configuring BGP is to enable the BGP process, and specify the router’s
Autonomous System (AS):
RouterB(config)# router bgp 100

RouterB is now a member of AS 100. Next, neighbor relationships must be established.

To configure a neighbor relationship with a router in the same AS (iBGP Peer):
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 10.1.1.1 remote-as 100
To configure a neighbor relationship with a router in a separate AS (eBGP Peer):
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 remote-as 900

Notice that the syntax is the same, and that the remote-as argument is always used,
regardless if the peering is iBGP or eBGP.
For stability purposes, the source interface used to generate updates to a particular
neighbor can be specified:
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 update-source lo0
RouterC must then point to RouterB’s loopback (assume the address is 1.1.1.1/24)
in its
neighbor statement:
RouterC(config)# router bgp 900
RouterC(config-router)# neighbor 1.1.1.1 remote-as 100
RouterC must have a route to RouterB’s loopback in its routing table.
Remember though: by default, BGP assumes that external peers are exactly one hop away.
Using the loopback as a source interface puts RouterB two hops away from RouterC. Thus,
the ebgp-multihop feature must be enabled:
RouterC(config)# router bgp 900
RouterC(config-router)# neighbor 1.1.1.1 ebgp-multihop 2
The 2 indicates the number of hops to the eBGP peer. If left blank, the default is 255.
To authenticate updates between two BGP peers:
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 password CISCO
Configuring BGP Timers
To globally adjust the Keepalive and Hold-time timers for all neighbors:
RouterB(config)# router bgp 100
RouterB(config-router)# timers bgp 30 90

The above command sets the Keepalive timer to 30 seconds, and the Hold- time timer to 90
seconds. If the configured Hold-time timers between two peers are different, the peer session
will still be established, and the smallest timer value will be used.
To adjust the timers for a specific neighbor (which overrides the global timer configuration):
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 timers 30 90
Viewing BGP Neighbors &
BGP Synchronization
Viewing BGP Neighbors
To view the status o f all BGP neighbors:
RouterB# show ip bgp neighbors

BGP neighbor is 172.16.1.2, remote AS 900, external l ink Index 1,

Offset 0, 0x2
Mask reconfigura ion allowed
Inbound soft t ter ID 172.16.1.2
BGP version 4 , remote table version = 27, up 00:03:45 Last read
BGP state = E rou for 0, keepalive
00:00:19, hol stablished, interval is 60
seconds d time is ds Received 25
Minimum time 18 rtisement runs is 30 secon
messages, 0 n , 0 in queue
Sent 20 messa between adve ications, 0 in queue
Inbound path gured onnections
Route map for otifications vertisements is testing C
established 2 ges, 0 t bytes: 0 Local host:
Connection notif /O status: 1, unread inpu
state policy confi 2
172.16.1.1, incoming ad reign port: 179
Loca ; dropped 1 0
Foreign host: 17 is ESTAB, I
l port: 1234 Next
2.16.1.2, Fo
Enqueued packets for retrans mit: 0, input: 0, saved:
Event Timers (current time is 0x530C294):
Timer Wakeups
Starts
To view the status of a specific BGP neighbor:
RouterB# show ip bgp neighbors 172.16.1.2
BGP Synchronization

Consider the above example. AS 200 is serving as a transit between AS 100 and AS
300. BGP follows a synchronization rule that states that all routers in a transit AS,
including non-BGP routers, must learn of a route before BGP can advertise it to an
external peer.
Confused?
Consider the above example again. If RouterA advertises a BGP route to RouterB (an
eBGP peer) for the 10.5.0.0/16 network, that same BGP route will eventually be
forwarded to RouterD (an iBGP peer).
However, a blackhole would exist if RouterD then advertised that update to RouterE, as
RouterC would not have the 10.5.0.0/16 network in its routing table. If RouterE attempts to
reach the 10.5.0.0 network, RouterC will drop the packet.
BGP’s synchronization rule will force RouterD to wait until RouterC learns the 10.5.0.0/16
route, before forwarding that route to RouterE. How will RouterD know when RouterC
learns the route? Simple! When it receives an update from RouterC via an IGP (such as
OSPF), containing that route.
BGP synchronization can be disabled under two circumstances:
 The local AS is not a transit between two other AS’s
 All routers in the transit AS run iBGP, and are fully meshed.
To disable BGP synchronization:
RouterD(config)# router bgp 200
RouterD(config-router)# no synchronization
As of IOS 12.2(8)T, synchronization is disabled by default.
 10.1.1.0/24

10.1.2.0/24

10.1.4.0/24
Originating Prefixes in
BGP & The BGP
Routing Table
Originating Prefixes in BGP
There are three ways to originate a prefix (in other words, advertise a network) into
BGP:
 By using network statements
 By using aggregate-address statements
 By redistributing an IGP into BGP
Using the network statement informs BGP which networks to advertise to eBGP peers, not
which interfaces to run BGP on. The network command can be used to inject any network
from the local AS into BGP, include dynamic routes learned from an IGP, and not just the
routes directly connected to the router.
However, the route must be in the routing table before BGP will advertise the network to
an eBGP peer. This is a fundamental BGP rule.
Consider the above example. RouterB may inject the 10.5.0.0/16 network into BGP using
the network command. However, unless that route is in the local routing table (in this case,
via an IGP), RouterB will not advertise the route to RouterC.
Furthermore, the network statement must match the route exactly as it is in the routing
table:
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 remote-as 900
RouterB(config-router)# network 10.5.0.0 mask 255.255.0.0
The above configuration would match the route perfectly, while the following
configuration would not:
RouterB(config-router)# network 10.5.0.0 mask 255.255.255.0

If no mask is specified, a classful mask will be assumed.

Originating Prefixes in BGP
There are three ways to originate a prefix (in other words, advertise a network) into
BGP:
 By using network statements
 By using aggregate-address statements (explained later in this guide)
 By redistributing an IGP into BGP
Using the network statement informs BGP which networks to advertise to eBGP peers, not
which interfaces to run BGP on. The network command can be used to inject any network
from the local AS into BGP, include dynamic routes learned from an IGP, and not just the
routes directly connected to the router.
However, the route must be in the routing table before BGP will advertise the network to
an eBGP peer. This is a fundamental BGP rule.
Consider the above example. RouterB may inject the 10.5.0.0/16 network into BGP using
the network command. However, unless that route is in the local routing table (in this case,
via an IGP), RouterB will not advertise the route to RouterC.
Furthermore, the network statement must match the route exactly as it is in the routing
table:
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 remote-as 900
RouterB(config-router)# network 10.5.0.0 mask 255.255.0.0
The above configuration would match the route perfectly, while the following
configuration would not:
RouterB(config-router)# network 10.5.0.0 mask 255.255.255.0

If no mask is specified, a classful mask will be assumed.

The BGP Routing Table
Recall that BGP maintains its own separate routing table. This table contains a list of
routes that can be advertised to BGP peers.

To view the BGP routing table on RouterB:

RouterB# show ip bgp
BGP table version is 426532, local router ID is 2.2.2.2
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.5.0.0 0.0.0.0 0 0 32768 i
The route has been injected into BGP using the network command. The Next Hop of
0.0.0.0 indicates that the route was locally originated into BGP. The Path is empty, as the
route originated in the Autonomous Systems.
Notice the Status Codes of “*>”. The * indicates that this route is valid (i.e. in the
routing table). The > indicates that this is the best route to the destination.
BGP will never advertise a route to an eBGP peer unless it is both valid and the
best route
to that destination. BGP routes that are both valid and best will also added the IP routing
table as well.
To view the BGP routing table on RouterC:

RouterC# show ip bgp

Network Next Hop Metric LocPrf Weight Path
*> 10.5.0.0 172.16.1.1 0 100 0 100 i

Notice that AS 100 has been added to the path, and that the Next Hop is now
RouterB.
BGP Route-Reflectors &
BGP Confederations &
BGP Peer-Groups
BGP Route-Reflectors
Recall that BGP requires all iBGP peers to be fully meshed. Route- Reflectors allow us
to bypass this restriction. Fewer neighbor connections will result in less bandwidth and
CPU usage.
Route-reflector clients form neighbor adjacencies with the route-reflector server. BGP
updates will flow from the server to the clients, without the clients having to interact
with each other.
Consider the above example. In AS 100, there are three BGP speakers. Normally, these
iBGP peers must be fully-meshed. For example, RouterB would need a neighbor statement
for both RouterA and RouterD.
As an alternative, RouterA can be configured as a route-reflector server. Both RouterB
and RouterD would only need to peer with RouterA.
All route-reflector specific configuration takes place on the route reflector server:
RouterA(config)# router bgp 100
RouterA(config-router)# neighbor 10.2.1.2 remote-as 100
RouterA(config-router)# neighbor 10.2.1.2 route-reflector-client
RouterA(config-router)# neighbor 10.1.1.2 remote-as 100
RouterA(config-router)# neighbor 10.1.1.2 route-reflector-client
Route-reflectors are Cisco’s recommended method of alleviating the
iBGP full-mesh
requirement.
BGP Confederations

Confederations are an alternative method to alleviate the requirement that all iBGP
routers be fully meshed. Confederations are essentially AS’s within an AS, and are
sometimes referred to as sub-AS’s.
In the above example, RouterA belongs to AS 777 and RouterB belongs to AS 888.
Both of those AS’s belong to a parent AS of 300. RouterA and RouterB will form an
eBGP peer session.
Configuration is simple:
RouterB(config)# router bgp 888
RouterB(config-router)# bgp confederation identifier 300
RouterB(config-router)# bgp confederation peer 777
RouterB(config-router)# neighbor 10.1.1.1 remote-as 777
RouterB(config-router)# neighbor 172.16.1.2 remote-as 500
Notice that the sub-AS (777) is used in the router bgp statement. Additionally, the
parent AS must be specified using a bgp confederation identifier statement.
Finally, any confederation peers must be identified.
RouterC will be unaware of RouterB’s confederation status. Thus, RouterC’s
neighbor statement will point to AS 300, and not AS 888:
RouterC(config)# router bgp 500
RouterC(config-router)# neighbor 172.16.1.1 remote-as 300

(Reference: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm#wp6834)
BGP Peer-Groups
Peer-groups simplify configuration of groups of neighbors, assuming those neighbors
share identical settings. Additionally, peer-groups conserve processor/memory resources by
sending updates to all peer-group members simultaneously, as opposed to sending
individual updates to each neighbor.
All neighbor parameters are applied to the peer-group itself. Configuration is simple:
Router(config)# router bgp 200
Router(config-router)# neighbor MYPEERGROUP peer-group
Router(config-router)# neighbor MYPEERGROUP remote-as 200
Router(config-router)# neighbor MYPEERGROUP update-source lo0
Router(config-router)# neighbor MYPEERGROUP route-reflector-client

The above configuration creates a peer-group named MYPEERGROUP, and applies the
desired settings. Next, we must “assign” the appropriate neighbors to the peer-group:
 Router(config-router)# neighbor 10.10.1.1 peer-group MYPEERGROUP
Router(config-router)# neighbor 10.10.2.2 peer-group MYPEERGROUP
Router(config-router)# neighbor 10.10.3.3 peer-group MYPEERGROUP
The above neighbors now inherit the settings of the peer-group named
MYPEERGROUP.
All “members” of a peer-group must exclusively be internal (iBGP) peers or
external (eBGP) peers. A mix of internal and external peers is not allowed in
a peer-group.
Outbound route filtering (via a distribution-list, route-map, etc.) must be
identical on all members of a peer-group. Inbound route filtering can still be
applied on a per-neighbor basis.
 10.1.1.0/24

10.1.2.0/24

10.1.4.0/24
BGP “Best Path”
Determination
BGP “Best Path” Determination
If BGP contains multiple routes to the same destination, it compares the routes in pairs, starting with
the newest entries (listed higher in the routing table), and working towards the oldest entries (listed
lower in the table).
BGP determines the best path by successively comparing the attributes of each “route pair.” The
attributes are compared in a specific order:
 Weight – Which route has the highest weight?
 Local Preference – Which route has the highest local preference?
 Locally Originated – Did the local router originate this route? In other words, is the next hop
to the destination 0.0.0.0?
 AS-Path – Which route has the shortest AS-Path?
 Origin Code – Where did the route originate? The following origin codes are listed in order of
preference:
o IGP (originated from an interior gateway protocol)
o EGP (originated from an exterior gateway protocol)
o ? (Unknown origin)
  MED – Which path has the lowest MED?
 BGP Route Type – Is this an eBGP or iBGP route? (eBGP routes are preferred)
 Age – Which route is the oldest? (oldest is preferred)
 Router ID – Which route originated from the router with the lowest BGP router ID?
 Peer IP Address – Which route originated from the router with the lowest IP?
When applying attributes, Weight and Local Preference are applied to
inbound routes, dictating the best outbound path.
AS-Path and MED are applied to outbound routes, dictating the best inbound
path.

(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml)
 Weigh
t

The Weight attribute is applied to inbound routes, dictating the best outbound path.
It is a Cisco-proprietary attribute, and is only locally significant (and thus, is never
passed on to BGP neighbors).
The weight value can range from 0 – 65535, and the highest weight is preferred. By
default, a route originated on the local router will be assigned a weight of 32768. All other
routes will be assigned a weight of 0, by default.
A weight value can be specified for all routes advertised from a specific neighbor:
RouterA(config)# router bgp 100
RouterA(config)# neighbor 10.1.1.2 weight 200
Otherwise, a weight value can be specified for specific routes from a particular
neighbor. First, the prefixes in question must be identified:
RouterA(config)# ip prefix-list MYLIST 192.168.1.0/24
Then, a route-map is used to apply the appropriate weight:
RouterA(config)# route-map WEIGHT permit 10
RouterA(config-route-map)# match ip address prefix-list MYLIST
RouterA(config-route-map)# set weight 200
RouterA(config-route-map)# route-map WEIGHT permit 20
Finally, the route-map is applied to the preferred neighbor:
RouterA(config)# router bgp 100
RouterA(config)# neighbor 10.1.1.2 route-map WEIGHT in
Local Preference

The Local Preference attribute is applied to inbound external routes, dictating the best
outbound path. Unlike the Weight attribute, Local Preference is passed on to iBGP peers
when sending updates. Local Preference informs iBGP routers how to exit the AS, if
multiple paths exist.
Local Preference is a 32-bit number, and can range from 0 to 4294967295. The highest
Local Preference is preferred, and the default preference is 100.
The Local Preference value can be specified for all inbound external routes, on a global
basis for BGP:
RouterB(config)# router bgp 100
RouterB(config-router)# bgp default local-preference 200
RouterD(config)# router bgp 100
RouterD(config-router)# bgp default local-preference 300
Both RouterB and RouterD will include the Local Preference attribute in updates to iBGP
neighbors. Thus, RouterA (and RouterB) will now prefer the route through RouterD to
reach any destination outside the local AS.
Local Preference can be applied on a per-route basis:
RouterD(config)# ip prefix-list MYLIST 192.168.1.0/24
RouterD(config)# route-map PREFERENCE permit
10
RouterD(config-route-map)# match ip address prefix-list MYLIST
RouterD(config-route-map)# set local-preference 300
RouterD(config)# router bgp 10
RouterD(config)# neighbor 172.17.1.2 route-map PREFERENCE
(Reference: http://www.cisco.com/warp/public/459/bgp-toc.html#localpref)
in
Lab
AS-Path Prepend

The AS-Path attribute is applied to outbound routes, dictating the best inbound path. Two
things can be accomplished with the AS-Path attribute, prepend or filter.
To prepend to (or add to) the existing AS-Path results in a longer AS-Path, which makes
the
route less desirable for inbound traffic:
 RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map ASPREPEND permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set as-path prepend 200 200
RouterB(config-route-map)# route-map ASPREPEND permit 20
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 route-map ASPREPEND out

The artificial AS-Path information is not added to a route until it is advertised to

an eBGP peer. RouterC’s BGP routing table will now look as follows:
RouterC# show ip bgp
Network Next Hop Metric LocPrf Weight Path
* 10.5.0.0 172.16.1.1 0 100 0 100 200 200 i
*> 10.5.0.0 172.17.1.1 0 100 0 100 i

Notice the inflated AS-Path through RouterB. RouterC will prefer the
path through RouterD to reach the 10.5.0.0/16 network.
 MED

The MED (MultiExit Discriminator) attribute is applied to outbound routes, dictating the
best inbound path into the AS (assuming multiple paths exist). The MED is identified as
the BGP metric when viewing the BGP routing table. A lower metric is preferred, and the
default MED value is 0.
In the above example, there are two entry points into AS 100. To force AS 900 to prefer
that path through RouterD to reach the 10.5.0.0/16 network, the set metric command can
be used with a route-map:
 RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map SETMED permit 10
RouterB(config-route-map)# ip address 5
RouterB(config-route-map)# set metric 200
match
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 route-map SETMED out
RouterC will now have two entries for the 10.5.0.0/16 route:
RouterC# show ip bgp
Network Next Hop Metric LocPrf Weight Path
* 10.5.0.0 172.16.1.1 200 100 0 100 i
*> 10.5.0.0 172.17.1.1 0 100 0 100 i

Notice that the route from RouterB has a higher metric, and thus is less preferred. Note specifically
the lack of a > on the route with a higher metric.
The MED value is exchanged from one AS to another, but will never be advertised further than
that. Thus, the MED value is passed from AS 100 to all BGP routers in AS 900, but the metric will
be reset to 0 if the route is advertised beyond AS 900.
The MED metric on routes sent to eBGP neighbors can be dynamically set to the actual
metric of an IGP (such as OSPF). This is accomplished using the set metric-type internal
command with a route-map:
RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map MED_INTERNAL permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set metric-type internal
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.17.1.2 route-map
MED_INTERNAL out

If the 10.5.0.0/16 network originated in OSPF, the link-state cost metric for that route will
be applied as the MED metric.
Communities
BGP allows routes to be placed (or tagged) into certain Communities. BGP routers can
make route policy decisions based on a route’s community membership.
BGP communities can be assigned using one of three 32-bit formats:
 Decimal (1000000)
 Hexadecimal (0x1A2B3C)
 AA:NN (100:20)
The AA:NN format specifies a 16-bit AS number (the AA), and a 16-bit generic
community identifier (NN).
By default, the decimal format for communities will be displayed when viewing
a
route. To force the router to display the AA:NN format:
RouterA(config)# ip bgp-community new-format
Additionally, there are four well-known communities that can be referenced by name:
 No-export – prevents the route from being advertised outside the local AS to
eBGP peers.
 No-advertise – prevents the route from being advertised to either internal or
external peers.
 Internet – allows the route to be advertised outside the local AS.
 Local-AS – prevents the route from being advertised outside the local AS to
either eBGP or confederate peers.
To set the community for a specific route, using a route-
map:RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map COMMUNITY permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set community no-export
RouterB(config)# route-map COMMUNITY permit 20
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 send-community
RouterB(config-router)# neighbor 172.16.1.2 route-map COMMUNITY out

The community attribute will not be advertised to a neighbor unless the send-
community parameter is applied to the neighbor command, regardless if a
community value is applied using a route-map.
The above configuration will place the 10.5.0.0/16 route into the no-export community
once it is advertised into AS 900. RouterC will advertise this network to all iBGP peers, but
the community attribute will prevent RouterC (and all iBGP peers) from advertising the
route outside of AS 900.
By default, the set community route-map command will overwrite any existing
community parameters for a route. To instead append additional community values, the
additive parameter must be specified:
RouterB(config)# route-map COMMUNITY permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set community no-export additive
RouterB(config)# route-map COMMUNITY permit 20
 Origin

The Origin attribute identifies the originating source of the route. The origin codes are as
follows (listed in order of preference for route selection):
 i (IGP) – Originated from an interior gateway protocol, such as OSPF. This usually
indicates the route was injected into BGP via the network command under the BGP
process. An origin code of “i” is most preferred.
 e (EGP) – Originated from an external gateway protocol.
AS-Path Filtering

Additionally, routes can be filtered based on AS-Path values, using an as- path access-list. This requires the use
of
regular expressions:
The following examples illustrate the use of regular expressions:
To configure RouterF to only accept routes that originated from
AS100:
RouterF(config)# ip as-path access-list 15 permit _100$
RouterF(config)# route-map ASFILTER permit 10
RouterF(config-route-map)# match as-path 15
RouterF(config)# router bgp 50
RouterF(config-router)# neighbor 10.5.1.1 route-map ASFILTER in
To view what BGP routing entries the AS-Path access-list will
match:
RouterF# show ip bgp regexp _100$
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a92.shtml)
  ? (incomplete) - Unknown origin. This usually indicates the route was redistributed
into BGP (from either connected, static, or IGP routes). An origin code of “?” is
the least preferred.

When viewing the BGP routing table, the origin code is listed at the end of each line in
the table:
RouterB# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 10.5.0.0 10.1.1.1 0 0 0 i
*> 192.168.1.0 172.16.1.2 0 100 0 900 ?

The i at the end of the first routing entry indicates the 10.5.0.0 network was originated via an IGP, probably
with the BGP network command. The 192.168.1.0 network was most likely redistributed into BGP in AS 900,
as evidenced by the ? at the end of that routing entry.
BGP Summarization
Routes that are redistributed into BGP are automatically summarized. To disable auto-
summary:
Router(config)# router bgp 100
Router(config-router)# no auto-summary
To manually create a summary address for the following group of networks:
 172.16.0.0/24  172.16.2.0/24
 172.16.1.0/24  172.16.3.0/24

The aggregate-address command must be used:

Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0
BGP’s default configuration is to send both the summary (or aggregated) address and
the more specific individual routes. To only send the summary route:
 Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0 summary- only
To suppress (or summarize) only specific routes, instead of all routes, a
route- map must be used:
Router(config)# access-list 5 permit 172.16.0.0 0.0.0.255
Router(config)# access-list 5 permit 172.16.1.0 0.0.0.255
Router(config)# route-map SUPPRESS permit 10
Router(config-route-map)# match ip address 5
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0 summary- only
suppress-map SUPPRESS
The access-list details the routes that should be suppressed. To allow
the summarized routes to retain their AS-Path information:
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0
summary- only
suppress-map SUPPRESS as-set
BGP Route Dampening
Route dampening “suppresses” routes that are flapping, minimizing unnecessary
convergence and updates. If a route flaps (goes up and down), it is assigned a penalty
(default is 1000). All routes start with a penalty of 0, and the local router maintains a
history of routes that have flapped.
Once the penalty reaches a specific threshold, the route is suppressed. When a route is
suppressed, it is neither advertised nor used locally on the router.
First, the routes to be “observed” must be identified using an access-list or prefix-list:
Router(config)# ip prefix-list MYLIST seq 10 permit 10.1.0.0/16
Router(config)# ip prefix-list MYLIST seq 20 permit 10.2.0.0/16
Next, dampening values must be configured using a route-map:
Router(config)# route-map MYMAP permit 10
Router(config-route-map)# match ip address prefix-list MYLIST
Router(config-route-map)# set dampening 15 750 2000 60
The above values for the set dampening command represent the
defaults.
The 15 (measured in minutes) indicates the half-life timer. If a route is assigned a
penalty, half of the penalty will decay after this timer expires.
The 750 (arbitrary penalty measurement) indicates the bottom threshold. Once a
penalized route falls below this threshold, it will no longer be suppressed.
The 2000 (arbitrary penalty measurement) indicates the top threshold. If a route
flaps to
the point that its penalty exceeds this threshold, it is suppressed.
The 60 (measured in minutes) indicates the maximum amount of time a route can be
suppressed.
Finally, route-dampening must be enabled under the BGP process:
Router(config)# router bgp 100
Router(config-router)# bgp dampening route-map MYMAP

(Reference: http://www.cisco.com/warp/public/459/bgp-rec-routing.html)
BGP Next-Hop-
Self

Consider the above diagram. If RouterC sends the 192.168.1.0/24 route to

its eBGP peer RouterB, the Next Hop for that route will be through
RouterC:
RouterB# show ip bgp

A serious problem arises when RouterB sends this route to its iBGP
peers
(RouterA and RouterD). The Next Hop value is not changed:
RouterA# show ip bgp
 Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 172.16.1.2 0 100 0 900 i

Notice the lack of >, indicating this is no longer the best route to the destination. This is because RouterA has
no route to the next hop address.
There are two workarounds. Either the 172.16.0.0/16 network must be added to RouterA’s and RouterD’s routing tables,
or the Next-Hop field must be adjusted to identify RouterB as the next hop.
The configuration is simple, and is completed on RouterB:
RouterB(config)# router bgp 200
RouterB(config-router)# neighbor 10.1.1.1 next-hop-self
RouterB(config-router)# neighbor 10.2.1.2 next-hop-self

RouterB now advertises itself as the next hop for all eBGP routes it learns:
RouterA# show ip bgp

Network Next Hop Metric LocPrf Weight Path

*> 192.168.1.0 10.1.1.2 0 100 0 900 i
BGP Backdoor
Recall that an external BGP route has an Administrative Distance (AD)
of
20, which
Under is less
certain than the default
circumstances, this AD
mayofresult
IGP’s,
in such as OSPFrouting.
sub-optimal or EIGRP.
If both an IGP route
and eBGP route exist to the same network, and the IGP route should be preferred, there
are two workarounds:
 Globally change BGP’s default Administrative Distance values.
 Use the BGP network backdoor command.
Cisco does not recommend changing BGP’s default AD values. If necessary, however, the
distance bgp will adjust the AD for external, internal, and locally-originated BGP routes,
respectively:
Router(config)# router bgp 100
Router(config-router)# distance bgp 150 210 210
The preferred workaround is to use the BGP network backdoor command, which adjusts
the AD for a specific eBGP route (by default, from 20 to 200), resulting in the IGP route
being preferred:
Router(config)# router bgp 100
Router(config-router)# network 10.5.0.0 mask 255.255.0.0 backdoor
Misc. BGP Commands
To restrict the number of routes a BGP router can receive from its neighbor:
Router(config)# router bgp 200
Router(config-router)# neighbor 10.1.1.1 maximum-prefix 10000

To immediately reset an eBGP session if a link connecting two peers goes down, the bgp
fast-external-fallover feature must be enabled. To enable this feature globally:
Router(config)# router bgp 200
Router(config-router)# bgp fast-external-fallover

To enable this feature on a per-interface basis:

Router(config)# int serial0/0
Router(config-if)# ip bgp fast-external-fallover permit
To reset the BGP session between all neighbors:
Router# clear ip bgp *

To force a resend of routing updates, without resetting any BGP sessions between
neighbors:
Router# clear ip bgp * soft

To view a summary of all BGP connections, including the total number of BGP routes
and a concise list of neighbors:
Router# show ip bgp summary
3.4.a Describe Network Time Protocol (NTP)
Network Time Protocol (NTP)
Time and date information can be configured locally on both Cisco routers and switches.
However, in environments with a large amount of equipment, this can become
unmanageable. As a result, the “time” will be inconsistent throughout the network. This can
lead to various inaccuracies, such as the timestamps in syslog messages.
Network Time Protocol (NTP) provides a mechanism to synchronize time throughout the
network. An NTP device will form an association with NTP devices closer to the time
source. NTP devices use a special measurement, called a stratum, to determine how far
they are away from the time source.
For example, a device with a stratum of 1 is directly connected to the time source. A
device
with a stratum of 2 is one device (or “hop”) away from the time source.
NTP Client/Server – The
can be configured oneNTP client
of two ways:is configured to always get its time information
from the NTP server. The server will never get its time from the client.
 Peer-to-peer – Peered NTP devices can get their time from each other,
depending on who is closest to the time source (i.e., lowest stratum).
NTP associations can be secured using encrypted authentication.
 Configuring Basic
NTP

Consider the above example. Two time sources exist off of RouterD; to use those
time sources as NTP servers:
RouterD(config)# clock timezone CST -6
RouterD(config)# clock summer-time CDT recurring
RouterD(config)# ntp server 10.1.1.1
RouterD(config)# ntp server 10.5.1.1
Router D’s time will now be synchronized with the external time
sources. Specifying more than one NTP server provides redundancy.
To prefer one time source over another:
RouterD(config)# ntp server 10.1.1.1 prefer
RouterD(config)# ntp server 10.5.1.1
NTP can be configured as a tiered client/server model. For example, instead of
pointing RouterC to the external time sources, RouterC can utilize RouterD as its
NTP Server instead:
RouterC(config)# clock timezone CST -6
RouterC(config)# clock summer-time CDT recurring
RouterC(config)# ntp server 50.1.1.1
RouterA and RouterB can be pointed to RouterC as well:
RouterA(config)# clock timezone CST -6
RouterA(config)# clock summer-time CDT recurring
RouterA(config)# ntp server 69.1.1.1
 Configuring Basic NTP (continued)

Now consider the above example. No external time sources exist; instead, RouterD can be
designated as the authoritative time source of this network. This is not an optimal solution,
and should only be used when there is no access to external (Internet) time sources.
First, accurate date and time information must be configured on
RouterD:RouterD(config)# clock timezone CST -
RouterD(config)#
6 clock summer-time CDT recurring

RouterD# clock set 04:33:01 June 27 2020

Next, RouterD must be configured as the NTP master time source:
RouterD(config)# ntp master 10
The 10 in the ntp master command indicates the stratum. Best practice is to set
this to a high number, so that it will become less preferred if an external time
source becomes available.
Now consider RouterA and RouterB. Both routers should point to RouterC as their
NTP Server. However, Router A will lose its direct connection to Router C if its
Ethernet interface fails. RouterB could similarly lose its direct connection.
RouterA and RouterB can be configured as “peers,” so that one can synchronize the other
if either lose their direct connection to the NTP server:
RouterA(config)# ntp peer 12.1.1.2
RouterB(config)# ntp peer 12.1.1.1
 NTPAuthentication

To ensure that erroneous time information is not propagated throughout the network, NTP
authentication can be configured.
Assume that RouterD is still configured as the NTP master. To configure authentication on
RouterD:
RouterD(config)# ntp master 10
RouterD(config)# ntp authentication-key 1 md5 MYPASSWORD
RouterD is the NTP server for RouterC. To secure this association, the following must
be configured on RouterC:
 RouterC(config)# ntp authenticate
RouterC(config)# ntp authentication-key 1 md5 MYPASSWORD
RouterC(config)# ntp trusted-key 1
RouterC(config)# ntp server 50.1.1.1 key 1
Usually in client/server environments, the server authenticates the
client. However, NTP clients authenticate the NTP server.
The authentication-key must be the same on both NTP devices.
Misc. NTP Commands
You may have noticed that, in client/server NTP environments, no configuration is
necessary on the NTP server to “service” clients. Thus, any device can point to a Cisco
router as its NTP server.
If this is undesirable, NTP can be disabled on a specific interface:
Router(config)# interface fa0/1
Router(config-if)# ntp disable
To restrict the number of client “associations” to an NTP server:
Router(config)# ntp max-associations 10
To provide stability to the NTP network, the source interface of NTP packets can be
specified. It is usually preferable to use a loopback interface as a source, as loopbacks
should never be in a down state:
Router(config)# ntp source loopback0
Verifying NTP
To view the current date and time:
Router# show clock
04:30:03.871 CDT Mon Jun 27
2020

To view the status of NTP

synchronization:
Router# show ntp status
Clock is synchronized, stratum 5, reference is
10.1.1.1
nominal freq is 250.0000 Hz, actual freq is
249.9941 Hz, precision is 2**18
reference time is
BF454660.7CCA9683 (04:30:03.871 CDT Mon
address Jun 27 2019) clock offset is 3.1328
ref clock st when poll reach delay offset disp
*~10.1.1.1 133.4.22.22 3 3 64 368 66.2 3.44 0.3
msec, root delay is
141.22 msec
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
root dispersion is 29.39 msec, peer dispersion is
1.22 msec
3.4.b Configure and verify NAT/PAT
NAT (Network Address Translation)
The rapid growth of the Internet resulted in a shortage of available IPv4 addresses. In
response, a specific subset of the IPv4 address space was designated as private, to
temporarily alleviate this problem.
A public address can be routed on the Internet. Thus, devices that must be Internet-
accessible must be configured with (or reachable by) public addresses. Allocation
of public addresses is governed by the Internet Assigned Numbers Authority
(IANA).
A private address is intended for internal use within a home or organization, and can be
freely used by anyone. However, private addresses can never be routed on the Internet. In
fact, Internet routers are configured to immediately drop traffic with private addresses.
Three private address ranges were defined in RFC 1918, one for each IPv4 class:
 Class A - 10.x.x.x /8
 Class B - 172.16.x.x /12
 Class C - 192.168.x.x /24
It is possible to translate between private and public addresses, using Network Address
Translation (NAT). NAT allows a host configured with a private address to be stamped
with a public address, thus allowing that host to communicate across the Internet. It is also
possible to translate multiple privately-addressed hosts to a single public address, which
conserves the public address space.
NAT provides an additional benefit – hiding the specific addresses and addressing
structure of the internal (or private) network.
Note: NAT is not restricted to private-to-public address translation, though that is the most
common application. NAT can also perform public-to-public address translation, as well as
private-to-private address translation.
NAT is only a temporarily solution to the address shortage problem. IPv4 will eventually
be replaced with IPv6, which supports a vast address space.
Both Cisco IOS devices and PIX/ASA firewalls support NAT.
Types of NAT
NAT can be implemented using one of three methods:
Static NAT – performs a static one-to-one translation between two addresses, or between a
port on one address to a port on another address. Static NAT is most often used to assign a
public address to a device behind a NAT-enabled firewall/router.
Dynamic NAT – utilizes a pool of global addresses to dynamically translate the outbound
traffic of clients behind a NAT-enabled device.
NAT Overload or Port Address Translation (PAT) – translates the outbound traffic of
clients to unique port numbers off of a single global address. PAT is necessary when the
number of internal clients exceeds the available global addresses.
NAT Terminology
Specific terms are used to identify the various NAT addresses:
 Inside Local – the specific IP address assigned to an inside host behind a NAT-
enabled device (usually a private address).
 Inside Global – the address that identifies an inside host to the outside world (usually
a public address). Essentially, this is the dynamically or statically-assigned public
address assigned to a private host.
 Outside Global – the address assigned to an outside host (usually a
public address).
 Outside Local – the address that identifies an outside host to the inside network.
Often, this is the same address as the Outside Global. However, it is occasionally
necessary to translate an outside (usually public) address to an inside (usually private)
address.
For simplicity sake, it is generally acceptable to associate global addresses with public
addresses, and local addresses with private addresses.
However, remember that public-to-public and private-to-private translation
is still possible. Inside hosts are within the local network, while outside
hosts are external to the local network.
 NAT Terminology Example

Consider the above example. For a connection from HostA to HostB, the NAT addresses
are identified as follows:
 Inside Local Address - 10.1.1.10
 Inside Global Address - 55.1.1.1
 Outside Global Address – 99.1.1.2
 Outside Local Address – 99.1.1.2
HostA’s configured address is 10.1.1.10, and is identified as its Inside Local address. When
HostA communicates with the Internet, it is stamped with RouterA’s public address, using
PAT. Thus, HostA’s Inside Global address will become 55.1.1.1.
When HostA communicates with HostB, it will access HostB’s Outside Global address of
99.1.1.2. In this instance, the Outside Local address is also
99.1.1.2. HostA is never aware of HostB’s configured address.
It is possible to map an address from the local network (such as 10.1.1.5) to the global
address of the remote device (in this case, 99.1.1.2). This may be required if a legacy device
exists that will only communicate with the local subnet. In this instance, the Outside Local
address would be 10.1.1.5.

Static NAT Translation

99.1.1.2 =
192.168.1.5
55.1.1.1
10.1.1.1
Internet 99.1.1.1
192.168.1.1
RouterA RouterA
HostA NAT-Enabled NAT-Enabled HostB
10.1.1.1 192.168.1.
0 5
SRC Address = SRC Address = 55.1.1.1:31092 SRC Address = 55.1.1.1:31092
10.1.1.10 DST Address DST Address = 99.1.1.2 DST Address = 192.168.1.5
= 99.1.1.2

The above example demonstrates how the source (SRC) and destination
(DST) IP addresses within the Network-Layer header are translated by NAT.

(Reference: http://www.cisco.com/warp/public/556/8.html)
 Router(config)# int e0/0 Router(config)# int s0/0
Router(config-if)# ip nat inside Router(config-if)# ip nat outside

To statically map a public address to a private address, the syntax is as follows:

Router(config)# ip nat inside source static 172.16.1.1 158.80.1.40
This command performs a static translation of the source address 172.16.1.1
(located on the inside of the network), to the outside address of 158.80.1.40.

Configuring Dynamic NAT

When configuring Dynamic NAT, the inside and outside interfaces must first be identified:

Router(config)# int e0/0 Router(config)# int s0/0

Router(config-if)# ip nat inside Router(config-if)# ip nat outside
Next, a pool of global addresses must be specified. Inside hosts will dynamically
choose the next available address in this pool, when communicating outside the local
network:
Router(config)# ip nat pool POOLNAME 158.80.1.1 158.80.1.50 netmask 255.255.255.0
The above command specifies that the pool named POOLNAME contains a range of public
addresses from 158.80.1.1 through 158.80.1.50.
Finally, a list of private addresses that are allowed to be dynamically translated must be
specified:
Router(config)# ip nat inside source list 10 pool POOLNAME
Router(config)# access-list 10 permit 172.16.1.0 0.0.0.255
The first command states that any inside host with a source that matches access-list 10
can be translated to any address in the pool named POOLNAME.
The access-list specifies any host on the 172.16.1.0 network.
Configuring NAT Overload (or PAT)
Recall that NAT Overload (or PAT) is necessary when the number of internal clients
exceeds the available global addresses. Each internal host is translated to a unique port
number off of a single global address.
Configuring NAT overload is relatively simple:
Router(config)# int e0/0
Router(config-if)# ip nat inside
Router(config)# int s0/0
Router(config-if)# ip nat outside
Router(config)# ip nat inside source list 10 interface Serial0/0 overload
Router(config)# access-list 10 permit 172.16.1.0 0.0.0.255
Any inside host with a source that matches access-list 10 will be translated with
overload to the IP address configured on the Serial0/0 interface.
Troubleshooting NAT
To view all current static and dynamic translations:
Router# show ip nat translations

To view whether an interface is configure as an inside or outside NAT interface, and to

display statistical information regarding active NAT translations:
Router# show ip nat statistics

To view NAT translations in real-time:

Router# debug ip nat

To clear all dynamic NAT entries from the translation table:

Router# clear ip nat translation
3.4.c Configure first hop redundancy protocols, such as
HSRP and VRRP

Redundancy and Load Balancing

Importance of Redundancy
High availability is critical in most environments. Even a brief outage due to hardware
failure may be considered unacceptable. Consider the following example:

To reach other networks, HostA must utilize a single gateway – SwitchA. The gateway
represents a single point of failure on this network. If the gateway fails, hosts will lose
access to all resources beyond the gateway.
Using multiple routers or multilayer switches can provide Layer-3 redundancy
for hosts:
However, the Layer-3 redundancy must be transparent to each host. Hosts should not be
configured with multiple default gateways.
Cisco supports three protocols to provide transparent Layer-3 redundancy:
 Hot Standby Router Protocol (HSRP)
 Virtual Router Redundancy Protocol (VRRP)
 Gateway Load Balancing Protocol (GLBP)
Hot Standby Router Protocol (HSRP)
Cisco developed the proprietary Hot Standby Router Protocol (HSRP) to allow multiple
routers or multilayer switches to masquerade as a single gateway. This is accomplished by
assigning a virtual IP and MAC address to all routers participating in an HSRP group.
Routers within the same HSRP group must be assigned the same group number, which
can range from 0 to 255. However, most Cisco platforms only support 16 configured
HSRP groups.
HSRP routers are elected to specific roles:
 Active Router – router currently serving as the gateway.
 Standby Router – backup router to the Active Router.
 Listening Router – all other routers participating in HSRP.
Only one active and one standby router are allowed per HSRP group. Thus, HSRP
provides Layer-3 redundancy, but no inherent load balancing.
Hello packets are used to elect HSRP roles and to ensure all routers are functional. If the
current active router fails, the standby router will immediately take over as active, and a
new standby is elected. By default, hello packets are sent every 3 seconds.
The role of an HSRP router is dictated by its priority. The priority can range from 0 – 255,
with a default of 100. A higher priority is preferred.

Thus, the router with the highest priority is elected the active router – SwitchB in the
above example. The router with the second highest priority becomes the standby router –
SwitchA in the example. If all priorities are equal, whichever router has the highest IP
Address on its HSRP interface is elected the active router.
HSRP States
A router interface participating in HSRP must progress through several
states before settling into a
role:
 Disabled  Speak
 Initial  Standby
 Learn  Active
 Listen

A disabled state indicates that the interface is either not configured for HSRP, or is
administratively shutdown.
An interface begins in an initial state when first configured with HSRP, or taken out of
an administratively shutdown state.
An interface enters a learn state if it does not know the HSRP virtual IP address. Normally
the virtual IP is manually configured on the interface – otherwise, it will be learned from
the current Active router via hello packets.
An interface in a listen state knows the virtual IP address, but was not elected as
either the Active or Standby Router.
Interfaces in a speak state are currently participating in the election of an active or standby
router. Elections are performed using hello packets, which are sent out every 3 seconds by
default.
A standby state indicates that the interface is acting as a backup to the active router. The
standby router continuously exchanges hello packets with the active router, and will
take over if the active router fails.
An interface in an active state is the live gateway, and will forward traffic sent to the
virtual IP address. Hosts will use the virtual IP address as their default gateway. The
active router will respond to ARP requests for the virtual IP with the virtual MAC address.
Note that hello packets are only exchanged in three HSRP states:
 Speak
 Standby
 Active
Interfaces in a listen state will only listen for hello packets. If an active or standby router
fails, a listen interface will transition to a speak state to participate in a new election.
HSRP Basic Configuration
HSRP is configured on the interface that is accepting traffic from hosts.
Recall that the interface with the highest priority is elected the active router. To configure
the priority of a router from its default of 100:
Router(config)# interface gi0/3
Router(config-if)# standby 1 priority 150
The standby 1 command specifies the HSRP group the interface belongs to. HSRP can also
be configured on a VLAN interface on a multilayer switch:
SwitchB(config)# interface vlan 100
SwitchB(config-if)# standby 1 priority 150
Each interface in the HSRP group retains its local IP address. The HSRP group itself is
assigned a virtual IP address, which hosts will use as their default gateway:
To configure the virtual HSRP IP
address: SwitchA(config)# interface vlan 100
SwitchA(config-if)# ip address 10.1.1.2 255.255.255.0
SwitchA(config-if)# standby 1 ip 10.1.1.1
SwitchB(config)# interface vlan 100
SwitchB(config-if)# ip address 10.1.1.3 255.255.255.0
SwitchB(config-if)# standby 1 ip 10.1.1.1
Remember: while each multilayer switch is configured with its own local IP
address, both are configured with the same virtual IP address. HostA will use this
virtual IP address as its default gateway.
HSRP Basic Configuration (continued)
HSRP supports using multiple virtual IP addresses:
SwitchB(config-if)# standby 1 ip 10.1.1.1
SwitchB(config-if)# standby 1 ip 10.1.1.5 secondary
The active router will respond to ARP requests for the virtual IP with
the
virtual MAC address.
The virtual MAC is a reserved address in the following format:
0000.0c07.acxx
…with xx representing the HSRP group number in hexadecimal. For example, if the HSRP
group number is 8, the resulting virtual MAC address would be 0000.0c07.ac08.
The HSRP virtual MAC address can be manually changed:
Switch(config-if)# standby 1 mac-address 0000.00ab.12ef
HSRP authentication prevents an unauthorized router from joining the HSRP group. All
routers in the HSRP group must be configured with an identical authentication string.
To specify a clear-text authentication string:
Switch(config-if)# standby 1 authentication STAYOUT
To specify an MD5-hashed authentication string:
Switch(config-if)# standby 1 authentication md5 key-string 7 STAYOUT
HSRP Preempt
If a new router is added to an HSRP group, it will not preemptively assume the role of the
active router, even if it has the best priority.
In fact, the router that is first powered on will become the active router, even if it has the
lowest priority!
Consider the above
1. If SwitchB was powered on first, it would become the active router.
example:
2. SwitchA would be elected the standby router.
3. If SwitchB fails, SwitchA would take over as the active router.
4. Once SwitchB recovers, it will not retake its role of active router,
despite having a higher priority.
The preempt parameter will allow a router to forcibly assume the role of active router, if it
has the highest priority. The preempt feature is disabled by default:
SwitchB(config-if)# standby 1 preempt
The optional delay parameter will force a router to wait before preempting as the active
router. The delay is measured in seconds:
HSRP Timers
Hello packets are used to elect the active and standby router, and to detect if there is a
failure. By default, hello packets are exchanged every 3 seconds.
HSRP Hello packets are sent to the multicast address 224.0.0.2 over UDP port 1985. If no
elections are occurring, only the active and standby routers exchange hello packets.
If no hello packets are received from the active router within the holddown timer
duration, the standby router will assume it failed and take over as active. By default, the
holddown timer is three times the hello timer, or 10 seconds. Cisco’s math, not mine.
To manually adjust the HSRP timers, measured in seconds:
SwitchB(config-if)# standby 1 timers 4 12
The first timer value represents the hello timer, while the second represents the
holddown
timer. The timers can also be specified in milliseconds:
SwitchB(config-if)# standby 1 timers msec 800 msec 2400
HSRP Tracking

In the above example, SwitchB will become the active router, and SwitchA the standby.
Both SwitchA and SwitchB exchange periodic hello packets to update their status.
If interface gi2/23 goes down on SwitchB, hello packets can still be exchanged with
SwitchA via interface gi2/22. SwitchA is unaware that SwitchB has a failure and can no
longer forward traffic to other networks. SwitchB will remain as the active router, and
traffic will be blackholed.
To mitigate a scenario like this, HSRP can track interfaces. If a tracked interface fails,
the router’s priority is decreased by a specified value – by default, this is 10.
Consider the following tracking configuration on SwitchB:
SwitchB(config-if)# standby 1 track gi2/23 60
If interface gi2/23 on SwitchB fails, the priority of the switch will decrease by 60. The
objective is to decrement the priority enough to allow the standby router to take over as
active.
This requires conscientious planning - if SwitchB’s priority decremented by only 40, it
would remain as active, as its priority would still be higher than SwitchA.
For tracking to be successful, the standby router must be configured to
preempt:
SwitchA(config-if)# standby 1 preempt
Otherwise, the standby router will never take over as active.
Virtual Router Redundancy Protocol (VRRP)
Virtual Router Redundancy Protocol (VRRP)
The Virtual Router Redundancy Protocol (VRRP) is an industry-standard Layer-3
redundancy protocol, originally defined in RFC 2338. VRRP is nearly identical to HSRP,
with some notable exceptions:
 The router with the highest priority becomes the master router.
 All other routers become backup routers.
 The virtual MAC address is the reserved 0000.5e00.01xx, with xx
representing the hexadecimal group number.
 Hello packets are sent every 1 second, by default, and sent to multicast
address 224.0.0.18.
 VRRP will preempt by default.
 VRRP cannot directly track interfaces – it can track an object which is tied to an
interface, though.
Configuration of VRRP is also very similar to HSRP:
SwitchB(config)# interface vlan 100
SwitchB(config-if)# ip address 10.1.1.3 255.255.255.0
SwitchB(config-if)# vrrp 1 priority 150
SwitchB(config-if)# vrrp 1 authentication STAYOUT
SwitchB(config-if)# vrrp 1 ip 10.1.1.1
As with HSRP, the default VRRP priority is 100, and a higher priority is preferred.
Unlike HSRP, preemption is enabled by default.
To manually disable preempt:
Switch(config-if)# no vrrp 1 preempt

To view the status of each VRRP group:

Switch# show vrrp
Vlan 100 - Group 1 State is
Master Virtual IP address is
10.1.1.1
Virtual MAC address is
0000.5e00.0101

Advertisement interval is
3.000 sec Preemption is enabled
min delay is 0.000 sec Priority 150
Master Router is 10.1.1.3 (local),
priority is 150
Master Advertisement interval is 3.000 sec Master Down interval is
9.711 sec
HSRP and VRRP Pseudo Load Balancing
While HSRP and VRRP do provide redundant gateways for fault tolerance, neither
provide load balancing between those gateways.
Cisco will claim that load balancing is possible. Two separate HSRP or VRRP
groups
canSwitchA(config)#
be configured on a single interface: SwitchB(config)# interface vlan 100
interface vlan 100
SwitchA(config-if)# ip address 10.1.1.2 255.255.255.0 SwitchB(config-if)# ip address 10.1.1.3 255.255.255.0

SwitchA(config-if)# standby 1 priority 150 SwitchB(config-if)# standby 1 priority 50

SwitchA(config-if)# standby 1 preempt SwitchB(config-if)# standby 1 preempt
SwitchA(config-if)# standby 1 ip 10.1.1.1 SwitchB(config-if)# standby 1 ip 10.1.1.1

SwitchA(config-if)# standby 2 priority 50 SwitchB(config-if)# standby 2 priority 150

SwitchA(config-if)# standby 2 preempt SwitchB(config-if)# standby 2 preempt
SwitchA(config-if)# standby 2 ip 10.1.1.254 SwitchB(config-if)# standby 2 ip 10.1.1.254

In the above configuration, each HSRP group has been assigned a unique virtual IP address – 10.1.1.1 and
10.1.1.254 respectively. By manipulating the priority, each multilayer switch will become the active router for one
HSRP group, and the standby router for the other group.
SwitchA# show standby brief
 Interface Grp Prio P State Active addr Standby addr Group addr
Vlan100 1 150 P Active local 10.1.1.3 10.1.1.1
Vlan100 2 50 P Standby 10.1.1.3 local 10.1.1.254

SwitchB# show standby brief

Standby addr Group addr
Interface Grp Prio P State Active
Vlan100 1 50 P Standby 10.1.1.2 local 10.1.1.1
addr 10.1.1.2 10.1.1.25
2 150 P Active local
4
Vlan100
To achieve load balancing with this HSRP setup, half of the hosts in VLAN 100 must point to the first virtual
address
as their gateway – 10.1.1.1. The other half must use the other virtual address as their gateway – 10.1.1.254.
Simple and practical, right? Certainly, it is perfectly feasible to manually configure half of the hosts to use one
gateway, and manually configure the other half to use another.
But hey – it’s not a limitation, it’s a feature!
3.4.d Describe multicast protocols, such
as PIM and IGMP v2/v3
Types of “packets”
Three types of packets can exist on an IPv4 network:
Unicast – A packet sent from one host to only one other host. A hub will forward a
unicast out all ports. If a switch has a table entry for the unicast’s MAC address, it will
forward it out only the appropriate port.
Broadcast – A packet sent from one host to all hosts on the IP subnet. Both hubs and
switches will forward a broadcast out all ports. By definition, a router will not forward a
broadcast from one segment to another.
Multicast – A packet sent from one host to a specific group of hosts. Switches, by
default, will forward a multicast out all ports. A router, by default, will not forward a
multicast from one segment to another.
Multicast Concepts
Remember, a multicast is a packet sent from one computer to a group of hosts. A host
must join a multicast group in order to accept a multicast.
Joining a multicast group can be accomplished statically or dynamically.
Multicast traffic is generally sent from a multicast server, to multicast clients. Very
rarely is a multicast packet sent back from a client to the server.
Multicasts are utilized in a wide range of applications, most notably voice or video
systems
that have one source “serving” out data to a very specific group of clients.
The key to configuring multicast is to ensure only the hosts that require the multicast
traffic actually receive it.
Multicast Addressing
IPv4 addresses are separated into several “classes.”
Class A: 1.1.1.1 – 127.255.255.255
Class B: 128.0.0.0 – 191.255.255.255
Class C: 192.0.0.0 – 223.255.255.255
Class D: 224.0.0.0 – 239.255.255.255
Class D addresses have been reserved for multicast. Within the Class D address space,
several ranges have been reserved for specific purposes:
 224.0.0.0 – 224.0.0.255 – Reserved for routing and other network protocols, such
as
OSPF, RIP, VRRP, etc.

 224.0.1.0 – 238.255.255.255 – Reserved for “public” use, can be used publicly on the
Internet. Many addresses in this range have been reserved for specific applications
 239.0.0.0 – 239.255.255.255 – Reserved for “private” use, and cannot be routed on the
Internet.
The following outlines several of the most common multicast addresses reserved for
routing protocols:
 224.0.0.1 – all hosts on this subnet
 224.0.0.2 – all routers on this subnet
 224.0.0.5 – all OSPF routers
 224.0.0.6 – all OSPF Designated routers
 224.0.0.9 – all RIPv2 routers
 224.0.0.10 – all IGRP routers
 224.0.0.12 – DHCP traffic
 224.0.0.13 – all PIM routers
 224.0.0.19-21 – ISIS routers
 224.0.0.22 – IGMP traffic
 224.0.1.39 – Cisco RP Announce
 224.0.1.40 – Cisco RP Discovery
Multicast MAC Addresses
Unfortunately, there is no ARP equivalent protocol for multicast addressing. Instead, a
reserved range of MAC addresses were created for multicast IPs. All multicast MAC
addresses begin with:
0100.5e
Recall that the first six digits of a MAC address identify the vendor code, and the last 6
digits identify the specific host address. To complete the MAC address, the last 23 bits of
the multicast IP address are used.
For example, consider the following multicast IP address and its binary equivalent:
224.65.130.195 = 11100000.01000001.10000010.11000011
Remember that a MAC address is 48 bits long, and that a multicast MAC must begin
with 0100.5e. In binary, that looks like:
00000001.00000000.01011110.0
Add the last 23 bits of the multicast IP address to the MAC, and we
get:
00000001.00000000.01011110.01000001.10000010.11000011
That should be exactly 48 bits long. Converting that to Hex format, our full MAC address
would be:
0100.5e41.82c3
How did I convert this to Hex? Remember that hexadecimal is Base 16 mathematics.
Thus, to represent a single hexadecimal digit in binary, we would need 4 bits (24 = 16). So,
we can break down the above binary MAC address into groups of four bits:

Binary 0000 0001 0000 0000 0101 1110 0100 0001 1000 0010 1100 0011
Decimal 0 1 0 0 5 14 4 1 8 2 12 3
Hex 0 1 0 0 5 e 4 1 8 2 c 3

Hence the MAC address of

0100.5e41.82c3.
Multicast MAC Addresses (continued)
Ready for some more math, you binary fiends?
Calculate what the multicast MAC address would be for the following IP addresses:
225.2.100.15 = 11100001.00000010.01100100.00001111
231.130.100.15 = 11100111.10000010.01100100.00001111
Remember that all multicast MACs begin with:
0100.5e = 00000001.00000000.01011110.0
So, add the last 23 digits of each of the above IP addresses to the MAC address, and
we get:
225.2.100.15 = 00000001.00000000.01011110.00000010.01100100.00001111
231.130.100.15 = 00000001.00000000.01011110.00000010.01100100.00001111

In Hex, that would be:

225.2.100.15 = 0100.5e02.640f
231.130.100.15 = 0100.5e02.640f
Wait a second…. That’s the exact same multicast MAC address, right? Double-
checking our math, we see that it’s perfect.
Believe it or not, each multicast MAC address can match 32 multicast IP addresses,
because we’re only taking the last 23 bits of our IP address.
We already know that all multicast IP addresses MUST begin 1110. Looking at the
225.2.100.15 address in binary:
11100001.00000010.01100100.00001111
That leaves 5 bits in between our starting 1110, and the last 23 bits of our IP. Those 5 bits
could be anything, and the multicast MAC address would be the same. Because 25 = 32,
there are 32 multicast IP’s per multicast MAC.
According to the powers that be, the likelihood of two multicast systems utilizing the
same multicast MAC is rare. The worst outcome would be that hosts joined to either
multicast system would receive multicasts from both.
Multicasts and Routing
Multicasts and Routing
A router, by default, will drop multicast traffic, unless a Multicast routing protocol is
utilized. Multicast routing protocols ensure that data sent from a multicast source are
received by (and only by) its corresponding multicast clients.
Several multicast routing protocols exist, including:
 Protocol Independent Multicast (PIM)
 Multicast OSPF (MOSPF)
 Distance Vector Multicast Routing Protocol (DVMRP)
 Core-Based Trees (CBT)
Multicast routing must be enabled globally on a Cisco router or switch, before it can be
used:
Switch(config)# ip multicast-routing
Multicast Path Forwarding
Normally, routers build routing tables that contain destination addresses, and route packets
towards that destination. With multicast, routers are concerned with routing packets away
from the multicast source. This concept is called Reverse Path Forwarding (RPF).
Multicast routing protocols build tables that contain several elements:
 The multicast source, and its associated multicast address (labeled as “S,G”, or
“Source,Group”)
 Upstream interfaces that point towards the source
 Downstream interfaces that point away from the source towards multicast hosts.
Multicast Path Forwarding Example
A router interface will not be designated as a downstream interface unless multicast hosts
actually exist downstream. In the above example, no multicast hosts exist downstream of
Router 5.
In fact, because no multicast hosts exist downstream of Router 1 towards Router 2, no
multicast traffic for this multicast group will be forwarded down that path. Thus, Router
1’s interface connecting to Router 2 will not become a downstream port.
This pruning allows for efficient use of bandwidth. No unnecessary traffic is sent down a
particular link. This “map” of which segments contain multicast hosts is called the multicast
tree. The multicast tree is dynamically updated as hosts join or leave the multicast group
(otherwise known as pruning the branches).
By designating upstream and downstream interfaces, the multicast tree remains loop-free.
No multicast traffic should ever be sent back upstream towards the multicast source.
Internet Group Management Protocol (IGMP)
Remember, multicast works by having a source send data to a specific set of clients that
belong to the same multicast group. The multicast group is configured (or assigned) a
specific multicast address.
The multicast clients need a mechanism to join multicast groups. Internet Group
Management Protocol (IGMP) allows clients to send “requests” to multicast-enabled
routers to join a multicast group.
IGMP only handles group membership. To actually route multicast data to a client, a
multicast routing protocol is required, such as PIM or DVMRP.
Three versions of IGMP exist, IGMPv1, IGMPv2, and IGMPv3.
IGMPv1 routers send out a “query” every 60 seconds to determine if any hosts need
access to a multicast server. This query is sent out to the
224.0.0.1 address (i.e., all hosts on the subnet). Interested hosts must reply
with a Membership Report stating what multicast group they wish to join.
Unfortunately, IGMPv1 does not allow hosts to dynamically “leave” a group. Instead, if
no Membership Reports are received after 3 times the query interval, the router will
flush the hosts out of its IGMP table.
IGMPv2 adds additional functionality. Queries can be sent out either as General
Queries (224.0.0.1) or Group-Specific Queries (only sent to specific group members).
Additionally, hosts can send a Leave Group message to IGMPv2 routers, to immediately
be flushed out of the IGMP table. Thus, IGMPv2 allows the multicast tree to by updated
more efficiently.
All versions of IGMP elect one router to be the Designated Querier for that subnet. The
router with the lowest IP address becomes Designated.
IGMPv1 is not compatible with IGMPv2. If any IGMPv1 routers exist on the network,
all
routers must operate in IGMPv1 mode.
Cisco IOS version 11.1 and later support IGMPv2 by default.
IGMPv3 enhances v2 by supporting source-based filtering of multicast groups.
Essentially, when a host responds to an IGMP query with a Membership Report, it can
specifically identify which sources within a multicast group to join (or even not join).
IGMP
Example
In the above example, assume the router is using IGMPv2. Interface fa0/1 points towards
the multicast source, and thus becomes the upstream interface.
Initially, the router will sent out Group Specific Queries out all non- upstream interfaces.
Any multicast hosts will respond with a Membership Report stating what multicast group
they wish to join.
Interfaces fa0/2 and fa0/3 will become downstream interfaces, as they contain multicast
hosts. No multicast traffic will be sent out fa0/4.
If all multicast hosts leave the multicast group off of interface fa0/2, it will be removed
from the multicast tree. If a multicast host is ever added off of interface fa0/4, it will
become a downstream interface.
IGMP Configuration
No configuration is required to enable IGMP, except to enable IP multicast routing (ip
multicast-routing). We can change the version of IGMP running on a particular interface (by
default, it is Version 2):
Switch(config-if)# ip igmp version 1
To view which multicast groups the router is aware of:
Switch# show ip igmp groups
We can join a router interface to a specific multicast group (forcing the router to respond
to ICMP requests to this multicast group):
Switch(config-if)# ip igmp join-group 226.1.5.10
WE can also simply force a router interface to always forward the traffic of a specific
multicast group out an interface:
Switch(config-if)# ip igmp static-group 226.1.5.10
We can also restrict which multicast groups a host, off of a
particular interface, can join:
Switch(config)# access-list 10 permit 226.1.5.10
Switch(config)# access-list 10 permit 226.1.5.11

Switch(config-if)# ip igmp access-group 10

Protocol Independent
Multicast (PIM)
Protocol Independent Multicast (PIM)
While IGMP concerns itself with allowing multicast hosts to join multicast groups,
Protocol Independent Multicast (PIM) is a multicast routing protocol that is concerned
about getting the multicast data to its destination (or, more accurately, taking the data away
from the multicast source).
PIM is also responsible for creating the multicast tree, and “pruning” the tree so that no
traffic is sent unnecessarily down a link.
PIM can operate in three separate modes:
 PIM Dense Mode (PIM-DM)
 PIM Sparse Mode (PIM-SM)
 PIM Sparse-Dense Mode (PIM-SM-DM, Cisco proprietary)
The key difference between PIM Dense and Sparse Mode is how the multicast tree is
created. With PIM Dense Mode, all networks are flooded with the multicast traffic from
the source. Afterwards, networks that don’t need the multicast are pruned off of the tree.
The network that contains the multicast source becomes the “root” of the multicast
network.
With PIM Sparse Mode, no “flooding” occurs. Only networks that contain “requesting”
multicast hosts are added to the multicast tree. A centralized PM router, called the
Rendezvous Point (RP), is elected to be the “root” router of the multicast tree. PIM routers
operating in Sparse Mode build their tree towards the RP, instead of towards the multicast
source. The RP allows multiple multicast “sources” to utilize the same multicast tree.
PIM Sparse-Dense Mode allows either Sparse or Dense Mode to be used, depending on
the multicast group. Any group that points to an RP utilizes Sparse Mode. PIM Sparse-
Dense Mode is Cisco proprietary.
Consider these key points:
 Dense Mode should be used when a large number of multicast hosts exist across the
internetwork. The “flooding” process allows for a quick creation of the multicast
tree, at the expense of wasting bandwidth.

 Sparse Mode should be used when only a limited number of multicast hosts exist.
Because hosts must explicitly join before that network segment is added to the
multicast tree, bandwidth is utilized more efficiently.
PIM Dense Mode Example

Multicast
Source
Router 1

Router 2 Router 3 Router 4

Router 6 Router 7
Router 5

Multicast Hosts No Multicast Multicast Hosts

No Multicast Hosts
Hosts

Consider the above example. When PIM routers operate in Dense Mode,
all segments of the multicast tree are flooded initially. Eventually,
“branches” that do not require the multicast traffic are pruned off:
 Multicast
Source
Router 1

Router 2 Router 3 Router 4

Router 6 Router 7
Router 5

Multicast Hosts No Multicast Multicast Hosts

No Multicast Hosts
Hosts
PIM Sparse Mode
Example

When PIM routers operate in Sparse Mode, multicast traffic is not initially flooded
throughout the entire multicast tree. Instead, a Rendezvous Point (RP) is elected or
designated, and all multicast sources and clients must explicitly register with the RP. This
provides a centralized method of directing the multicast traffic of multiple multicast sources:
Configuring Manual PIM
Two versions of PIM exist (PIMv1 and PIMv2), though both are very similar. PIM must be
enabled on each participating interface in the multicast tree.
To enable PIM and specify its mode on an interface:
Switch(config)# interface fa0/10
Switch(config-if)# no switchport
Switch(config-if)# ip pim dense-mode
Switch(config-if)# ip pim sparse-mode
Switch(config-if)# ip pim sparse-dense-mode
When utilizing PIM-SM, we must configure a Rendezvous Point (RP). RP’s can be
identified manually, or dynamically chosen using a process called auto-RP (Cisco-
proprietary).
To manually specify an RP on a router:
Switch(config)# ip pim rp-address 192.168.1.1
The above command must be configured on every router in the multicast tree, including
the RP itself.
To restrict the RP to a specific set of multicast groups:
Switch(config)# access-list 10 permit 226.10.10.1
Switch(config)# access-list 10 permit 226.10.10.2
Switch(config)# ip pim rp-address 192.168.1.1 10
The first two commands create an access-list 10 specifying the multicast groups this RP
will support. The third command identifies the RP, and applies access-list 10 to the RP.
Troubleshooting Multicasting
To view IGMP groups and current members:
Switch# show ip igmp groups

To view PIM “neighbors”:

Switch# show ip pim neighbor

To view PIM RPs:

Switch# show ip pim rp

We can also debug multicasting protocols:

Switch# debug ip igmp

Switch# debug ip pim

Viewing the Multicast Table
Just like unicast routing protocols (such as OSPF, RIP), multicast routing protocols
build a routing table.
Again, these tables contain several elements:
 The multicast source, and its associated multicast address (labeled as “S,G”,
or
“Source,Group”)
 Upstream interfaces that point towards the source
 Downstream interfaces that point away from the source towards multicast
hosts.
To view the multicast routing table:
Switch# show ip mroute
Remember that a multicast source with its associated multicast address is labeled as
(S,G). Thus, in the above example, 10.1.1.1/24 is the multicast source, while 239.5.222.1
is the multicast address/group that the source belongs to.
The Incoming interface indicates the upstream interface. The RPF neighbor is the next hop
router “upstream” towards the source. The outgoing interface(s) indicate downstream
interfaces.
Notice that the S – Sparse flag is not set. That’s because PIM is running in Dense Mode.

Viewing the Multicast Table (continued)

Remember, to view the multicast routing table:
Switch# show ip mroute

If using PIM in Sparse Mode, the output would be similar to the following:
Notice that the (S,G) pairing is labeled as (*, 224.59.222.10). In Sparse Mode, we can
have multiple sources share the same multicast tree.
The Rendezvous Point (RP) is 10.1.1.10. The flags are set to SC, indicating this router is
running in Sparse Mode.
Just like with Dense Mode, the Incoming interface indicates the upstream
interface, and the outgoing interface(s) indicate downstream interfaces.
However, the RPF neighbor is the next hop router “upstream” towards the
RP now, and not the source.