The routing table is concerned with two types of protocols:
PROTOCOL:-
Protocol are a set of rules and regulation that define data transfer over the
network. Which are rules that govern end-to-end communication between
devices. Protocols are rules
that govern how devices communicate and share
information across a network.
- ROUTED PROTOCOL :- Routed protocol is a layer 3 protocol
that applies logical addresses to devices and routes data between
networks. It is used to Forward the packet over the network. Examples
would be IP, IPX, SPX, AppleTalk.
- ROUTING PROTOCOL:-
Routing protocol dynamically builds the network, topology, and next
hop information in routing tables. It is used Exchange information from
one router to other router and to find out the best route for packet to
reach the right destination. Examples would be RIP, IGRP, EIGRP,OSPF,
IS-IS, BGP etc.
IP ROUTING
It is a technique in which we can
interconnect two or more different network with each other and transfer data
based on IP header in data packet by the help of router device and router
devices used some routing protocol to find out the best route for particular
destination and routing protocol used it’s metrics.
There
are following types of routing:-
Ø
Static Routing
Ø
Default Routing
Ø
Dynamic Routing
STATIC ROUTING:- In static routing we define
the route manually in routing table of a router.
DEFAULT ROUTING:- In default routing , router doesn’t
aware about destination network In that
case We can define destination as 0.0.0.0
and their subnet mask also 0.0.0.0
. it create Only that router which has only one enter and exit interface.
Note: It is used for STUB ROUTER (A Router which has only one entry
and exit point)
DYNAMIC ROUTING:- IN this routing , we used routing
protocol they dynamically learn the
route and learn next hop address and do send the own routing information to their neighbor router
and routing information is exchanged
automatically with the help of routing protocols.
ROUTING
PROTOCOL
There are Two types of Routing Protocol:
1:- INTERIOR GATEWAY
PROTOCOL:- These types of
protocol can communicate between two or more same autonomous system number.
This types of protocol used to route the packet inside an autonomous system.
They work within AS.
TYPES
OF INTERIOR GATEWAY PROTOCOL:-
a. Distance-vector Routing Protocols. Ex.- RIP, (RIP v1,v2), IGRP.
b. Enhanced Distance-vector Routing protocol (Hybrid). Ex.-
EIGRP.
c. Link-State Routing Protocols. Ex.- OSPF, IS-IS.
2:- EXTERIOR GATEWAY
PROTOCOL:- These types of
protocol can communicate between two or more different autonomous system
number. They work over AS.
TYPES
OF EXTERIOR GATEWAY PROTOCOL:-
Path-vector. Ex.-
BGP.(ibgp, ebgp)
METRICS– It is unit of hop count, bandwidth, Reliability, load,
cost, delay, MTU (maximum transmission unit ) to identify the appropriate path.
Routing metric are value that allow the router decide the best route for the
data packet.
ADMINISTRATIVE DISTANCE (AD) -- AD is an integer assigned to every rooting protocol in the range of (0 to 255).
A number between 0 and 255 that expresses the level of trustworthiness of a
routing information source. lower AD value routing protocol more reliable to
provides routing information .
IF two protocol have
same AD then router used it’s metrics to find out the best route to data
packet.
IF the AD and Metric for both protocol are the same, then the
router send equal amount of packet through the connected link. This term as
load balancing.
Protocol
|
AD Value
|
Connected Interface
|
0
|
Static Route
|
1
|
EIGRP
EXTERNAL EIGRP
Summary EIGRP
|
90 IP Protocol No. 88
170
5
|
IGRP
|
100 IP Protocol No.=9
|
OSPF
|
110 IP Protocol No.=89
|
IS-IS
|
115
|
RIP
|
120 UDP Port No.=520
|
BGP
|
External=20 TCP=179
Internal=200
|
Unknown
|
It is
never used
|
1.DISTANCE-VECTOR ROUTING PROTOCOLS ( RIP
& IGRP)
All distance-vector
routing protocols share several key characteristics:-
·
A
distance –vector routing protocol select the route based on distance that is
called “HOP COUNT”.
·
Periodic updates
of the full routing table are sent to
their neighbors router. Distance-vector protocols suffer from slow
convergence, and are highly susceptible to loops.
·
Some
form of distance is used to calculate a route’s metric.
·
The
Bellman-Ford algorithm is used to determine the shortest path.
·
A
distance-vector routing protocol begins by advertising directly-connected
networks to its neighbors. These updates are sent regularly (RIP – every
30 seconds; IGRP – every 90 seconds).
·
Neighbors
will add the routes from these updates to their own routing tables. Each
neighbor trusts this information completely, and will forward their full
routing table (connected and learned routes) to every other neighbor.
Thus, routers fully (and blindly) rely on neighbors for route information, a concept
known as routing by rumor.
·
There
are several disadvantages to this behavior. Because routing information is
propagated from neighbor to neighbor via periodic updates.
·
Distance-vector
protocols suffer from slow convergence. This, in addition to blind faith of
neighbor updates, results in distance-vector protocols being highly susceptible
to routing loops.
·
Distance-vector
protocols utilize some form of distance to calculate route’s metric.
·
RIP
uses hop count as its distance
metric, and IGRP uses a composite of bandwidth and delay.
2 ENHACED DISTANCE VECTOR ROUTING PROTOCOL
(HYBRID) (EIGRP):-
·
It
is combination of both distance-vector and link-state characteristics, and is
considered a hybrid protocol.
- It is based on distance vector
algorithm.
- It send incremental update
like link-state.
3 Link-State Routing
Protocols (OSPF & IS-IS ):-
- These protocol
send update based on the link when a link comes up and goes down it send
update that time.
- Link-state
routing protocols were developed to alleviate the convergence and loop issues of distance-vector
protocols. Link-state protocols maintain three separate tables:
-
Neighbor table –
contains a list of all neighbors, and the interface each neighbor is connected
off of. Neighbors are formed by sending Hello packets.
-
Topology table –
otherwise known as the “link-state” table, contains a map of all links within
an area, including each link’s status.
-
Shortest-Path table – contains the best routes to each particular destination
(otherwise known as the “routing” table”)
·
Link-state
protocols do not “route by rumor.” Instead, routers send updates advertising
the state of their links (a link is a directly-connected
network).All routers know the state of all existing links within their area,
and store this information in a topology table. All routers within an
area have identical topology tables.
·
The
best route to each link (network) is stored in the routing (or shortest
path) table. If the state of a link changes, such as a router interface failing,
an advertisement containing only this link-state change will be
sent to all routers within that area. Each router will adjust its topology
table accordingly, and will calculate a new best route if
required.
·
By
maintaining a consistent topology table among all routers within an area, link-state
protocols can converge very quickly and are immune to routing loops.
·
Additionally,
because updates are sent only during a link-state change, and contain only the change (and not the full table),
link-state protocols are less bandwidth intensive than distance-vector
protocols. However, the three.
·
Link-state
tables utilize more RAM and CPU on the router itself.
·
Link-state
protocols utilize some form of cost, usually based on bandwidth, to
calculate a route’s metric. The Dijkstra formula is used to determine
the shortest path.
4 Path-vector: Path-vector routing protocol select
the route based on the AS path. It select
a route which provides a network at least AS.
ROUTING INFORMATION PROTOCOL (RIP)
RIP is a
standardized Interior Gateway, Distance-Vector protocol, designed for use on
smaller networks. RIP was one of the first true Distance Vector routing
protocols, and is supported on a wide variety of systems.
RIP
adheres to the following Distance Vector characteristics:
1. RIP sends out periodic routing updates (every
30 seconds)
2. RIP sends out the full routing table every
periodic update
3. RIP uses a form of distance as its metric (in
this case, hop count)
4. RIP uses the
Bellman-Ford Distance Vector algorithm to determine the best “path” to a
particular destination.
5. RIP supports IP and IPX routing.
6. RIP utilizes UDP port 520
7. RIP routes have an administrative distance of
120.
8. RIP has a maximum
hop count of 15 hops. Any network that is 16 hops away or more is
considered unreachable to RIP, thus the maximum diameter of the network is 15
hops. A metric of 16 hops in RIP is considered a poison route or infinity
metric.
9. If multiple paths
exist to a particular destination, RIP will load balance between those paths
(by default, up to 4) only if the metric (hop count) is equal.
RIP uses a round-robin system of load-balancing between equal metric routes,
which can lead to pinhole congestion.
RIP TIMERS
RIP has
four basic timers:-
Update Timer (default 30 seconds) –
Indicates how often the router will send out a routing table update.
Invalid Timer (default 180 seconds) –
Indicates how long a route will remain in a routing table before being
marked as invalid, if no new updates are heard about this route. The invalid
timer will be reset if an update is received for that particular route before
the timer expires.
A route marked as invalid is not immediately removed
from the routing table. Instead, the route is marked (and advertised) with a
metric of 16, indicating it is unreachable, and placed in a hold-down state.
Hold-down Timer (default 180 seconds) –
Indicates how long RIP will “suppress” a route that it has placed in a hold-down
state. RIP will not accept any new updates for routes in a hold-down state,
until the hold-down timer expires.
A route will
enter a hold-down state for one of three reasons:
·
The
invalid timer has expired.
·
An
update has been received from another router, marking that route with a metric
of 16 (or unreachable).
·
An
update has been received from another router, marking that route with a higher
metric than what is currently in the routing table. This is to prevent
loops.
Flush Timer (default 240 seconds) –
Indicates how
long a route can remain in a routing table before being flushed, if no new
updates are heard about this route. The flush timer runs concurrently with
the invalid timer, and thus will flush out a route 60 seconds after it has
been marked invalid.
RIP timers must be identical on all routers on the RIP
network, otherwise massive instability will occur.
RIP LOOP
AVOIDANCE MECHANISMS
RIP, as a Distance Vector routing protocol, is susceptible to
loops. How can we prevent this from happening? There is several loop avoidance
mechanisms:
SPLIT-HORIZON:-
Prevents a routing update from being sent out
the interface it was received on. It is able to prevent counting to
infinity problem over a single link. Split-horizon is enabled by
default on Cisco Routers.
ROUTE
POISONING :- A router will advertise a route to an
unreachable network with an infinite metric to ensure all routers do not
believe any rumor about the availability of the unreachable network. Poisoned routes
are placed into hold down instead of waiting for the invalid timer to expire.
It is used
to prevent routing loops due to inconsistent routing updates through
alternative or redundant paths.
POISON REVERSE:-
·
When
the network is stable, routers use split horizon. When a link has failed and a
router received an infinite metric route, the route will be advertised out to all
interfaces (route poisoning), including those prevented by split horizon.
·
This
ensures that all routers on the segment receive the poisoned route and will not
use the invalid route.
·
It
is able to prevent counting to infinity problem.
·
It
is also known as split horizon with poison reverse.
MAXIMUM
HOP COUNT:-
·
Hop
count metric increases each time a route passes through a router. It is able to solve counting to
infinity problem by defining a maximum hop count. This is not a good
solution since packets will still loop in the network until all routers removed
or flushed the bad route from their routing tables.
HOLD-DOWN
TIMERS:-
·
Prevents
RIP from accepting any new updates for routes in a hold-down state, until the
hold-down timer expires.
TRIGGERED
UPDATES:-
·
Without
waiting for the regular scheduled routing update timer to expire, a router will
immediately send out an update as soon as a directly connected subnet
has changed state (up or down), which intends to speed up convergence time.
Also known as flash updates.
Loop-avoidance
features on distance-vector routing protocols are enabled and activated by
default.
RIP
VERSIONS
RIP has two
versions, Version 1 (RIPv1) and Version 2 (RIPv2).
RIPv1:-
·
It
is Classfull routing protocol, and thus does not include the subnet mask
with its routing table updates. Because of this, RIPv1 does not support.
·
It
doesn’t support Variable Length Subnet Masks (VLSMs). When using RIPv1,
networks must be contiguous, and subnets of a major network must be configured
with identical subnet masks. Otherwise, route table inconsistencies (or worse)
will occur.
·
It
doesn’t support Triggered Update.
·
RIPv1
sends periodic updates within 30 sec as broadcasts to address 255.255.255.255.
·
It
doesn’t support authentication &
Summarization.
·
It
is default configure in Cisco router.
RIPv2:-
·
It is classless
routing protocol , and thus does include the subnet mask with its
routing table updates.
·
RIPv2
fully supports VLSMs, allowing discontinuous networks and varying subnet masks
to exist. Other enhancements offered by RIPv2 include.
·
Routing
updates are sent via multicast, using address 224.0.0.9.
·
Encrypted
authentication can be configured between RIPv2 routers.
·
Route
tagging is supported.
·
It
does support authentication & Summarization
·
It
does support Triggered Update.
RIPv2 can
interoperate with RIPv1. By default:
•
RIPv1
routers will sent only Version 1 packets.
•
RIPv1
routers will receive both Version 1 and 2 updates.
•
RIPv2
routers will both send and receive only Version 2 updates.
We can
control the version of RIP a particular interface will “send” or “receive.” Unless
RIPv2 is manually specified, a Cisco will default to RIPv1 when configuring
RIP.
AUTONOMOUS SYSTEM:-- A group of networks under mutual
administration control that share the
same routing methodology. Autonomous systems are subdivided by areas and must
be assigned an individual 16-bit number by the IANA. The AS enable the gateway
to decide which routing protocol & table to used.
Range of
ASN. (1 to 65535)
·
PUBLIC ASN (1 - 65511)-- The ASN in the public range are globally unique and may be
announced on the global Internet. ASN are used to uniquely identify
networks or systems of networks which appear to the outside world to be running
a single consistent routing policy.
·
PRIVATE ASN (65512 - 65535)--The private ASN should not be seen on the global Internet
(they shouldn't be announced via your exterior gateway routing protocol).
Private AS numbers are used by ISP's who use BGP confederations. Private AS
numbers are also used to provide an AS number to customers with multiple
connections who have no connections to any other Internet service provider.
DATA
CIRCUIT-TERMINATING EQUIPMENT DCE
is used to provide clocking to DTE equipment.
DCE DATA COMMUNICATIONS EQUIPMENT-- (as defined by the EIA) Electronic
Industries Alliance or data circuit-terminating equipment (as defined by the
ITU-T) International Telecommunication union–Telecommunication: The mechanisms and links of a communications
network that make up the network portion of the user-to-network interface, such
as modems.
The DCE supplies the physical connection to the network,
forwards traffic, and provides a clocking signal to synchronize data
transmission between DTE and DCE devices. Compare with: DTE. The connection to a data network is made
through data communication equipment (DCE) such as a modem, using the clocking
signals generated by that device.
DTE DATA TERMINAL EQUIPMENT:-- Any device located at the user end of a user-network
interface serving as a destination, a source, or both. DTE includes devices
such as multiplexers, routers, protocol translators, and computers.
DTE connect computer
to WAN with the help of DCE. DTE is end user equipment like router, pc. A
device where a communication path begins or end is called DTE.
IGRP
(INTERIOR GATEWAY ROUTING PROTOCOL)
IGRP is a Cisco-proprietary Distance-Vector protocol and
interior gateway routing protocol, designed to be more scalable than RIP, its
standardized counterpart. IGRP adheres to the following Distance-Vector
characteristics:
·
IGRP
sends out periodic routing updates (every 90 seconds).
·
IGRP
sends out the full routing table every periodic update.
·
IGRP
uses a form of distance as its metric (in this case, a composite of bandwidth
and delay).
·
IGRP
uses the Bellman-Ford Distance Vector algorithm to determine the best “path” to
a particular destination.
Other characteristics of IGRP include:
·
IGRP
supports only IP routing.
·
IGRP
is classful routing protocol it is doesn’t support VLSM.
·
IGRP
utilizes IP protocol 9.
·
IGRP
routes have an administrative distance of 100.
·
IGRP,
by default, supports a minimum of 100 hops. This value can be adjusted
to a maximum of 255 hops.
·
IGRP
uses Bandwidth and Delay of the Line, by default, to calculate
its distance metric. Reliability, Load, and MTU are
optional attributes that can be used to calculate the distance metric.
·
IGRP
requires that you include an Autonomous System (AS) number in its
configuration. Only routers in the same Autonomous system will send updates
between each other.
IGRP
TIMERS:-
IGRP has
four basic timers:-
UPDATE
TIMER (DEFAULT
90 SECONDS) :- Indicates how often the router will send out a routing table update.
INVALID TIMER (DEFAULT 270 SECONDS):-
Indicates how long a route will remain in a routing table before being
marked as invalid, if no new updates are heard about this route. The invalid
timer will be reset if an update is received for that particular route before
the timer expires.
A route marked as invalid is not immediately removed
from the routing table. Instead, the route is marked (and advertised) with a
metric of 101 (remember, 100 maximum hops is default), indicating it is
unreachable, and placed in a hold-down state.
HOLD-DOWN TIMER (DEFAULT 280 SECONDS) :- Indicates how long IGRP will “suppress” a
route that it has placed in a hold-down state. IGRP will not accept any
new updates for routes in a hold-down state, until the hold-down timer expires.
A route
will enter a hold-down state for one of three reasons:
·
The
invalid timer has expired.
·
An
update has been received from another router, marking that route with a metric
of 101 (unreachable).
·
An
update has been received from another router, marking that route with a higher
metric than what is currently in the routing table (this is to prevent loops).
FLUSH TIMER (DEFAULT 630 SECONDS):-
Indicates how long a route can remain in a routing table before being
flushed, if no new updates are heard about this route. The flush timer runs concurrently
with the invalid timer, and thus will flush out a route 360 seconds V after
it has been marked invalid.
NOTE:-
IGRP timers
must be identical on all routers on the IGRP network, otherwise massive
instability will occur.
IGRP LOOP AVOIDANCE MECHANISMS
IGRP, as a Distance Vector routing protocol, is susceptible
to loops. How can we prevent this from happening? There are several loop
avoidance mechanisms:
SPLIT-HORIZON:-
Prevents a routing update from being sent out
the interface it was
received on.
It is able to prevent counting to infinity problem over a single link.
Split-
horizon is enabled
by default on Cisco Routers.
ROUTE POISONING :- A router will advertise a route to an
unreachable network with an infinite metric to ensure all routers do not
believe any rumor about the availability of the unreachable network. Poisoned
routes are placed into hold down instead of waiting for the invalid timer to
expire.
It is used to prevent routing loops due to
inconsistent routing updates through alternative or redundant paths.
POISON
REVERSE:-
·
When
the network is stable, routers use split horizon. When a link has failed and a
router received an infinite metric route, the route will be advertised out to all
interfaces (route poisoning), including those prevented by split horizon.
·
This
ensures that all routers on the segment receive the poisoned route and will not
use the invalid route.
·
It
is able to prevent counting to infinity problem.
·
It
is also known as split horizon with poison reverse.
MAXIMUM HOP COUNT:- Hop count metric increases each time
a route passes through a router. It is able
to solve counting to infinity problem by defining a maximum hop count.
This is not a good solution since packets will still loop in the network until
all routers removed or flushed the bad
route from their routing tables.
HOLD-DOWN TIMERS:- Prevents RIP from accepting any new
updates for routes in a hold-down state, until the hold-down timer expires.
TRIGGERED UPDATES:-Without waiting for the regular
scheduled routing update timer to expire, a router will immediately send
out an update as soon as a directly connected
subnet has changed state (up or down), which intends to speed up
convergence time. Also known as flash updates.
Loop-avoidance
features on distance-vector routing protocols are enabled and activated by
default.
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. For
Ex. A router are send update packet using multicast and the packet are
delivered to their neighbor is sequence, however the router didn’t receive the
acknowledgement in a sequential order, then it can re-send the packet unicast.
It is ensured that EIGRP is a reliable transport protocol.
·
EIGRP
routers do not send periodic and full-table routing updates. Updates are
sent when a change occurs, and include only the change.
·
It
send incremental update to their neighbor router
·
EIGRP
modification DV algorithm. It’s provides loop free failover path.
·
EIGRP
is a class full protocol till IOS version 12.4 by default and IOS version
15.0 it is by default classless
protocol, and thus supports VLSMs
·
EIGRP
supports IP, IPX, and Apple talk routing that’s way it is called PDM protocol
dependent module.
·
Default
max path for reach the destination 4. maxi 16 path
·
EIGRP
Use IP Protocol No. 88.
·
EIGRP
applies an Administrative Distance of 90 for routes originating within
the local Autonomous System.
·
EIGRP
applies an Administrative Distance of 5 for summary route.
·
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 255, 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:-It is
used to maintain Neighborship.
1- First it
determined that how many neighbors exist.
2- How many
“hello” or “ack” will be excepted.
3- It will
not receive hello till hold down time then it is erase the neighbors details
from the neighbor table.
4- If it will not receive the hello then it send 16 unicast
message to the neighbor. If neighbor is still un-responsible then it is erase
the neighbors details from the neighbor table.
·
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.
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.
·
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.
NEIGHBORS TABLE CONTAINS:-
A neighbor
table is constructed from the EIGRP Hello packets, which includes the
following information:
I.
IP
address of the neighboring router.
II. Local interface that received the
neighbor’s Hello packet.
III. Up time.
IV. Hold down timer.
V. Sequence number of last received update.
VI. Packet in queue.
VII. Retransmission Time Out (RTO).
VIII.
Smooth
round Trip Time (SRTT)
TOPOLOGY
TABLE CONTAINS:-
i.
Successor
Route
- Feasible Successor Route
ROUTING
TABLE CONTAINS:-
i.
Internal
Route (90 AD)
- External Route (170AD)
- Summary Route (5 AD)
EIGRP
TERMINOLOGY:-
A.
Successor:- A best route to reach
the destination subnet or network.
B.
Feasible Distance:- Calculated
metric of successor is called FD.
C.
Feasible successor:- Another best
route which is provides backup for successor route.
Feasible successor requirement:- A route who’s AD/RD is less then FD of current successor.
D.
Advertise Distance/Reported Distance (AD/RD):-
A router FD
will be called AD/RD for it’s neighbor.
E.
Input Event:- An information which
has capabilities to change the database.
F.
Local Computation:- A term it has
two function
a. If successor goes down, it use
feasible successor.
b. If feasible successor is not
available then it become Active for that route.
Going Active:- It means a router it
sending query to it’s neighbor for a route.
Requirement
for Neighborship:
1. Autonomous System No.
- K Values
- Authentication
- If you are using static neighbor
ship than you have to define static neighbor ship both site.
EIGRP METRICS:-
EIGRP can utilize 5 separate metrics to determine the best
route to a Destination. It is called composite metric. It contain 5 element.
These elements are called K Value.
1)
Bandwidth (K1-Used)– Slowest link in the route
path, measured in kilobits
2)
Load (K2-Not used) – Cumulative load of
all outgoing interfaces in the path, given as a fraction of 255
3)
Delay of the Line (K3-Used) – Cumulative delay of
all outgoing interfaces in the path in tens of microseconds.
4)
Reliability (K4-Not used) – Average reliability
of all outgoing interfaces in the path, given as a fraction of 255.
5)
MTU (K5-Not used) – 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/10] * 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”).
EIGRP
PACKET TYPES:-
EIGRP employs five packet types:
Hello
packets – multicast -------
Update
packets – unicast or multicast RTP
Query
packets – multicast RTP
Reply
packets – unicast RTP
Acknowledgement packets -- unicast -------
HELLO PACKETS:- Hello packet
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:- 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:- 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 :- 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:-
1.
Update
Packets
2.
Query
Packets
3.
Reply
Packets
Hello and Acknowledgments
(ha!) 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:
1) ACTIVE STATE
2) PASSIVE STATE
1) 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. When a successor goes down and route
is reachable through Feasible Successors.
2) ACTIVE STATE:- A route is placed in an Active state when
the Successor and router has no Feasible Successors or Feasible Successors
fail, forcing the EIGRP to send out Query packets and recon verge.
Multiple routes in an Active state indicate an unstable EIGRP
network. If a Feasible Successor exists, a route should never enter an
Active state.
STUCK-IN-ACTIVE
(SIA):-
When a successor goes down and router has no Feasible Successors
router will come in Active state. Routes will become Stuck-in-Active (SIA) when
a router sends out a Query Packet to its neighbor, but does not receive a Reply
packet within three minutes. This state is called Stuck-in-Active
(SIA).
In Stuck-in-Active (SIA)
router breaks neighborship with all pears of neighbors and again reestablished
neighborship.
·
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.
·
Stuck-in-Active (SIA) is not include previous
version of 11.0 IOS. Router send SIA query Don’t receive SIA reply within 3 minutes then route break the neighborship of all pear
and again reestablished neighborship so all route down in 3 min.. In 15.0
Router send SIA query and
after 90 sec receive or not receive SIA
reply don’t break neighborship I am finding that route.
LIMIT
SIA QUERY:-
- Active timer disable --- Only query not wait SIA reply (3 min)
- Summarization----
Save
memory, routing table short, not
forward all route information and query to all router.
- Stub router --- NO query, no wait (3 min)
EIGRP
ADDITIONAL FEATURE:-
- Incremental update– send only changes
occur.
- Multicast
- Unequal load balance -- Best FD multiple by multiplier and we get
product. If another route are lower that product they are eligible for
unequal load balancing.
EIGRP
Load-Balancing
By default, EIGRP will automatically load-balance across
equal-metric routes (four by default, sixteen 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 16
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.
Open
Shortest Path First
OSPF is a standardized IG Classless Link-State routing
protocol, designed to scale efficiently to support larger networks.
OSPF adheres
to the following Link State characteristics:
·
OSPF
send increment update. These update are called LSA.
·
It
is use IP Protocol No. 89.
·
IT
send multicast hello on 224.0.0.5, 224.0.0.6.
·
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.
·
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.
·
OSPF
metric is called Cost.
(100mbps/bandwidth==cost)
The OSPF process builds and maintains three separate tables:
·
Neighbor
table – contains a list of all neighboring routers.
·
topology table –
contains a list of all possible routes to all known networks within an
area.
·
routing table –
contains the best route for each known network.
PROCESS ID--They are locally significant only,
and have no bearing on the structure of any OSPF packet or LSA update. So you
can have a separate process-id on every single router in your network if you so
desire! Cisco routers may have up to 32 simultaneous processes. A single
interface can only belong to a single process
(although you can redistribute to "share").
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.
Hello & Dead
Interval—
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.
OSPF Designated Routers & Backup Designated Routers
DR--- When OSPF
Router are connect to a Multi access
Network then there is a responsibilities of one router who is responsible for
making Adjacency with other router that is called
DR(F/R & Switch).
Ex-- If a link off of Router A in 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 Req.
1. 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.
Default Priority = 1
Maximum Priority = 255
Default priority on Cisco routers is 1.
A priority of 0 router will not participate in DR or BDR election.
2. HIGHER ROUTER ID----Each OSPF router is identified by
a unique Router ID. The Router ID can be determined in one of three
ways:
-
The
Router ID you 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.
NOTES– DR is only used to reduce the no of
adjacencies..
1- Adjacencies without DR & BDR - (n(n-1)/2)
2- Adjacencies with DR & BDR – (n*2—3)
3- Adjacencies with DR only – (n--1)
OSPF Packet Format----
Below list of the 5 types of OSPF packets:
Message Type and Packet Type
Purposes
Type-1 – Hello-- Discovers neighbors, negotiate
capabilities, establishes and maintains
adjacencies between neighbors.
Type-2 – Database Description (DBD) --Elects the Master and Slave,
determines the initial sequence number for database exchange, and summarizes
the LSDB contents using LSA headers during the database exchange process
between routers.
Type-3 – Link-State Request (LSR) --Requests specific LS records (LSAs)
that are seen during the database exchange process.
Type-4 – Link-State Update (LSU) --Sends specifically requested LS
records to a neighbor and sends triggered updates upon a topology change. LSU
packets are also used in the flooding process.
Type-5 – Link-State Acknowledgment (LSAck)--Acknowledges the receipt of LSU
packets. A single LSAck packet can acknowledge multiple LSU packets.
OSPF
Neighbors (continued) Hello contents
OSPF routers will only
become neighbors if the following parameters within a Hello packet are
identical on each router:
Unique
Attribute Common
Attribute
Router ID Priority
Interface & Network ID DR & BDR Information
Area
ID
Area
Type (stub, NSSA, etc.) stub Information
Prefix
(Subnet Mask)
Hello
Interval & Dead Interval
Network
Type (broadcast, point-to-point, etc.)
Authentication
The Hello packets also serve as keepalive 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 Neighbor
States---
Neighbor adjacencies will progress through several states,
including:
Down – When hello is not exchange between 2 ospf router that is called down.
indicates that no Hellos have been heard from the neighboring router.
Attempt– This is valid for Non Broadcast
network(Frame Relay). In this state Router sends unicast hello to its
Neighbors.
Init – When a router receive hello that is
call INIT. indicates a Hello packet has been heard from the neighbor,
but two way communication has not yet been initialized.
2-Way
– When hello is exchange between ospf router that is called 2-way. 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.
Note-- Designated and Backup Designated Routers are elected at this
stage.
ExStart – In this state they are elect master & slave. 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.
MASTER– A
router who sends DBD First.
master req– 1- Highest
priority 2- Higher RID
Exchange – indicates that the routers are exchanging Database
Descriptors (DBDs) master first send then slave . 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.
DBD– It sends brief information of database.
Loading – indicates the routers are finally exchanging actual data LSR,
LSU, 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
Drother to Drother (Two way or neighbor ship only hello
exchange )
Drother to DR/BDR (full sync)
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.
NOTES– When OSPF sends update it add
sequence no. with the update
0x80000001 to 0xffff- ffff Lower is
old update and higher is new update.
When a router receive a update it
check sequence no.
1- If sequence no. higher update will
be accepted.
2- If sequence no. same update will
be ignore.
3- If
sequence no. lower update will be ignore but router will send new update to its
neighbor.
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
1– Cisco specific-- Broadcast Multi-Access,
Point-to-Point, Point-to-Multipoint Non-broadcast
2- Rfc Specific-- Non-broadcast Multi-access
Network (NBMA, Point-to-Multipoint
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.
N/w Type
|
Hello
|
Dead
|
Automatic
Neighbor Ship
|
Manually
Neighbor Ship
|
DR/BDR
Election
|
Broadcast
|
10 Sec
|
40 Sec
|
Yes
|
No
|
Yes
|
Point-to-Point
|
10 Sec
|
40 Sec
|
Yes
|
No
|
No
|
Point-to-MultiPoint
|
30 Sec
|
120 Sec
|
Yes
|
No
|
No
|
Point-to-MultiPoint
Non-Broadcast
|
30 Sec
|
120 Sec
|
No
|
Yes
|
No
|
Non-Broadcast
|
30 Sec
|
120 Sec
|
No
|
Yes
|
Yes
|
OSPF Router
types—
·
Internal Routers – All router interfaces belong to only one Area or regular area is called
Internal router.
Area- Logical grouping of OSPF Router.
Area structure-
1- Backbone Area
(0)--- Area 0 is
backbone area. It provides higher IP packet transmission between regular area.
That is why it’s called Transit area.
2- Regular Area (1
to 65535)-- Off Backbone Area – A part from area
0 all other area is called regular area.
3- Standard Area(single area ) – A “normal” OSPF area. An area which contain entire
OSPF domain itself.
• Backbone Routers – contain at least one interface in
Area 0. A Router is backbone of OSPF Domain is called Backbone Router.
• Area Border Routers (ABRs) – A router which connect
backbone area to regular area contains interfaces in at least two separate
areas
• Autonomous System
Border Routers (ASBRs )– A router which connects OSPF routing domain to
another routing domain. contain a connection to a separate Autonomous
System.
A router can become an
ASBR in one of two ways:
a. By connecting to a separate
Autonomous System, such as the Internet
b. 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.
LSAs Types and the OSPF Topology Database
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 Router ID of router
and 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 (send) to all other routers within the
local (with in ) area.
• Network LSA (Type 2) – It contain the DR Router ID
and Generated by all Designated Routers in OSPF, and contains a list of all
routers attached to the Designated Router.
• Network Summary LSA (Type 3) – when the route of one
area go to another area they go as Summary LSA. Generated (send) 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) – It contain ASBR router
ID. 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) – It contain the external
routes which are redistributed into OSPF. 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. Type 5 LSAs will be flooded to routers of all areas.
·
Group membership LSA- Multicast OSPF (MOSPF) utilizes a Type 6 LSA, but that goes
beyond the scope of this guide.
·
NSSA LSA-- Type 7 NSSA External LSAs Used in NSSA area. It conation external
route.
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
On Serial interfaces, OSPF will use
the configured bandwidth (measured in Kbps) to determine the cost:
Router(config)# interface s0
Router(config-if)#
bandwidth 64
The default cost of an interface can
be superseded:
Router(config)# interface e0
Router(config-if)#
ip ospf cost 5
Changing the
cost of an interface can alter which path OSPF deems the “shortest,” and thus
should be used with great care.
To alter how OSPF calculates its
default metrics for interfaces:
Router(config)# router ospf 1
Router(config-router)#
ospf auto-cost
reference-bandwidth 100
The above OSPF auto-cost command has a value of 100
configured, which is actually the default. This indicates that a 100Mbps
link will have a cost of 1 (because 100/100 is 1). All other costs are based
off of this. For example, the cost of 4 Mbps Token Ring is 25 because 100/4 =
25.
OSPF Area Types--
In order to control the propagation of LSAs in the OSPF
domain, several area types were developed.
Standard
Area(single area ) – A “normal”
OSPF area. An area which contain entire OSPF domain Itself.
Stub Area– It filter the external route and
place them as default route.
Totally Stub Area- It filter the External & inter
Area routes and place them as default routes.
NSSA- Not- so Stub
Area– It allow an
ASBR to send external routes through stub area to backbone area using LSA
7(NSSA LSA)
NOTES- Its filter the external routes
coming from ABR. Is doesn’t generate default route.
Totally NSSA- It allow an ASBR to
send external routes through stub area to backbone area using LSA 7(NSSA LSA)
NOTES- Its filter the external & inter
area routes coming from ABR. Is does generate default route.
Virtual Link– OSPF designing say that all regular area must be connected to
backbone area. If it not possible we have used Virtual link.
STUB area
Limitation- Area 0
can't be stub,, virtual link are not allowed in stub area,,, all router must be
agree that we part of stub area.
Border Gateway Protocol
Border Gateway Protocol
(BGP)
BGP is a standardized exterior gateway
protocol (EGP) classless path vector routing protocol, as opposed to RIP,OSPF,
and EIGRP which are interior gateway protocols (IGP’s). BGP Version 4 (BGPv4) is
the current standard deployment.
PATH
VECTOR—It select the route based on the
AS Path. IT select the route which provides a network at least AS.
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:
1- Multiple connections exist to
external AS’s (such as the Internet) via different providers.
2-Multiple connections exist to
external AS’s through the same provider, but connect via a separate CO or
routing policy.
3-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:
1-iBGP Peers –200-
BGP neighbors within the same autonomous system.
2-eBGP Peers -20–
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—
1-OPEN
2-KEEPALIVE
3-UPDATE
4-NOTIFICATION
BGP forms its peer relationships through a series of messages.
OPEN- Open message
is sent between peers to initiate the session using TCP port 179.
OPEN
message contains several
parameters:
Ø BGP Version – must be the same between BGP peers
Ø Local AS Number
Ø BGP Router ID
Ø Hold-time 180
sec
KEEPALIVE -- 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-- Update messages are used to exchange routes between peers.
When two router become BGP neighborship then they send update m/s to each
other.
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. BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
5
Configuring BGP Neighbors (continued)
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 Holdtime 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
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
6
Viewing BGP Neighbors
To view the status of all BGP neighbors:
RouterB# show ip
bgp neighbors
BGP
neighbor is 172.16.1.2, remote AS 900, external link
Index 1,
Offset 0, Mask 0x2
Inbound
soft reconfiguration allowed
BGP
version 4, remote router ID 172.16.1.2
BGP state
= Established, table version = 27, up for 00:03:45
Last read
00:00:19, hold time is 180, keepalive interval is 60
seconds
Minimum
time between advertisement runs is 30 seconds
Received
25 messages, 0 notifications, 0 in queue
Sent 20
messages, 0 notifications, 0 in queue
Inbound
path policy configured
Route map
for incoming advertisements is testing
Connections
established 2; dropped 1
Connection
state is ESTAB, I/O status: 1, unread input bytes: 0
Local
host: 172.16.1.1, Local port: 12342
Foreign
host: 172.16.1.2, Foreign port: 179
Enqueued
packets for retransmit: 0, input: 0, saved: 0
Event
Timers (current time is 0x530C294):
Timer
Starts Wakeups Next
Retrans 15
0 0x0
TimeWait 0
0 0x0
AckHold 15
13 0x0
SendWnd 0
0 0x0
KeepAlive
0 0 0x0
GiveUp 0 0
0x0
PmtuAger 0
0 0x0
<snip>
To view the status of a specific
BGP neighbor:
RouterB# show ip
bgp neighbors 172.16.1.2
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
7
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.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
8
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.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
9
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 v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
10
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 v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
11
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 v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
12
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.
(Reference: http://www.cisco.com/warp/public/459/29.html)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
13
BGP Attributes
BGP utilizes several attributes
to determine the best path to a
destination.
Well-known attributes
are supported by all implementations of BGP, while optional attributes
may not be supported by all BGP-speaking routers. Several subcategories of
attributes exist:
Well-known Mandatory – Standard attributes supported by all BGP implementations,
and always included in every BGP update.
Well-known Discretionary – Standard attributes supported by all BGP
implementations, and are optionally included BGP updates.
Optional Transitive – Optional attribute that may not be supported by all
implementations of BGP. Transitive indicates that a noncompliant BGP router will forward
the unsupported attribute unchanged, when sending updates to peers.
Optional Non-Transitive - Optional attribute that may not be supported by all
implementations of BGP. Non-Transitive indicates that a non-compliant BGP router will strip
out the unsupported attribute, when sending updates to peers.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
14
BGP Attributes (continued)
The following describes several specific BGP
attributes:
AS-Path (well-known mandatory) – Identifies the list (or path) of traversed AS’s to
reach a particular destination.
Next-Hop (well-known mandatory) – Identifies the next hop IP address to reach a
particular destination.
Origin (well-known mandatory) – Identifies the originator of the route.
Local Preference (well-known,
discretionary) – Provides a preference to
determine the best path for outbound traffic.
Atomic Aggregate (well-known
discretionary) – Identifies routes that have been
summarized, or aggregated.
Aggregator (optional transitive) –
Identifies the BGP router that performed
an address aggregation.
Community (optional transitive) – Tags routes that share common characteristics into communities.
Multi-Exit-Discriminator (MED)
(optional non-transitive) –
Provides a preference to eBGP peers to a specific inbound router.
Weight (Cisco Proprietary) – Similar to Local Preference, provides a local weight to determine the best path
for outbound traffic.
Each attribute is identified by a code:
Origin
AS-Path
Next Hops
MED
Local Preference
Automatic Aggregate
Aggregator
Community
Code 1
Code 2
Code 3
Code 4
Code 5
Code 6
Code 7
Code 8
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
15
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)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
16
Weight
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
(Reference: http://www.cisco.com/warp/public/459/bgp-toc.html#weight)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
17
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 in
(Reference: http://www.cisco.com/warp/public/459/bgp-toc.html#localpref)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
18
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.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
19
AS-Path Filtering
Additionally, routes can be filtered
based on AS-Path values, using an
aspath access-list. This requires the use of regular
expressions:
^ = Start of
a string
$ = End
of a string
. = Any
one character
* = Any
one or more characters, including none
+ = Any
one or more characters
? = Any one character, including none
_ = Serves the function of virtually all of the above
The following examples illustrate the use of regular expressions:
^100_ = learned from AS 100
_100$ = originated from AS 100
^$ = originated locally
.* = matches everything
_100_ = any instance of AS 100
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)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
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.
? (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 v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
21
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)# match ip address 5
RouterB(config-route-map)# set metric 200
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.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
22
MED (continued)
A key aspect to consider when using the MED attribute
is BGP’s method of route selection. Recall that if BGP contains multiple routes
to the same destination, it compares the routes in pairs,
starting with the newest entries and working towards the oldest entries.
This can lead to sub-optimal routing, depending on the
order of routes in the BGP routing table. BGP employs two MED-related commands
to alleviate potential sub-optimal routing selections. The bgp deterministic-med command forces the MED value to be compared, when
multiple routes to the same network are received via multiple routers from the same AS, regardless of the order of routes in the BGP routing
table.
RouterE(config)# router
bgp 100
RouterE(config-router)# bgp deterministic-med
The bgp
deterministic-med command is disabled by default.
If used, the command should be enabled on all
routers within the AS.
The bgp always-compare-med command
forces the MED value to be compared, when multiple routes to the same network
are received via multiple routers from different AS’s, regardless of the order of
routes in the
BGP routing table.
RouterE(config)# router
bgp 100
RouterE(config-router)# bgp always-compare-med
The bgp
always-compare-med command is disabled by default.
Thus, by default, the MED value is not compared between paths from different AS’s.
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094925.shtml;
http://www.cisco.com/warp/public/459/bgp-toc.html#metricattribute)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
23
MED (continued)
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.
BGP v2.01 – Aaron Balchunas
* * *
24
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.
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#four;
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#communityattribute)
BGP v2.01 – Aaron Balchunas
* * *
25
Communities (continued)
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
BGP v2.01 – Aaron Balchunas
* * *
26
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.1.0/24
172.16.2.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 summaryonly
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 summaryonly 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 summaryonly suppress-map
SUPPRESS as-set
BGP v2.01 – Aaron Balchunas
* * *
27
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 v2.01 – Aaron Balchunas
* * *
28
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
Network
Next Hop Metric LocPrf Weight Path
*>
192.168.1.0 172.16.1.2 0 100 0 900 i
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 v2.01 – Aaron Balchunas
* * *
29
BGP Backdoor
Recall that an external BGP route has an
Administrative Distance (AD) of 20, which is less than the default AD of IGP’s, such as
OSPF or EIGRP. Under certain circumstances, this may result in sub-optimal
routing. 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
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#bgpbackdoor)
BGP v2.01 – Aaron Balchunas
* * *
30
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
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their
respective owners.
This material may be copied and used freely, but may not be
altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may
be found at http://www.routeralley.com.
No comments:
Post a Comment