Warning and Disclaimer

This book is designed to provide information about interview questions for networking profile for
freshers and experienced. Every effort bas been made to make this book as complete and as
accurate
as possible, but no warranty or fitness is implied. The authers have neither liability nor responsibility
to
any person or entity with respect to any loss or damage arising from the information contained in
this
book.

Feedback Information
Reader’s feedback is a natural continuation of this process. If you have any comments regarding how
we
could improve the quality of this book, or otherwise alter it to better suit your needs, you can
contact us
through email at cisconetworklearning@gmail.com.
You can also visit to my youtube channel: www.youtube.com/cisconetworklearning

Dedications
I would like to dedicate this book to my wife for her love, encouragement and continuous
support.

Acknowledgement
First, I would like to thank God for giving me the opportunity and ability to write, teach, and do what
I
truly enjoy doing. Also , I would like to thank to my family for constant
encouragement and help.

BGP is an inter-domain routing protocol (IDRP), which is also known as an EGP.

1. BGP version 4 is the latest version of BGP.

2. AS: is a set of routers under a single technical administration, using an interior
gateway protocol and common metrics to determine how to route packets within the
autonomous system, and using an inter-autonomous system routing protocol to
determine how to route packet to other AS. AS might use more than one IGP.
3. The AS is a 32 bit number, with a range of
4. 1 to 65535. 64512 to 65535 are reserved for private use.
5. A router consists of two logical components:
a. Control Plane: is responsible for building a RIB.
b. Forwarding plane: can use to classify and forward packets.
6. BGP support VLSM & carrying a subnet mask.
7. BGP MTU: BGP support for TCP path MTU discovery introduces the ability for BGP
to automatically discover the best TCP path MTU for each BGP session. TCP path
 MTU discovery is enabled by default for all BGP neighbour session, but you can
disable, and subsequently enable, the TCP path MTU globally for all BGP session or
for individual BGP neighbour session. Commands are:
a. No BGP Transport path-MTU-Discovery
b. no neighbor {ip-address | peer-group-name} transport {connection-mode | path-mtu-
discovery}.
8. BGP is also a distance vector protocol with many enhancements, it is also called a
path vector protocols.
9. The network command controls what networks are originated by this box. This is a
different concept from what you are used to configuring with IGRP and RIP. With
this command we are not trying to run BGP on a certain interface, rather we are trying
to indicate to BGP what networks it should originate from this box. The mask portion
is used because BGP4 can handle subnetting and supernetting. A maximum of 200
entries of the network command are accepted. The Network command will work if the
network you are trying to advertise is known to the router, whether connected, static
or learned dynamically.
1. BGP does not look at speed for the best path. Rather; BGP is a policy based routing
protocol that allows an AS to control traffic using multiple BGP attributes.
2. When BGP is running between routers in different AS, it is called EBGP. When BGP
is running between routers within same AS it is called IBGP. Generally EBGP peers
should be directly connected (except in case of EBGP Multi-hop) but IBGP routers do
not have to be directly connected, as long as there is some IGP running that allows the
two neighbours to reach one another.
3. Any two routers that form a TCP connection in order to exchange BGP routing
information are “peers” or “Neighbours”. BGP peer initially exchange the full BGP
routing tables. After this exchange, the peers send incremental update as the routing
table change. BGP keeps a version number of the BGP table. The version number is
the same for all BGP peers. The version number changes whenever BGP updates the
table with routing information change. You can see the same by Show IP BGP
Neighbour command in which the BGP state always should be established.
4. BGP routers exchange reach-ability information, called path vectors, made up of path
attributes. The path vector information includes a list of the full path of BGP AS
number (hop by hop) necessary to reach a destination network. Other attributes
includes the IP address to get to the next AS (The next hop attributes) and how the
network at the end of the path were introduced into BGP (The origin code attribute).
5. BGP AS path is guaranteed loop free: A router running BGP does not accept a routing
update that already includes its AS no. in the path list, because the update has already
passed through its AS, and accepting it again will result in a routing loop.
a. Route Loops are very easily detected with the AS Path attribute.
6. When to use BGP.
a. The Autonomous system allows packet to transit through it to reach other AS.
b. The AS has multiple connections to other AS.
c. You should implement BGP only when a sound engineering reasons, like IGPs
do not provide the tools necessary to implement the required routing policies
or when the sized of routing tables cannot be controlled with summarization.
d. Multi-homing is for redundancy and increased routing efficiency, not load
balancing.
7. When not to use BGP.
a. A single connection to the internet or another AS.
b. Lack of memory or processor on edge router.
 c. When the redundant link is used only for backup, there is again no call for
BGP.
d. Limited understanding of BGP protocol.
8. BGP use the TCP as its transport protocol, for connection oriented delivery.
9. BGP information is carried inside TCP segments using protocol 179.
10. BGP sends keep-alive messages in every 60 seconds, similar to the hello message like
OSPF.
11. Any routers that run BGP are called a BGP speaker. Known Also BGP neighbour.
12. To avoid the routing loops with in an AS, BGP specifies that routes learned through
the IBGP are never propagated to other IBGP peers. IBGP does not advertise 3rd party
routes to other IBGP peers. IBGP peers will not advertise routes learned by one IBGP
peer to another IBGP peer. This is because IBGP has no loop prevention, so this
solves it. Confederation and route reflector are use to address IBGP full mesh
constraints. IBGP does not use AS_Path as a loop detection method. Instead, IBGP
uses the full mesh requirement.
13. IBGP session must be fully meshed.
14. EBGP AD = 20 ; IBGP AD = 200
15. A path is not a valid candidate in the best path selection process if it meets any of the
following conditions:
a. The path next hop is unreachable
b. The path is not synchronized, and synchronization is enabled
c. The path is denied by inbound BGP policies, and inbound soft reset is
configured.
d. The route is dampened.
16. The BGP synchronization rule states that before a route learned from an IBGP
neighbour is entered into the IGP routing table or is advertised to a BGP peer, the
route must first be known via IGP.

Next, suppose salt lake learns a route to 196.223.18.0/24 from AS 500 and advertise the route
over the IBGP connection to Provo, using a next-hop-self policy to change the Next Hop
attribute to its own router ID. Provo then advertises the route to AS 700. Routers in AS 700
now begin forwarding packet destined for 196.223.18.0/24 to Provo. Here is where things go
wrong. Provo does a route lookup for 196.223.18.0/24 and sees that the network is reachable
via salt lake. It then does a lookup for salt lake’s IP address and sees that it is reachable via
next hop router, Ogden. So the packet destined for 196.223.18.0/24 is forwarded to Ogden.
But the external router is shared between Salt lake and Provo via IBGP; the OSPF routers
have no knowledge of external routes. Therefore, when the packet is forwarded to Ogden,
that router does a route lookup and does not find an entry for 196.223.18.0/24. The Router
drops the packet and all subsequent packets for that address. Traffic for the network
196.223.18.0/24 is black holed.
Synchronization prevents packets from being black holed with in a transit AS by an IGP with
insufficient information. If the OSPF routers know about the external routes, the situation just
described will not happen.
Synchronization is a somewhat antiquated feature of BGP that assumes redistribution of
routes into the IGP.
The Moral of the story is that for IBGP to work correctly, one of two configuration option
must be performed:
a. The external routes must be redistributed into the IGP to ensure that the IGP can
synchronize with BGP. The drawback to this approach is that if you are taking a large
number of routes from BGP, such as full internet routing table, you are placing a huge
processing and memory burden on the IGP routers.
b. The IBGP routers must be fully meshed, and synchronization must be disabled. Every
router then has knowledge of the external routes via BGP, and disabling
synchronization allows the routes to be entered into the routing table without having
to first inform the IGP. The drawback to this approach is that in an AS where there are
more than a few routers, peering every router with every router become an
administratively challenge. Two tools for controlling the full IBGP mesh requirement,
route reflectors and confederations.
c. What is IGP/BGP synchronization, and why is it important? : IGP synchronization is
a rule whereby a BGP router cannot advertise a transit route to an EBGP peer unless
the route is found in the IGP routing table. If a BGP router forwards a transit packet to
an IBGP peer via an IGP router, and the IGP router does not know the route, the
packet is dropped.
d. Under what circumstances can you safely disable IGP/BGP synchronization? : You can
safely turn off IGP synchronization if the IBGP peers in an AS are fully meshed, or when the
AS is not a transit AS.

17. BGP tables:

a. BGP table: BGP tables are separate from the IP routing table in the router. The
Router offers the best route from the BGP table to IP Routing table.
b. BGP topology table:
c. BGP topology database
d. BGP routing table
e. BGP forwarding database

18. BGP message types:

a. Open: After a TCP connection established, the first message sent by each side
is an open message. If an open message is acceptable, a keep-alive message
confirming the open message is sent back by the side that received the open
 message. When the open is confirmed the BGP connection is established, and
update, keep-alive, and notification message can be exchanged. The open
message includes the BGP version number, AS No. , Hold Time, BGP
identifier (Router ID), Optional Parameters (Authentication, Multiprotocol
support).
b. Keep-alive: If a router accept the parameter specified in its neighbour’s open
message. It responds with a keep-alive.
c. Update: An update message has information on one path only. Multiple paths
require multiple messages. The update message advertises feasible routes,
withdrawn routes, or both. The update message includes the NLRI, path
attributes, and withdrawn routes.
d. Notification: A BGP router sends a notification message when it detects an
error condition. The BGP router closes the BGP connection immediately after
sending the notification message. Notification message includes an error code,
an error sub-code and data related to error.

19. An open message includes the followings:

a. Version:
b. My Autonomous system
c. Hold time: Default 180 seconds
d. BGP router identifier: (Router ID)
e. Optional Parameter this parameter is type’s length and value (TLV). An
example of an optional parameter is session authentication.

20. An update message might include the following fields.

a. Withdrawn routes: A list of IP address prefixes for routes that are being
withdrawn from service, if any.
b. Path Attributes: The AS Path, Local Preference, and so forth.
c. Network layer reach ability information: (NLRI): A list of networks that can
be reached by this path.
21. BGP Neighbour state:
a. Idle: BGP always begin in the idle state, in which it refuses all incoming
connections. When a start event occurs, the BGP process initialize all BGP
resources, starts the connection retry timer (60 Seconds), initialize a TCP
connection to the neighbour, listen for a TCP initialization from the neighbour
and change its state to connect.
b. Connect: In this state, the BGP process is waiting for the TCP connection to
be completed. If the TCP connection is successful, the BGP process clear the
connect retry, completes initialization, sends an open message to the
neighbour, and transition to the open state. If the TCP connection is
unsuccessful, the BGP process continues to listen for a connection to be
initiated by the neighbour, reset the connect retry timer, and transition to the
active state.
c. Active: In this state, the BGP process is trying to initiate a TCP connection
with the neighbour. If the TCP connection is successful, the BGP sends an
open message to the neighbour, and transition to open sent. The hold timer is 4
minutes.
 d. Open Sent: An open message was sent, with the parameter for the BGP
session.
e. Open Confirm: The Router receives agreement on the parameter for
establishing a session.
f. Established: peering is established and routing begins.
22. BGP attributes types:
a. Well Known mandatory: A well known mandatory attribute must appear in all
BGP update message.
b. Well known discretionary: attributes does not have to be present in all BGP
updates message. In other words, it is recognized by all BGP implementation
but does not have to be in every update message.
c. Optional transitive: Attributes that are not well known are called optional.
BGP router that do not implement an optional transitive attribute should pass it
to other BGP routers untouched and mark the attribute as partial.
d. Optional non-transitive: BGP Routers that do not implement an optional non-
transitive attribute must delete the attribute and must not pass it to the other
BGP Routers.
23. Well known attributes:
a. AS Path: The AS Path attribute is the list of AS number that a route has
traversed to reach a destination, AS Path lists in reverse order the AS traversed
by a prefix, with the last AS placed at the beginning of the list. The primary
purpose of the AS Path is to provide loop prevention for inter AS routing.
b. Next Hop: It indicates the next hop IP address that is to be used to reach
destination.
c. Origin: It defines origin of the path information. These are IGP, EGP and
incomplete.
24. Well Known discretionary:
a. Local Preference
b. Atomic Aggregate
25. Optional Transitive attributes
a. Aggregator
b. Community
26. Optional Non transitive
a. MED
b. Originator-ID
c. Cluster List

27. In addition, Cisco has defined a weight attributes for BGP.

28. Origin Attributes: The origin attributes can be one of three values:
a. IGP: the route is interior to the originating AS. This normally happens when a
network command is used to advertise a route via BGP. An origin of IGP is
indicated with an [I] in the BGP table. An IGP origin gets the highest
preference.
b. EGP: The Route is learned via EGP. This is indicated with an e in the BGP
table. EGP is preferred second to IGP.
c. Incomplete: The Route’s origin is unknown or is learned via some other
means. This usually occurs when a route is redistributed via BGP.
29. Local Preference: it indicates to the routers in the AS which path is preferred to
exit the AS. If an internal BGP speaker receives multiple routes to the same
 destination, it compares the local preference for an advertised route. A path is the
higher local preference is preferred. LP is an attribute that is configured on a router
and exchange only among routers within the same AS. It is not passed to other AS.
The default value for LP is 100. The local preference attribute effect only traffic
leaving from the AS.

30. Next Hop Attribute: It described the IP address of the next hop router on the path to
the advertised destination. The IP address described by the BGP next hop attribute is
not always the address of a neighbouring router. The following rules apply:
a. If the advertising router and receiving router are in different AS (EBGP), the
next hop is the IP address of the advertising routers interface.
b. If the advertising router and the receiving router are in the same AS (Internal
peer), and the NLRI of the update refers to a destination within the same AS,
the next hop is the IP address of the neighbour that advertised the route.
c. If the advertising router and the receiving router are in the same AS (Internal
peer), and the NLRI of the update refers to a destination in a different AS, the
next hop is the IP address of the external peer which the route was learned.
d. For IBGP, the protocol states that the next hop advertised by EBGP should be
carried into IBGP.
 Because the IP address does not belong to one of the router’s directly
connected subnets, the router must then look up the route to 172.16.83.2. That
route learned via IGP, indicates a next hop of 172.16.101.1. The packet can
now be forwarded. This example is very important for understanding the
dependency of IBGP on the IGP.

The network 192.168.5.0, to which the next hop belongs, is not part of AS
509. Unless the AS border router advertises the network into AS 509, the IGP
and hence the internal peers will not know about this network. And if the
network is not in the routing tables, the next hop address for 207.135.64.0/19
is unreachable, and packet for that destination dropped. In fact although the
route to 207.135.64.0/19 is installed in the internal peers BGP table it is not
installed in the routing table, because the next hop address is invalid for that
router. The solution is to use a configuration option to cause the AS border
router in AS 509 to set its own IP address in the next hop attribute, in place the
IP address of the external peer. The internal peers would then have a next hop
router address of 172.16.83.2 which is known to the IGP. This configuration
option is called the next-hop-self.

31. BGP Next HOP with multi-access network:

 a. Assume that RTC and RTD in AS300 are running OSPF. RTC is running BGP
with RTA. RTC can reach network 180.20.0.0 via 170.10.20.3. When RTC
sends a BGP update to RTA regarding 180.20.0.0 it will use as next hop
170.10.20.3 and not its own IP address (170.10.20.2). This is because the
network between RTA, RTC and RTD is a multiaccess network and it makes
more sense for RTA to use RTD as a next hop to reach 180.20.0.0 rather than
making an extra hop via RTC.
b. RTC will advertise 180.20.0.0 to RTA with a NextHop = 170.10.20.3.
32. BGP Next Hop Frame Relay:
a. If the common media as you see in the shaded area above is a frame relay or any
NBMA cloud then the exact behaviour will occur as if we were connected via
Ethernet. RTC will advertise 180.20.0.0 to RTA with a next hop of 170.10.20.3. The
problem is that RTA does not have direct PVC to RTD, and cannot reach the next
hop. In this case routing will fail. In order to remedy this situation a command called
Next-Hop-self is created.
b. RTC#
c. router bgp 300
d. neighbor 170.10.20.1 remote-as 100
e. neighbor 170.10.20.1 next-hop-self
f. RTC will advertise 180.20.0.0 with a NextHop = 170.10.20.2
33. Confederation: One way to reduce the IBGP mesh is to divide an AS into multiple sub
AS and group them into a single confederation. To the outside world, confederation
looks like a single AS. Each Sub AS is fully meshed within itself. And has a few
connections to other sub AS in the same confederation. When configuring a BGP
confederation, you specify a confederation identifier.
a. BGP confederation identifier ……. (Real AS number)
b. BGP confederation peers …………….. (Sub AS number)
34. Community Attribute: BGP communities are one way to filter incoming or outgoing
routes. BGP communities allow routers to tag routes with an indicator (The
Community) and allow other routers to make decision based on that tag. Communities
are not restricted to one network or one AS, and they have no physical boundaries.
Communities are optional transitive attributes. If a router does understand the
concept, it defer to the next routers. The community attributes is a set of four octet
values. RFC 1997 specifies that the first two octet are the AS and the last two octet
are an administratively defined identifier, giving a format of AA:NN. The default
Cisco format, on the other hand, is NN:AA. You can change this default to the RFC
1997 format with the command IP BGP community new-format. The well known
attributes are:
a. Internet: The internet community does not have any value; all routes belong to
this community by default. Received routes belonging to this community are
advertised freely.
b. None: Apply no community attribute when you want to clear the communities
associated with a route.
c. No-Advertise: Do not advertise this route to any peer, internal or external.
d. No-Export: Do not advertise to external BGP (EBGP) peers. Keep this route
within an AS. If a confederation is configured, the route cannot be advertised
outside of confederation.
e. Local AS: Use in confederation scenario to prevent sending packets outside
the local AS.
35. You can configure communities in three different formats called decimal,
hexadecimal, and AA:NN. By default, IOS uses the older decimal format. In order to
configure and display in AA:NN, where the first part is the AS number and the second
part is a 2−byte number, issue the ip bgp−community new−format global
configuration command.
36. Community Lists: are used to identify and filter routes by their common community
attributes. There are two forms of community lists: numbered and named. Within each
category, there are also standard and expanded formats. A standard formats allows
actual communities values or well known constants, and an expanded format allows
communities to be entered as a regular as a regular expression string. There is a limit
 of 100 for either format of the numbered lists (1-99 for standard and 100 to 199 for
the expanded format), but named lists have no limit. Formats are as follows:
a. Standard: IP COMMUNITY-LIST ….. [PERMIT|DENY] COMMUNITY-
NUMBER
b. EXPANDED: IP COMMUNITY-LIST ….. [PERMIT|DENY] REGULAR-
EXPRESSION
c. STANDARD NAMED: IP COMMUNITY-LIST STANDARD
………(NAME) [PERMIT|DENY] COMMUNITY-NUMBER
d. Expanded named: IP COMMUNITY-LIST EXPANDED …. (NAME)
[PERMIT|DENY] REGULAR-EXPRESSION
1. MED: also called the metric, the MED is displayed in the metric column. The MED
indicates to external neighbours the preferred path into an AS. A lower metric value is
preferred. This is a dynamic way for an AS to try to influence another Autonomous-
System as to which way it should choose to reach a certain route, if there is multiple
entry point into the AS. Unlike LP, the MED is exchanged between AS.
2. MED influence inbounds traffic to an AS, whereas LP influences outbound
traffic from an AS.
3. By default, the MED comparison is done only if neighbour AS is the same for all
route considered. For the routers to compare metric from neighbour coming from
different AS, the BGP always-compare-med router configuration command must be
configured on the routers.

4. Weight: The Weight attribute is a cisco defined attribute used for the path selection
process. The weight attribute is configured locally and provides local routing policy
only: it is not propagated to any BGP routers. Router with the highest weight is
preferred when multiple routes to the same destination exist. The weight can have a
value from 0 to 65535. Paths that the router originates have a weight of 32768 by
default, and other paths have a weight 0 by default.
5. The weight attribute applies when using one router with multiple exit points out of an
AS, as compared to the LP attributes, which is used when two or more router provide
multiple exit point.
6. Weight & Local Preference applied on inbound & traffic affected for outbound.
7. AS Path & MED applied on Outbound and traffic flow effected for INbound.
8. The following process summarizes how BGP chooses best path on a cisco router.
a. Prefer the route with the highest weight.
 b. If multiple routes have same weight, prefer the route with the highest local
preference.
c. If multiple routes have same LP, prefer the route that was originated by the
local router. (A locally originated route has a next hop of 0.0.0.0 in the BGP
table.)Here is the complete order with decreasing preference default originate
(configured per neighbour), default information originate (configured per
address family), network, redistribute, aggregate address.
d. If none of the local routes were originated by the local routers, prefer the route
with the shortest AS path. However, the configuration of BGP best path as-
path ignore (a hidden command) bypasses this step.
e. If AS path length is the same, prefer the lowest origin code
(IGP<EGP<Incomplete).
f. If all origin code is the same, prefer the path with lowest MED.
g. If the routes have the same MED, prefer external path (EBGP) over internal
path. (BGP Backdoor)
h. If synchronization is disabled (Default) and only internal paths remains prefer
the path through the closest IGP neighbour. This means that the router prefer
the shortest internal path within the AS to reach the destination.
i. For EBGP paths, select the oldest route to minimize the effect of routes going
up a down (flapping).
j. Prefer the route with the lowest neighbour BGP router ID value.
k. If the BGP router ID is the same, prefer the route with lowest neighbour IP
address.
9. Multiple path selection: The maximum path ….. (Path) router configuration command
for BGP works if your routers have multiple parallel paths to different routers in the
same Remote AS.
10. The Border Gateway Protocol (BGP) Link Bandwidth feature is used to advertise the
bandwidth of an autonomous system exit link as an extended community. This feature
is configured for links between directly connected external BGP (eBGP) neighbors.
The link bandwidth extended community attribute is propagated to iBGP peers when
extended community exchange is enabled. This feature is used with BGP multipath
features to configure load balancing over links with unequal bandwidth. The
prerequisite for the same is:
a. BGP load balancing or multipath load balancing must be configured before
this feature is enabled.
b. BGP extended community exchange must be enabled between iBGP
neighbors to which the link bandwidth attribute is to be advertised.
c. Cisco Express Forwarding (CEF) or distributed CEF (dCEF) must be enabled
on all participating routers.
d. This will work only for IPV4 & VPNV4
e. What is the command for the same?
1. Peer Group: In BGP many neighbour are often configured with same update policies.
On a Cisco IOS router, neighbour with the same update policies can be grouped into
peer group to simply configuration and more importantly, to make updating more
efficient and improve performance. A neighbouring router can be part of only one
group.
2. EBGP Multi-hop: This feature allows the router to accept and attempt BGP
connection to external peers residing on network that are not directly connected. This
increase the default of one hop for EBGP peers by changing the default TTL value of
 one and therefore routers to use loopback address. By default TTL is set to 255 with
this command. IBGP does not require the same.
3. Next Hop self: router configuration command is used to force BGP to use the source
IP address of the update as the next hop for each network it advertise to the
neighbour, rather than letting the protocol choose the next hop address to use.
4. Using a redistribute command in BGP result in incomplete origin attribute for the
route.
5. BGP by default provide auto summary.
6. BGP support MD5 authentication.
7. There are three ways to trigger an update in BGP.
a. Hard reset: A hard reset means that the router issuing command will close the
appropriate TCP connection, re-establish those TCP session as appropriate,
and resend all information to each of the neighbour affected by particular
command.
b. Soft Reset: It does not reset the TCP session. Instead the router creates a new
updates and sends the whole table to the specified neighbour.
c. Route Refresh:
8. Outbound BGP soft configuration does not have any memory overhead. This
command is highly recommended when you are changing an outbound policy but
does not help if you are changing an inbound policy.
9. The soft in option generates new inbound updates without resetting the BGP session,
but it can be memory intensive. BGP does not allow a router to force another BGP
speaker to resend its entire table.
10. To determine whether a BGP router support this route refresh capability, use the show
IP BGP neighbour command. The following message is displayed in the output when
the router support route refreshes capability. (Received Route refresh capability from
peer).
11. BGP Commands:
12. BGP Show & Debug commands:
a. Show IP BGP neighbour ….. (address) received routes. Display all received
routes both accepted and rejected from the specified neighbour.
b. Show IP BGP neighbour ….. (address) routes: This output is the subset of
above.
c. Show IP BGP: Displays entries in the BGP table.
d. Show IP BGP neighbour ….. (address) advertised routes: Display all BGP
routes that have been advertised to neighbours.
e. Show IP BGP Neighbour: Command output contains details about the peer
connection with the neighbour. It will show BGP Version, BGP State,
Keepalive timing, Hold Time,
f. Show IP BGP rib failure: Display BGP routes that were not installed in the
routing information base and the reason that they were not installed.
g. Show IP BGP summary: Display the status of all BGP connections.
h. Debug IP BGP dampening: BGP Dampening
i. Debug IP BGP Events: Command displays the states of the BGP Finite
Machine.
j. Debug IP BGP keepalive
k. Debug IP BGP updates
13. What is a provider-independent address space, and why can it be advantageous to
have one? : A provider-independent address space is assigned by the regional IP
address registry rather than as part of a service provider's CIDR block. It proves
 useful if an AS is multi-homed to different service providers. It is also useful because
it is portable. That is, the owners of the address space can change ISPs without having
to re-address.
14. What is a routing policy? : A routing policy is a predefined set of rules for handling
incoming and outgoing routes. Typical tools for setting routing policies are
redistribution, route filters, and route map.
15. In what state or states can BGP peers exchange Update messages? : BGP peers can
exchange Update messages only when both are in the Established state.
16. What is NLRI? : Network Layer Reach ability Information is the IP address prefix or
prefixes advertised in a BGP Update.
17. What is the purpose of the AS_PATH attribute? : The AS_PATH attribute describes
the AS numbers that a received Update has crossed after it left the originating router.
This information can be used to The AS_PATH attribute describes the AS numbers
that a received Update has crossed after it left the originating router. This information
can be used to determine the shortest inter-AS path, and it is also used to detect
routing loops.
18. What are the different types of AS_PATH? : AS_PATH types are AS_SEQUENCE,
AS_CONFED_SEQUENCE, AS_SET, and AS_CONFED_SET.AS_SEQUENCE is
an ordered set of AS numbers, and AS_SET is an unordered set of AS
numbers.AS_CONFED_SEQUENCE and AS_CONFED_SET are the same as
AS_SEQUENCE and AS_SET but are used only within BGP confederations.
19. What attribute or attributes are useful if a BGP speaker originates an aggregate route?
: THE ATOMIC_AGGREGATE informs downstream routers that a loss of path
information has occurred due to aggregation. And the AGGREGATOR attribute
indicates where the aggregation occurred.

20. Aggregation Example:

a. There are two ways to create an aggregate address under BGP. The first is to
create a static entry in the routing table for the aggregate address and then
advertise it with the network command.
b. Router BGP 100
c. Network 192.168.192.0 mask 255.255.248.0
d. IP route 192.168.192.0 255.255.248.0 null 0
e. The static route is pointed at the null interface because the aggregate itself is
not a legitimate end destination.
f. The second way is to use the aggregate-address command.
g. Aggregate-address 192.168.192.0 255.255.248.0 summary-only
 h. This suppression results from the summary-only option used with the
aggregate-address command. Without that option, both the aggregate and the
more specific route are advertised.
i. You may use attribute map option with aggregate address command. These
options enable you to change the attributes of the aggregate route.
j. Aggregate-address ……… (Address)….. (Mask) as-set: This command
provides the path in the routing update.
k.

21. What is a BGP administrative weight? : A BGP administrative weight is a Cisco-

specific parameter that can be assigned to routes within a single router. The higher the
weight, the more preferable the route. Weights are local to the router and are not
advertised to peers.
22. Given an EBGP route and an IBGP route to the same destination, which route will a
BGP router prefer? : If the weights, LOCAL_PREFs, AS_PATH lengths, ORIGIN
codes, and MEDs are equal, EBGP routes are preferred over IBGP routes.
23. What is route dampening? : Route dampening is a mechanism by which BGP routes
are assigned a penalty for changing state. The more often the state changes (the route
flaps), the greater the accumulated penalties. If the penalties exceed a certain
threshold, the route is suppressed for a time. As a result, unstable routes have less
adverse effect on the BGP internetwork. Route Oscillation is the same but it happens
periodically. In other word route dampening is a method created to stop unstable routs
from being forwarded throughout an internetwork.
24. Define the penalty, suppress limit, and reuse limit and half-life as they apply to route
dampening. : The penalty is a value assigned to a route by the route-dampening
mechanism each time the route changes state. The suppress limit is a threshold that, if
exceeded by a route's accumulated penalties, signifies that the route should not be
advertised. Reuse limit is a threshold that, if a suppressed route's accumulated penalty
falls below it, signifies that the route can again be advertised. The half-life is the rate
at which a route's accumulated penalties are reduced. At the end of each half-life, the
penalty is reduced by half.
25. What is a route reflector? What is a route reflection client? What is a route reflection
cluster? : A route reflector, Routes from one peer are advertised, or reflected, to the
other peers. To avoid possible routing loops or other routing errors, the route reflector
 cannot change the attributes of the routes it receives from clients. As a result, the
number of peering sessions is reduced from what would be required if the IBGP peers
were fully meshed. A route reflection client is an IBGP router that has peered with a
internal route reflector. A route reflection cluster is a route reflector and its clients. A
cluster can have more than one route reflector, but all the clients in the cluster must be
peered with all the route reflectors in the cluster. By default, the next hop attribute is
not changed when a prefix is reflected by route reflector. However, you can issue the
neighbor next−hop−self command in order to change the attribute of the next hop for
prefixes reflected from an eBGP peer to any route reflector client. The concept of
clients and non clients is always in the context of the RRs that serve or do not serve
them. A client of one RR can be an RR of another client. A non-client with respect to
one RR can be an RR of another client. Route reflection provides another scalability
feature an RR reflect only the best path of each prefix. When an RR receives multiple
paths for the same destination, it first steps through the path selection process to
determine the best path for that destination. It then reflects the best path. Abstraction
of routing information by RRs reduces the size of the BGP RIB in the domain.
a. If a route is received from non-client peer, reflect to client only.
b. If a route is received from a client peer, reflect to all non-client peers and also
to client peers. Except the originator of the route.
c. If a route is received from an EBGP peer, reflect to all client and non-client
peers. An RR always advertises to EBGP peers.
d. The combination of the RR and its client is called cluster.
26. Loops: There is two types of loops: Routing information & Routing. With a routing
information loop, the reachability information is received and accepted by a router
that has advertised the information. This type of loop is relevant to a routing protocol,
such as BGP. Routing information can cause suboptimal routing and routing loops
and can waste system resources. Routing loops, can directly affect the forwarding
plane. A routing loop occurs when a device receives the same packets that were
originally transmitted from that same device.
27. Clustering: Clustering is introduced to provide redundancy in an RR environment. In
a traditional clustering design, multiple RRs are used to serve one or more clients.
These RRs are configured with an identical Cluster_ID, which is a 4 byte BGP
attribute that commonly takes the form of an IP address and defaults to the BGP
router ID. If two routers share the same Cluster_ID they belong to the same cluster.
An advertisement that bears the same Cluster_ID is ignored by receiving RR in the
same cluster.
28. Originator_ID: This is an optional, non transitive BGP attribute that is four bytes long
and is created by a RR. This attribute will carry the router ID of the originator of the
route in the local AS. Thus, due to poor configuration, if the routing information
comes back to the originator, it will be ignored.
29. Cluster_List: The combination of RR and its clients called cluster. A cluster list is a
sequence of cluster-ids that the route has passed. The Cluster_List is another BGP
path attribute that helps break the routing information loop in an RR environment. It
records the cluster in the reverse order the route has traversed. If the local Cluster_ID
is found in the list, the route is discarded. Unlike the Originator_ID, the Cluster_List
is used only by RRs in loop prevention because a client or non-client has no
knowledge of which cluster it belongs to.
a. BGP route-reflector ….. 10 (Cluster ID No.). This command is used to provide
cluster ID & will be used on RR.
 b. The two attributes that are used to prevent potential information looping: the
originator ID and the cluster List.
30. What is a BGP confederation? : A BGP confederation is a large AS that has been
subdivided into a group of smaller autonomous systems for easier manageability.
eBGP sessions between confederation sub−AS do not modify the next hop attribute.
31. Can route reflectors be used within confederations? : Yes.
32. What is the purpose of the next-hop-self function? Are there any reasonable
alternatives to using this function? : next-hop-self tells a router to change the
NEXT_HOP attribute of routes received from an external peer to its own IP address.
This function is used when the IGP has no knowledge of the external next-hop
address. An alternative method is to run the IGP passively on the external link so that
it knows the subnet on which the external next-hop address resides.
33. RIB Failure: When BGP tries to install the best path prefix into Routing Information
Base (RIB) (for example, the IP Routing table), RIB might reject the BGP route due
to any of these reasons:
a. Route with better administrative distance already present in IGP. For example,
if a static route already exists in IP Routing table.
b. Memory failure.
c. The number of routes in VPN routing/forwarding (VRF) exceeds the
route−limit configured under the VRF instance.
d. In such cases, the prefixes that are rejected for these reasons are identified by r
RIB Failure in the show ip bgp command output and are not advertised to the
peers.
34. The BGP routing information database (RIB) consists of three parts:
a. ADJ-RIBs-In: Stores unprocessed routing information that has been learned
from updates received from peers. The routes are considered feasible routes.
b. Loc-RIB: Contains the routes that the BGP speaker has selected by applying
its local routing policies to the routes contained in ADJ-RIB-In.
c. ADJ-RIB-OUT: Contains the routes that the BGP speaker advertises to its
peers,
35. Summarization or route aggregation is the practice of advertising a contiguous set of
addresses with a single, less specific address. Basically, summarization/route
aggregation is accomplished by reducing the length of the subnet mask until it masks
only the bits common to all the addresses being summarized. Summarization is a great
tool for conserving network resources, from the amount of memory required to store
the routing table to the amount of network bandwidth and router horsepower
necessary to transmit and process routing information, summarization also network
resources by “hiding” network instabilities.
36. A routing policy is just a designed and configured process for controlling the traffic
patterns within an internetwork by controlling routes and their characteristics.
Redistribution, route filters, and route maps are the most common tools for
implementing routing policies.
37. BGP Router ID:
a. The router chooses the numerically highest IP address on any of its loopback
interfaces.
b. If no loopback is configured, the router chooses the numerically highest IP
address on any of its physical interfaces.
c. You also can set the router ID of a BGP speaker manually, overriding both the
physical and loopback interface addresses via BGP ROUTER-ID commands.
 38. An alternative to redistributing IGP routes into BGP is to use the network command.
This command function differently under EGP and BGP than it does under an IGP.
When used with an IGP, the network command specifies the address of an interface
on which the routing protocol will be enabled. When used with BGP, network
specifies an IP prefix to be advertised. For each specified with the command, BGP
looks into the routing table. If an entry in the table exactly matches the network
prefix, that prefix is entered into the BGP table and advertised. A maximum of 200
addresses can be specified with the network command.
39. The BGP neighbour default-originate command is similar to the OSPF default-
information-originate always command in that a default is advertised whether the
router actually has a default route or not.
40. Remember the following important point when configuring IBGP.
a. Synchronization must be off. (No Synchronization)
b. Every IBGP router must be peered with every other IBGP router.
c. All Network and subnets connecting the IBGP routers must be known.
d. If you turn off synchronization on a working BGP process, you must reset the
BGP connections with the clear IP BGP * command before the changes will
take effect.
41. Timers BGP is the command to set BGP keep-alive & Hold time.
42. Neighbour update-source Lo 0: This command causes the BGP message to be sourced
from the IP address of the loopback interface rather than from the physical interface the
message is sent on. It requires for both IBGP & EBGP in the case of loopback interface.
Via this command we can use load sharing in the case of EBGP with the help of static
routing.

43. The neighbour EBGP-Multihop commands enables you to override the default one-hop
EBGP limit by changing the TTL of EBGP packet from the default value of 1.
44. Neighbour Description: like the description statement that can be entered under an
interface configuration.
45. The IOS uses MD5 authentication when a BGP neighbour password command is
configured. MD5 is a one way message digest or secure hash function produced by RSA
date security. MD5 computes a 128 bit hash value from a plain text message. This is also
called TCP MD5 signature. The TCP MD5 signature is an 18 byte value that is generated
based on the data in the packet and a password that is configured on both peering routers.
46. Neighbour ……… Maximum-prefix…… : if the limit is exceeded, the router close the
BGP session with the neighbour and the session cannot be re-establish until you issue the
clear IP BGP …… command.
47. Neighbour …… maximum prefix 300 90 warning only: A log message is generated when
the neighbour advertised prefix exceeds 90 percent of the maximum.
48. The neighbour shutdown command closes the TCP port 179 connections to a specified
neighbour, similar the way the shutdown command disable a single interface.
49. The IP as-path access list command defines a variant of an ACL that identifies AS
numbers. Just as an access list identifying NLRI is called by the neighbour distribute list
command, the AS path access list is called by the Neighbour filter-list command. The AS
path access list uses a powerful text parsing tool known as regular expression.
50. To change the default distance of BGP, you use the distance BGP command, this
command sets the distance for EBGP, IBGP and local BGP routes, respectively. Local
BGP route generally comes when we use network command in IBGP to advertise routes
to avoid redistribution.
51. Network Backdoor:

a. Consider the above diagram, RTA and RTC are running EBGP and RTB and RTC
are running EBGP. RTA and RTB are running some kind of IGP (RIP, IGRP, etc)
Also.
b. By definition, EBGP updates have a distance of 20 which is lower than the IGP
distances. Default distance is 120 for RIP, 100 for IGRP, 90 for EIGRP and 110
for OSPF.
c. RTA will receive updates about 160.10.0.0 via two routing protocols: EBGP with
a distance of 20 and IGP with a distance higher than 20. By default, BGP has the
following distances, but that could be changed by the distance command:
d. distance bgp external-distance /internal-distance/ local-distance
 e. RTA will pick EBGP via RTC because of the lower distance.
f. If we want RTA to learn about 160.10.0.0 via RTB (IGP), then we have two
options:
g. Change EBGP’s external distance or IGP’s distance which is NOT recommended.
h. Use BGP backdoor
i. BGP backdoor will make the IGP route, the preferred route. Use the following
command: network address backdoor. The configured network is the network
that we would like to reach via IGP. For BGP this network will be treated as a
locally assigned network except it will not be advertised in bgp updates.
52. The Neighbour …………. Remove-private-AS: It removes private AS numbers from the
AS path of routes before advertising them to specified neighbours.
53. Show IP BGP Neighbours: The table version provides the state of the table. Any times
that new information comes in, the table increases the version. A version that continues to
increment indicates that there is some route flap that causes the continuous update of
routes.
54. Redistribution of OSPF is slightly different than redistribution for other IGPs. The simple
issue of redistribute ospf 1 under router BGP does not work. Specific keyword such as
internal, external and nssa-external are necessary to redistribute respective routes.
55. The BGP always compare MED command ensures the comparison of the MED for paths
from neighbours in different AS.
56. BGP deterministic MED command ensures the comparison of the MED variable at route
choice when different peers advertise in the same AS.
57. BGP Convergence: The most significant performance gains in achieving fast BGP
convergence are found in the manner in which updates are generated. The following
method of improving update generation, which are the basis for any BGP convergence
tuning.
a. Peer Group: This feature has two major benefits: configuration reduction and the
ability to replicate update between peers.
b. In a non peer group environment, the BGP process must walk the entire BGP table
for every peer, creating updates for each peer independently. If there are 1, 00,000
prefixes and 100 IBGP peers, the router walks through 1, 00, 00,000 prefixes. In a
peer group environment, the BGP process walks the entire BGP table only once
for each peer group. A peer group leader is elected for each peer group based on
the lowest IP address. The BGP process walks the table for the peer group leader,
creating the BGP update messages. These update messages are replicated for all
other member in the peer group. If the 100 IBGP peers are all in the same peer
group, the router walks 1,00,000 prefix instead of 1,00,00,000. This optimization
reduced both the processor and memory requirements.
58. BGP Dynamic Update peer Group: this feature identifies peers that have the same
outbound policy and optimizes update generation and replication across those peers.
Before this feature, these peers had to be manually grouped with traditional peer
groups. The use of traditional peer groups limited the available outbound policy that
could be defined and the ability to have session specific configuration. Dynamic peer
groups separate the peer group configuration from update replication through two new
features:
a. Peer Templates
b. Update Groups
59. Peer Templates: Traditional peer groups from a configuration prospective had two
major disadvantages:
 a. All neighbours in a peer group must have the exact same outbound routing
policy.
b. All neighbour in a peer group must be in the same address family like IPV4 or
VPNV4.
c. The configuration feature of peer templates allows a set of configuration
options to be applied to a set of neighbours. Peer templates are reusable and
support inheritance, giving you much more power and flexibility in generating
concise BGP configurations.
60. There are two types of peer templates:
A. Peer Session Templates: Peer session templates are used to build a template of
general session configuration. This does not include any policy type attributes,
but it is focused on session attributes. It support the commands like
Description, disable-connected-check, EBGP Multihop, Local-AS, Password,
Remote-as, Shutdown, timers, Translate-update, update-source, version.
B. Peer Policy Templates: are used to build a template of policy information.
This includes aspects of the BGP session related to manipulating actual BGP
prefix information, such as filtering, capabilities and route reflection.
Commands may be like advertise-interval, allowas-in, as-override, capability,
default-originate, distribute-list, filter-list, maximum-prefix, next-hop-
self.prefix-list, remove-private-as, route-map, route-reflector-client, send
community, soft-reconfiguration, weight.
61. Session Inheritance configuration Example:
a. Router BGP ……..
b. Template peer-session base-session
c. Password Cisco
d. Version 4
e. Exit-peer-session
f. Template peer-session
g. Inherit base-session
h. Update-source Loopback 0
i. Remote-as 100
j. Exit-peer session
k. Template peer-session
l. Inherit base-session
m. Password customer
n. Remote-as 65001
o. Exit-peer-session
p. Inherit
q. In above the base-session template, the password is defined as Cisco, but in
the external session it is changed to customer. When processing a template,
any inherited templates are processed first, and then the configuration specific
to that template occurs. In this case the password setting of Cisco is
overwritten for the external session with the password customer. Templates
are applied to BGP peering sessions using the inheritance concept. A
neighbour has its default setting as its “base” configuration. The neighbour is
configured to inherit a peer template, which modifies those settings. In the
example, the BGP session 10.1.1.1 inherits the internal session template. Any
configuration setting at the neighbour level takes precedence over peer
template settings.
 r. A BGP session cannot be associated with the both a peer group and peer
templates. The peer templates feature is expected to ultimately replace the peer
group feature.
s.
62. Update Groups:
63. BGP Read only Mode:
64. Network failure Impact Mitigation: Detecting the failure quickly and minimizing its
impact is important for maintaining high network availability. In addition to handling
failure quickly, the interaction between IGP and BGP can result in problematic
recovery scenarios. The following features of failure mitigation:
a. BGP fast external fall-over: This feature provides a mechanism for BGP to
quickly tear down an EBGP session without waiting for the hold timer to
expire.
b. IGP/BGP convergence time deltas:
c. BGP Non Stop Forwarding:
65. BGP fast External Failover: The default behaviour for tearing down a BGP session is
to require hold timer to expire, which by default is 180 seconds. The BGP fast
external fall-over function triggers the teardown of an EBGP session immediately
when the link to that EBGP peer fails. This is only for EBGP. This feature is enabled
globally, not on a per peer basis. From IOS release 12.0ST the following interface
configuration command was added. The default setting is to comply with the global
setting & the command is: IP BGP FAST-External-failover [permit | Deny]. This
feature does not work with EBGP multi-hop, and the peering address must be the
same as the physical interface address.
66. IGP/BGP Convergence time Deltas: The ISIS and OSPF routing protocols both
provide a transient black hole avoidance mechanism. The mechanism for this is as
follows:
a. ISIS Overload Bit
b. OSPF Maximum metric on start-up.
67. BGP Non Stop Forwarding: The current generation of middle to high end router has
separated control plane processing from data plane processing. The route processor
generates the forwarding table and programs it into the forwarding engines on the line
cards. The route processor is not a required part of the forwarding path. The BGP
Non-stop forwarding (NSF) or graceful restart (BGP-GR) feature takes advantage of
the independence of the data plane and control plane processing. The concept of BGP
NSF is that data plane can continue forwarding for a period of time while BGP
restarts. This BGP restart could be in the form of in the form of a route processor
reload, route processor switch over or restart of BGP process.
68. Prefix update optimization: Prefix update optimization is focused on preventing
instabilities in prefix advertisement and minimizing the impact of new policy
application. The following features cover the available prefix handling optimizations:
a. Route Flap Dampening: This feature monitors routing information for signs of
instability. Prefix that demonstrate instability are dampened until they
stabilize.
b. Soft Reconfiguration and route refresh: These features are designed to
minimize the impact of applying new policy through reducing the impact on
unaffected prefixes.
c. Transmit (TX) side loop detection: It is focused on reducing prefix
information sent to an external peer. If the prefix information will be rejected
by the remote peer because of the AS path loop detection mechanism, the
 update process can be optimized by suppressing the advertisement of those
prefixes. It must be implemented manually. It is applicable to only external
peers. It is not supported in MPLS-VPN. The AS Path ACL is used for this.
d. Outbound Route Filtering (ORF): The ORF capability is similar in concept to
the TX side loop detection in that it focuses on reducing the prefix
information advertised by a peer based on inbound policy configuration on the
remote peer.
69. Prefix lists are used to filter IP prefixes and can match both the prefix length and
prefix number. Compared to regular access lists, use of prefix lists provides higher
performance (fewer CPU cycles). Prefix lists cannot be used as packet filters. By
default, the sequence numbers are automatically generated in increments of 5.
70. Conditional Advertisement: BGP by default advertises the permitted best path in its
BGP routing information base (RIB) to external peers. In certain cases, this might be
undesirable. Advertisement of some routes might depend on the existence and
nonexistence of some other routes. In other words, the advertisement is conditional. A
conditional advertisement does not creates routes; it only withholds them until the
condition is met. These routes must already be present in the BGP RIB. Conditional
advertisement has two forms: advertisement of some prefixes when some other
prefixes do not exist and advertisement of some prefixes when they do exist.
Configuration of the same like follows:
a. The prefixes to be advertised are defined by a special route map called
advertise-map.
b. The condition is defined by a route map called non-exist-map for condition
that do not exist or by a route map called exist map for condition that do exist.
c. The first form of conditional advertisement is configured as follows:
NEIGHBOUR ADVERTISE-MAP MAP1 NON-EXIST-MAP MAP2. The
route map associated with the non exist map specifies the prefix (or prefixes)
that the BGP speaker tracks. Only permit is accepted; any deny is ignored.
When a match is made, the status of the advertise map is withdraw; when no
match is made, the status becomes advertise.
d. The second form of conditional advertisement is configured as follows:
NEIGHBOUR ADVERTISE-MAP MAP1 EXIST-MAP MAP2.
71. LOCAL AS: with the local AS feature, a BGP speaker can be physically in one AS
and acts as such to some neighbours while it appears to be another AS to neighbours.
When sending and receiving AS_Path to and from neighbours with local AS
configured, BGP prepends the local AS to the real AS. For these neighbours, BGP
uses the Local AS as the remote AS in the configuration. Thus, the local AS number
appear as if it were another AS inserted between the two real AS. When Local AS is
used, the AS path length become longer. The solution to the problem is to add the no-
prepend option to the local AS command.
72. QOS policy Propagation:
73. BGP policy accounting
74. Transient black holing of traffic:
75. BGP BESTPATH COMPARE-ROUTERID: can be configured on all routers to
ensure deterministic path selection based on lowest router ID.
76. Example of Multi-homing:
77. BGP Multipath Scenario with maximum-path command:
78. BGP Multipath Scenario with recursive Routing means static routing with EBGP
Multi-hop
79. Route Reflection Versus Confederation:
a. If you need to scale your IGP, you should use confederation.
b. If you do not scale your IGP, select the route reflection method whenever you
can to simplify migration and management.
80. Directly Connected External BGP Neighbour not initializing: The AS will not send or
receive any IP prefix updates to or from a neighbouring AS unless the neighbour
relationship reaches the established state. The most common possible causes of this
problem are as follows:
a. Layer 2 is down, preventing communication with a directly connected EBGP
neighbour.
b. An incorrect Neighbour IP address is in the BGP configuration.
81. Non Directly Connected External BGP Neighbour Not coming up:
a. The route to the non-directly connected peer address is missing from the
routing table.
b. The EBGP-Multihop command is missing in BGP configuration.
c. The Update-source interface command is missing.
82. Internal BGP Neighbour not coming up:
a. The route to the nondirectly connected IBGP neighbour address is missing.
b. The update source interface command is missing in BGP configuration.
c. Interface ACL blocking BGP packets.
d. Wrong AS configuration
83. Problem in propagating/ Originating BGP route to IBGP/EBGP Neighbour:
a. IP Routing table does not have a matching route. Identical advertising BGP
route must exist in the routing table when network and redistribute commands
are used.
b. Configuration error in network command like wrong mask.
c. Aggregate address configuration
d. Auto summarizing to classful/network Boundary
e. Misconfigured filters like prefix list, AS Path etc.
84. EBGP Learned route not getting Installed in IP routing table: Possible causes can be:
a. BGP routes are dampened
 b. The BGP next hop is not reachable in case of multi-hop EEBGP
c. The MED value is infinite.
85. Load Balancing and managing outbound traffic from a single router when dual homed
to same ISP but BGP installs only one best path in the routing table.: In BGP, by
default, only one of the many path paths available is used.BGP selects only a single
best route for a prefix out of many alternate paths. If two or more paths have identical
attributes except for the RID, they can go in the routing table and load sharing can be
achieved for traffic going to that prefix. The maximum path 2 command allows two
equal BGP paths to be installed in the routing table. Notice that in the BGP output,
only one path has “best”in its output, but both have “multipath” and thus both will be
installed in the routing table. For IBGP we may use Maximum-path IBGP, this allows
installing multiple equal IBGP paths to install in the routing table.

86. Migration is typically a process where both old & new architectures exist side by side
during migration. The goal of many migration procedures should be to minimize
network downtime and traffic loss.
87. BGP Network Design Rules:
a. Hierarchy: The most common method of enhancing a network’s scalability is
to introduce a hierarchy into the network. Hierarchy is used in both the
physical topology and the BGP peering layout. The hierarchy is broken into
three major components: The Network Core Layer; The Aggregation Layer;
The Network Edge Layer
b. Modularity: Modularity in network design increase the network’s
extensibility.
c. Redundancy: Redundancy provides the foundation for a fault tolerant network.
d. Simplicity: Simplicity in network design results in fewer human mistakes and
a reduced set of code issues.

88. The Network Core Layer: The primary responsibility of the network core is switching
packet at line rate. The network core consist of a small routers, usually fewer than 20,
That all are connected in a dense partial mesh or full mesh. The Network core is at the
very top of the hierarchy, providing connectivity for the aggregation layer. Some rules
for Core layer are:
a. The IBGP full mesh consists of all the core routers.
b. Policy is not modified for BGP prefixes in the network core.
c. A single peer group can be used for the entire IBGP mesh for the core peering
session.
d. An important rule for route reflection is that BGP peering session must follow
the physical topology to avoid routing loops.
e. No connection external to the network are terminated on the core routers. This
includes customer connections and peering or transit connections.
89. Aggregation Layer: This includes distributing the circuit aggregation and reducing the
number of peering session terminating on the core routers. Aggregation router has two
types of links: uplink and downlinks; uplinks are to the network core routers and
circuits to the edge routers. Typically there are two uplinks for each aggregation
routers to core for provide redundancy. The Aggregation routers have downlinks to
the edge routers. Two peer groups are required on the aggregation routers. The first
 peer group is the IBGP session to the upstream core routers. The second peer group is
the IBGP session to the edge routers.
90. Edge Router: The edge is responsible for external connectivity. Typically, an edge
router has uplinks an edge router has uplink to two aggregation routers, this provides
redundancy. Services and policy are applied at the network edge. The traffic rates on
the edge routers are much lower than at the aggregation and core Several BGP
functions are performed on the edge routers like: Route Dampening, Route
Aggregation, Resetting the Next-Hop, MED, Route information filtering, Policy
application like LP or other attributes.
91. The difference between BGPV4 and MP-BGP is the ability to carry prefix
information for multiple protocols, such as IP Multicast, CLNS, MPLS Label, IPV4
VPN, and IPV6. This information is advertised using address families. Prefix
information is advertised using the BGP attribute MP_REACH_NLRI and is
withdrawn using MP_UNREACH_NLRI attributes.
92. The mechanisms and techniques provided by BGPv4 also available in MP BGP for
handling IPV6 NLRI. The decision process, scalability mechanism, and policy
features are not specified to IPv4 NLRI; they apply quite well to to IPV6 NLRI. This
means that route reflection, route dampening, BGP confederation, MED, and ORF are
all unchanged for MP-BGP.
93. In general, BGP is protocol agnostic. It runs on top of TCP, which is the same in IPV4
and IPV6. This means that the underlying network layer protocol can be either IPV4
or IPV6 without requiring any changes to BGP. However, two fields in BGP
messages are IPV4- specific router ID and cluster ID. Both are 4 byte long.
94. The router generates the router ID automatically based on IPv4 addressing configured
on the router, the address configured on the loopback interface, or, if there is no
loopback, the highest IPv4 address on any of the interfaces. In a pure IPv6
deployment, no IPv4 addressing is configured, providing nothing for the router to use
in building a router ID. In this case, the router ID must be manually configured under
the BGP process. If there is no router ID, BGP sessions do not form.
95. The other component of BGP that requires a unique 4-byte number is the cluster ID,
used on route reflectors. The cluster ID is carried with the NLRI in the BGP UPDATE
messages. If a router ID is configured, this value is used for the cluster ID. The cluster
ID can also be configured independent of the router ID. The originator ID attribute is
also a 4-byte value that is used with route reflection. The manual configuration of a 4-
byte router ID provides the value for the originator ID.
96. The concept of auto-summarization along class full boundaries does not exist in
IPv6.Because IPv6 does not use address classes, the auto-summary command in
BGP has no effect on IPv6 prefix information
97. The BGP configuration for IPv4 and IPv6 is very similar. However, when you
configure IPv6, the address family-style (AF-style) configuration is required. The AF-
style configuration is used for all address families besides IPv4. IPv6 forwarding is
not enabled by default. This must be done explicitly in global configuration mode
with the command ipv6 unicast-routing. Do this before configuring IPv6 routing.
98. BGP AF-style configuration is based on the concept of defining all the peering
relationships or neighbors in the main BGP router configuration. These neighbours
are then activated under the address family for each NLRI type that will be carried in
this peering session. The IPv4 NLRI is on by default for all BGP sessions. You can
disable the default behaviour of carrying IPv4 NLRI on all BGP sessions using the no
bgp default ipv4-unicast command.
99. Example of Pure IPV6 Deployment:
 a. router bgp 65000
b. no synchronization
c. bgp router-id 10.1.1.5
d. no bgp default ipv4-unicast
e. bgp log-neighbor-changes
f. neighbor 2001:400:0:1234::1 remote-as 65000
g. neighbor 2001:400:0:1234::1 update-source Loopback1
h. neighbor 2001:400:0:1234::2 remote-as 65000
i. neighbor 2001:400:0:1234::2 update-source Loopback1
j. no auto-summary
k. address-family ipv6
l. no synchronization
m. neighbor 2001:400:0:1234::1 activate
n. neighbor 2001:400:0:1234::2 activate
o. network 2001:400:0:ABCD::/64
a. exit-address-famil

100. BGP Graceful Restart Mechanism: Normally when the BGP control plane in a
router restarts, its BGP sessions to the peers are lost. Upon detection of the BGP
session failure, peers withdraw all routes associated with the failed session. The
neighboring routers first withdraw, but then quickly re-advertise the affected routes as
their peer restarts. This set of actions leads to route flaps. The aforementioned BGP
behavior is based on the fact that the restarting router is incapable of forwarding
across the restart. However, if the faults were confined to the control plane and the
restarting router was capable of preserving the FIB across the control-plane restart, it
would be desirable to keep the restarting router in the forwarding path and avoid route
flaps.
101. Exchange of graceful restart capability: The BGP graceful restart mechanism
defines protocol extensions that allow a speaker to indicate NSF capability to its peers
during the initial BGP session-establishment process. For this purpose, a new BGP
capability known as graceful restart capability is defined that is carried in the Open
message. The neighbouring speakers exchange graceful restart capability in the Open
message during BGP session establishment. When a speaker is capable of preserving
the FIB across a BGP control-plane restart, it announces its capability to preserve the
concerned forwarding state in the graceful restart capability, which is tantamount to
saying, “For each address family listed here, I am capable of preserving the associated
forwarding state across the BGP restart. When my BGP control- plane restarts, please
continue to forward data traffic to me as before, and don’t withdraw routes for the
aforementioned address families. If I don’t re-establish the failed session within a
certain time (as indicated in the Restart Time field), you should delete all routes that
were being retained across the restart and stop forwarding traffic on those routes.”
102. As a result of having exchanged the graceful restart capability, when a router
restarts that had previously expressed its capability to preserve the FIB across the
restart, its neighbors retain routes learned from the restarting router, but mark them as
stale. Assuming the restarting router is ready for communicating with peers within the
previously advertised restart time, it re-establishes a BGP session and again
exchanges graceful restart capability exchange in the Open message. In the new
graceful restart capability exchange, the restarting router informs its neighbors
whether it was actually able to preserve its forwarding state, which it had indicated in
the previous (pre-restart) graceful restart capability. Assuming the restarting router
 actually had managed to preserve the pertinent forwarding state; the peers exchange
routing information again, select the best routes, and update the FIB. Because peers
do not withdraw routes and keep the restarting router on the forwarding path, traffic
passing through the restarting router is not disrupted. This means that, other than the
immediate peers who act as helper nodes, the BGP restart event is completely
concealed from all other speakers. Thus the BGP graceful restart mechanism helps to
eliminate the negative effects of the normal BGP restart.
103. Operation of BGP Graceful Restart Mechanism:

a. R1 and R2 establish BGP session and exchange the graceful restart capability
to indicate their capability to preserve forwarding state during BGP restart. For
the sake of brevity, suppose that only IPv4 addresses are supported. In general,
however, the same procedure applies to other address families such as IPv6.
b. R1 and R2 exchange routing information using normal BGP procedures.
c. Assume in R2 the BGP control-plane restarts and the control processor
switches over.
d. R1 detects the failure of the BGP session with R2. Because R1 knows that
that R2 is capable of preserving the forwarding state across the restart, R1
starts the restart timer within which R2 is expected to re-establish the session.
However, R1 retains the routes received from R2 for all the address families
that were advertised by R2 in the graceful restart capability before its BGP
restart, marks these routes as stale, and starts a stale timer. R1 continues to use
 the stale routes for forwarding while the restart timer is running. R1 waits for
R2 to re-establish the BGP session. If the BGP session were not established
within restart time, R1 would delete all stale routes from R2.
e. Assume R2 is able to preserve the BGP-related forwarding state across the
restart for the IPv4 address family. After restarting, R2 marks the preserved
forwarding state as stale and starts a stale timer, but continues to use the stale
information for forwarding. R2 tries to establish the BGP session with R1.
During the session-reestablishment process, R2 includes the graceful restart
capability with the R bit set. In addition, because R2 was able to preserve the
forwarding state for the IPv4 address family, it sets the F bit for the IPv4
address family. In general, R2 would need to set the F bit for each address
family for which it was able to preserve the forwarding state.
f. On BGP session reestablishment, R1 stops the restart timer and processes the
newly received graceful restart capability from R2. Because the F bit for the
IPv4 address family is set, R1 continues to retain the forwarding state marked
as stale. However, if the F bit for an address family were not set in the newly
received graceful restart capability, R1 would have immediately removed all
stale routes from R2 for that address family. For each address family, R1
sends BGP updates from its Adj-RIBs-Out to R2. Upon completion of the
initial update for an address family, R1 sends the End-Of-RIB marker to R2.
g. R2 receives BGP Update messages from its peers, processes these messages,
and rebuilds its Adj-RIBs-In. However, R2 defers (for a configurable time) its
BGP route-selection process for an address family until it receives an End-Of-
RIB marker from all its nonrestarting peers. After R2 has done the route
selection, it updates its Loc-RIB, FIB, and Adj-RIBs-Out and advertises its
routes to its peers. On completion of the initial update for an address family,
R2 in turn sends an End-Of-RIB marker to all its peers. To avoid deferring
route selection indefinitely, R2 uses a delay timer. When the delay timer
expires, R2 runs the route-selection process, even if not all End-Of-RIB
markers have been received.
h. R1 replaces the stale routes in Adj-RIBs-In with the routing updates received
from R2. On receiving the End-Of-RIB marker for an address family, R1
deletes any routes from R2 that are still marked as stale for that address
family. R1 runs the decision process and updates the-RIB, FIB, and Adj-RIBs-
Out. To avoid waiting indefinitely for the arrival of all the End-Of-markers
and to avoid retaining stale routes, the helper speaker uses a (configurable)
stale timer. When the stale timer expires, R1 deletes all routes still marked as
stale.
i. Normal operation resumes.