https://bidsarmanish.blogspot.com/2017/01/bgp-in-nutshell-interview-question-on.

html

Networking And Scripting

FRIDAY, 27 JANUARY 2017
BGP In Nutshell "With"Interview Question on BGP
Introduction:

 BGP is the routing protocol used to exchange routing information

between networks. It Is the largest routing protocol in the internet.
 Comes in two flavours
 External BGP (EBGP)
 Internal BGP (IBGP)
 BGP is Currently in version 4,
 Runs over TCP(Port No. 179)
 Path vector protocol ,CIDR support
By Default BGP finds the best path to a network by using the best AS –
Path.

BGP advertises the complete path to the advertised network. Path is sent
as a LIST OF AS no. Which avoids loop.

Interconnections: BGP is a path-vector protocol.

Similar to distance-vector, but does not say the distance to the

destination but the paths (AS number sequence) to the destination. Based
on paths reported by the neighbors, choose your preferred path and
report that to your neighbors.

Autonomous System (AS)

 Collection of networks with same routing policy
 We can have different IGP protocols within an AS
 Usually under single ownership, trust and administrative control

BGP General Operations

 BGP Neighbours are manually configured
 Learns multiple paths via internal and external BGP speakers
 Picks the best path and installs in the forwarding table

NOTE: BGP Converges slow. BGP sends Batch updates every 5

seconds for ibgp peer and every 30 second for ebgp.

External BGP (EBGP)

 BGP speakers in different AS

 Do not run an IGP between eBGP peers

Internal BGP (iBGP)

 BGP peer within the same AS
 iBGP speakers need to be fully meshed
 They do not pass on prefixes learned from other iBGP speakers to
other iBGP peer . (The Rule of Split Horizon.)
Rule Of Split Horizon. : Routes Learned Via iBGP Will Never be Sent
to Another iBGP peer.
 Why This Rule??
-> It is a loop prevention mechanism.
-> BGP assumes that in an Autonomous System all BGP neighbor
would be fully meshed
----- Which causes a loop
So here Route Reflector comes into picture.

Why does IBGP require a full mesh?

BGP uses the AS _PATH attribute for loop detection. If a router sees its
own AS number in a BGP advertisement, the advertisement is dropped.
IBGP routers have the same AS number so the AS number cannot be
used for loop detection. IBGP neighbors will not advertise prefixes
learned from one IBGP neighbor to another IBGP neighbor; therefore, a
full mesh is required.

Why IGP in BGP?

Keep in mind these rules when using BGP with other IGP protocols:
BGP will not put routes that it cannot verify reachability for in the main
IP routing table.
For routers to successfully use BGP routes, they must always have a
route to the next-hop IP address in the main IP routing table.
Unless otherwise configured, BGP stores only the best path to a
destination network in the main IP routing table. However, you can use
the BGP maximum-paths command to configure more than one path.

BGP advertises only the best path to a destination network. You can
control BGP path selection using BGP attributes, and you can control
the best path selection process using certain Cisco IOS Software BGP
configuration commands.
BGP follows its own best path decision process to find the most efficient
path; this path is stored in the main routing table.

BGP forms peer relationships only with explicitly configured peers, and
only advertises networks that it was explicitly configured to advertise.
 BGP does not redistribute its routes into IGPs unless explicitly
configured to do so.
BGP is an extremely customizable protocol; it can be as dynamic or
static as it is configured to be. You can advertise and control route
policies in a number of different ways.

BGP Message Type

 Open: Establishes a peering session
 Keep Alive: Handshake at regular intervals to maintain peering
session.
 Notification: Closes a peering session
 Update: Advertises new routes or withdraws previously announced
routes.
Each announced route is specified as a network prefix with
attribute values.
Idle State — BGP is waiting for a Start event, which is initiated by an
operator or the BGP system. After the Start event, BGP initializes its
resources, resets a ConnectRetry timer, initiates a TCP transport
connection, and starts listening for a connection that may be initiated by
a remote peer. BGP then transitions to a Connect state. In case of errors,
BGP falls back to the Idle state.

Connect State —BGP is waiting for the transport protocol connection

to be completed. If the TCP transport connection is successful, the state
transitions to OpenSent (this is where the OPEN message is sent). If the
transport connection is unsuccessful, the state transitions to Active.

Active State—BGP tries to acquire a peer by initiating a transport

protocol connection. a neighbor state that is oscillating between Connect
and Active indicates that something is wrong with the TCP transport
connection. It could be because of many TCP re transmissions or the
inability of a neighbor to reach the IP address of its peer.

OpenSent State—BGP is waiting for an OPEN message from its peer.

The OPEN message is checked for correctness. At the OpenSent state,
the BGP recognises, by comparing its AS number to the AS number of
its peer, whether the peer belongs to the same AS (Internal BGP) or to a
different AS (External BGP).

OpenConfirm State—BGP waits for a KEEPALIVE message. If a

KEEPALIVE is received, the state goes to Established, and the neighbor
negotiation is complete.
If a NOTIFICATION message is received, the state falls back to the Idle
state. The system sends periodic KEEPALIVE messages at the rate set
by the KEEPALIVE timer.

Established State—This is the final stage in the neighbor negotiation.

At this stage, BGP starts exchanging UPDATE packets with its peers.
The UPDATE messages are checked for errors, such as missing
attributes, duplicate attributes, and so on. If errors are found, a
NOTIFICATION message is sent to the peer, and the state falls back to
Idle.

BGPStateMachine BGP goes through six states to establish an

adjacency.

Idle - incoming connections are refused, and the system gets ready to
start speaking BGP. After this is done (by way of a Start event), move to
Connect.Connect - a connection is made to the peer. Send a BGP OPEN
message, and go to OpenSent. Active - a connection comes in from a
peer. Send a BGP OPEN message, and go to OpenSent. OpenSent - Wait
for an OPEN message from the peer. When received, send a
KEEPALIVE and go to OpenConfirm. OpenConfirm - Wait for the
KEEPALIVE from the peer, then move to Established. Established -
Bidirectional communication is established. Start sending UPDATE
and KEEPALIVE messages as required
BGP defines the following message types:
 Open = Includes hold time and BGP router ID. Keepalive, Update =
Information for one path only(could be multiple networks) Includes path
attributes and networks. Notification.= When error is detected, BGP
connection is closed after sent.
How iBGP works?

Split horizon rule.

Routes learnt via IBGP will never be sent to another IBGP Peer.

Why this rule ??

When two IBGP neighbors send update messages to each other they do
not add the ASN in AS_Path attribute in the update because both of
them are in the same AS and the AS_Path will not change. Since BGP
uses the ASN in the AS_Path attribute to avoid loops, and IBGP will not
add the ASN to AS_Path when sending updates in the same AS, this can
cause a potential routing loop. To avoid such loops IBGP has to follow a
rule which says that when a route is learnt from an IBGP neighbor, that
route cannot be advertised to another IBGP Peer.

Consider the example below.

RTR-A is advertising 1.1.1.0/24 to RTR-B. RTR-B learns the route but
will not advertise that route to RTR-C. Similarly RTR-B will also learn
the route 2.2.2.0/24 From RTR-C but will not advertise this route to
RTR-A. Since all the three routers are in the same AS and in same AS
BGP does not advertise routes that have been learned from an IBGP peer
to another IBGP peer.

This is a partially meshed IBGP network hence RTR-A and RTR-C are
not exchanging the NLRI.

This can be resolved by creating a logical connection between RTR-A

and RTR-C. A BGP Session can be established between RTR-A and
RTR-C to allow both of them to exchange their BGP learnt Routes. The
TCP Session that RTR-A and RTR-C use to establish the BGP passes
through RTR-B, so it is important that the data link addresses
interconnecting RTR-A and RTR-C are known to them.
In iBGP, the routes learnt from one iBGP neighbor are not advertised to
another iBGP neighbor due to the BGP Split Horizon Rule. To
overcome the issues generated by this rule, one option is to have a full
mesh of iBGP routers, where each iBGP router is peering directly with
all other iBGP routers in the AS. The solution is feasible if you have a
small number of iBGP routers, but it will not scale if you need a large
number of iBGP speaking routers in the AS.

The number of iBGP Sessions needed in an AS for Full mesh IBGP

are calculated with the formula N(N-1)/2.

So assuming you have 10 iBGP routers then the number of iBGP

peering sessions would be 10(10-1)/2 = 45 iBGP Sessions to manage
within the AS. That’s a lot of configuration and a lot of room for errors
and may become difficult to troubleshoot.
There are 2 alternatives to creating a Full Mesh iBGP routing,
which are
1. Route Reflectors
2. Confederations

Rule of Synchronisation:
Routes learnt via IBGP must be validated by Interior Routing
Table/Protocol such as OSPF,RIP etc
before they can be advertised to remote peers

For A Route to be learnt from an IBGP neighbor, it must first be known

via an IGP. Any route learnt from IBGP is entered into the routing table
only if that route is first learnt by an IGP

Note: In some case Synchronisation is not practical and this rule can be
turned off by command: No Synchronisation.
Synchronization requires that before a route is learnt from an IBGP
neighbor and entered into Routing table and advertised to other BGP
peers, the route must first be learnt via IGP.

In this example, RTR-A and RTR-C have formed a BGP Peering, and
the TCP session passes through RTR-B. There is no physical
connectivity between RTR-A and RTR-C but a logical connection
exists. If Synchronization is turned on, then it is important to note that
the routes advertised by RTR-A will appear in the RTR-C’s Routing
table only if these routes exist in the IGP. The same applies for RTR-A,
the routes advertised by RTR-C will not appear in the RTR-A’s Routing
table if these routes are not being learnt by the IGP first.

RTR-B is directly connected to Both RTR-A and RTR-C and is learning

the routes from both of them. RTR-B still cannot advertise the routes
learnt from RTR-A to RTR-C and the routes learnt from RTR-C to
RTR-A because there is either no IGP running or these routes are not in
IGP, and since both RTR-A and RTR-C are not directly connected they
have to cross through RTR-B. Since there is no entry in IGP for these
routes RTR-B cannot advertise these routes -as per the rule of
synchronization.
If the routes advertised by RTR-A and RTR-C are being learnt by an
IGP then both RTR-A and RTR-C will learn each others BGP routes in
their BGP and routing tables.

There are two workarounds for these situations.

1. Not all routes can be redistributed into IGP (Since the Internet
Routing table is very large and IGP cannot scale to it) then have all the
IBGP routers fully meshed and then turn off the Synchronisation rule
with no synchronisation command.

2. Redistribute all external routes into IGP. Not a feasible solution as

IGP will not scale to hold all the internet routes.

Difference between BGP synchronisation and split-horizon rule.

BGP Split horizon:
This is for ibgp only and when you have more than 2 routers in ibgp you
have to think about this, If only two routers you are ok.

If a routes is learned by an ibgp neighbor that route will not be

advertised to another ibgp neighbors

The solution is full mesh-- number of bgp =n(n-1)/2 where n is number

of routers
But this leads to lots of configs so solution is either Route Reflector or
confederation(sub AS within main AS)

Rule of Synchronisation:
BGP routers try to synchronise between IGP table(show ip route bgp)
and bgp table(show ip bgp)
In order for bgp route to be used and advertised, it must be learned by an
IGP(another routing protocol rip/eigrp/ospf) etc

But if you run only bgp and if same routes are not advertised by IGP,
you may want to turn off this automatic synchronisation between IGP
 table of BGP(show ip route bgp) and BGP table(show ip bgp) with
(config-router)#no sync
Now in new IOS "no sync" is default.

Content of Advertisement
 BGP routers advertise routes
 Each route consists of a network prefix and a list of attributes that
specify information about a route.
 All BGP Routing Policies are configured using BGP attributes.
 BGP calculates its Metric through a series of attributes.

BGP converges slowly. Batch updates sent once every 5 seconds for
IBGP peer, and once for every 30 Sec for EBGP.

BGP PATH Attributes

Well Known Attributes: Are attribute which have to be supported by
every routers which run bgp.
i.e. in order to run BGP these three attributes have to be present.

Optional Attributes: Are those which can or cannot be supported by

your router manufacturers depends on need and capability.

Mandatory: These attributes are those that much be included in each

and every single BGP routing updates.

Discretionary Attribute: Up to the router/administrator whether you

want to have those attribute or not.

Transitive Attribute: Are those which will keep travelling through the
system whether they are recognized by bgp router or not.

Non Transitive Attribute: Are those which will be stripped off it is not
recognized by router or it chooses not to propagate it.
 Next-Hop Cont.
 Each The next-hop concept with BGP is slightly more elaborate. It
takes one of the following three forms:
 For EBGP sessions, the next hop is the IP address of the neighbor
that announced the route.
 For IBGP sessions, for routes originated inside the AS, the next hop
is the IP address of the neighbor that announced the route
 For routes injected into the AS via EBGP, the next hop learned
from EBGP is carried unaltered into IBGP. The next hop is the IP
address of the EBGP neighbor from which the route was learned.

What is the Use of MED ??

MED (multi-exit Discriminator) is a BGP attribute that is used to
influence the other AS on how to reach the prefixes inside your own AS.
The lower the MED, the higher the preference
You cannot tell another Autonomous System how to Route Traffic.
You can’t tell how to send traffic through this router and exit at this
point. Which is the most expensive way.
You have control over your autonomous system only your autonomous
system. Not others …..
Used to Suggest an Entry point into your network.

We can suggest the path from A-C since it has a lower MED ( which is
better)
You cannot tell another Autonomous System how to Route Traffic .

… through MED we can suggest AS 200 how to route traffic i.e

through A-C It depend on them whether they will use our metric or not
.
But default it will not use the metric.. So the AS200 has to accept the
suggestion that they will route the traffic through MED 1000
Goes Closer to break the Golden Rule of BGP but doesn’t quite get
there …
The metric attribute also has the name
MULTI_EXIT_DISCRIMINATOR, MED (BGP4), or INTER_AS
(BGP3). The attribute is a hint to external neighbors about the path
preference into an AS. The attribute provides a dynamic way to
influence another AS in the way to reach a certain route when there are
multiple entry points into that AS. A lower metric value is preferred
more.
Unlike local preference, metric is exchanged between ASs. A metric is
carried into an AS but does not leave the AS. When an update enters the
AS with a certain metric, that metric is used to make decisions inside the
AS. When the same update passes on to a third AS, that metric returns to
0. The diagram in this section shows the set of metric. The metric default
value is 0.

What is the difference between always-compare-med and

deterministic-med?
There are two BGP configuration commands that can influence the
MED-based path selection,
the bgp deterministic-med and the bgp always-compare-med commands.

Enabling the bgp deterministic-med command ensures the comparison

of the MED variable when choosing routes advertised by different peers
in the same autonomous system.

Enabling the bgp always-compare-med command ensures the

comparison of the MED for paths from neighbors in different
autonomous systems. The bgp always-compare-med command is useful
when multiple service providers or enterprises agree on a uniform policy
for setting MED. Thus, for network X, if Internet Service Provider A
(ISP A) sets the MED to 10, and ISP B sets the MED to 20, both ISPs
agree that ISP A has the better performing path to X.

Note: The bgp deterministic-med and bgp always-compare-med

commands are not enabled by default. Also, the two commands are
separate; enabling one does not automatically enable the other.
How Metrics Determine the Route Selection Process
Routes are chosen and built in the routing table based on the routing
protocol's administrative distance. The routes learned from the routing
protocol with the lowest administrative distance are installed in the
routing table. If there are multiple paths to the same destination from a
single routing protocol, then the multiple paths would have the same
administrative distance and the best path is selected based on the
metrics. Metrics are values associated with specific routes, ranking them
from most preferred to least preferred. The parameters used to determine
the metrics differ for different routing protocols. The path with the
lowest metric is selected as the optimal path and installed in the routing
table. If there are multiple paths to the same destination with equal
metrics, load balancing is done on these equal cost paths

Making Forwarding Decisions

Let's look at the three routes we just installed in the routing table, and
see how they look on the router.
router# show ip route
....
D 192.168.32.0/26 [90/25789217] via 10.1.1.1
R 192.168.32.0/24 [120/4] via 10.1.1.2
O 192.168.32.0/19 [110/229840] via 10.1.1.3
 ....
If a packet arrives on a router interface destined for 192.168.32.1, which
route would the router choose? It depends on the prefix length, or the
number of bits set in the subnet mask. Longer prefixes are always
preferred over shorter ones when forwarding a packet.
In this case, a packet destined to 192.168.32.1 is directed toward
10.1.1.1, because 192.168.32.1 falls within the 192.168.32.0/26 network
(192.168.32.0 to 192.168.32.63). It also falls within the other two routes
available, but the 192.168.32.0/26 has the longest prefix within the
routing table (26 bits verses 24 or 19 bits).

Likewise, if a packet destined for 192.168.32.100 arrives on one of the

router's interfaces, it's forwarded to 10.1.1.2, because 192.168.32.100
doesn't fall within 192.168.32.0/26 (192.168.32.0 through
192.168.32.63), but it does fall within the 192.168.32.0/24 destination
(192.168.32.0 through 192.168.32.255). Again, it also falls into the
range covered by 192.168.32.0/19, but 192.168.32.0/24 has a longer
prefix length.
Does the route reflector change the next hop attribute of a reflected
prefix?
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.

Does route reflector come in actual path during traffic forwarding?

RR is deployed as a control plane to reduce the requirements for a full
iBGP mesh. Thus, it is not in the forwarding path, but forms iBGP
peering

What is route reflector and why it is required?

Answer: Route reflector is a solution for BGP split horizon. The rule
says “prefix learned from an iBGP neighbor will not be advertised to
another iBGP neighbor.”

To overcome this situation, we have multiple options:

Make your network a full mesh
Route confederation
Confederation
Route reflector is something like a central point acting as a route
reflector server: Rather than peering with every iBGP router in a full
mesh, it makes IBGP neighbors as route reflector clients to overcome
the split horizon issue.

Why do we use route reflector?

A route reflector (RR) is a network routing component. It offers an
alternative to the logical full-mesh requirement of internal border
gateway protocol (IBGP). A RR acts as a focal point[clarify] for IBGP
sessions. The purpose of the RR is concentration. Multiple BGP routers
can peer with a central point, the RR - acting as a route reflector server -
rather than peer with every other router in a full mesh. All the other
IBGP routers become route reflector clients.

Will the actual route propagate through route reflector?

RR will forward both data plane and control plane traffic.

BGP route reflectors: A route reflector is BGP router that is allowed to

break the iBGP loop avoidance rule. Route reflectors can advertise
updates received from an iBGP peer to another iBGP peer under specific
conditions. By breaking the rules, route reflectors are used to eliminate
the full mesh requirement and allow for building iBGP networks that
scale easily and cleanly.
How is this accomplished?
BGP Route Reflector follows the below listed rules to achieve its
function:
 * iBGP routers are divided into Route Reflectors, Route Reflector
clients and non-client Peers.
* Routes received from a Route-Reflector-client are reflected to other
clients and non-client neighbors.
* Routes received from non-client neighbors are reflected to Route-
Reflector-client neighbors only.
* Set the Originator-ID attribute in the reflected update if it is not
already set.
* Add the Cluster-ID to the Cluster-list attribute in the reflected
update.
* A Route Reflector reflects routes considered as best routes only. If
more than one update is received for the same network, the BGP best
route is only reflected.
* A Route Reflector is not allowed to change any attributes of the
reflected routes including the next-hop attribute.
Route Reflectors and Loop Prevention:
The following rules are used to detect and avoid routing loops caused by
route reflection:
* If a router received an iBGP route with the Originator-ID attribute
set to its own router-id the route is discarded.
* If a route reflector receives a route with a cluster-list attribute
containing its cluster-id the route is discarded.
* If a BGP router that receives a route from an iBGP neighbor in the
incoming update detects the presence of its own Router-ID in the
Originator-ID attribute it will reject the update.
* If a BGP router that receives a route from an iBGP neighbor is
configured to operate as a route reflector and in the incoming update
detects the presence of its own Cluster-ID in the Cluster-list attribute it
will reject the update.
Originator is the Router-ID of the iBGP peer that advertised the route to
a route-reflector. In our case, this is R6. Cluster list is a set of BGP
Cluster-IDs of all the route reflectors that reflected this route. By default,
Cluster-ID will be the same as the Router-ID of the route reflector
http://blog.ipexpert.com/2012/02/20/understanding-bgp-originator-id-
and-cluster-id/
BGP updates are carried using TCP on port 179. In contrast, RIP
updates use UDP port 520, while OSPF does not use a Layer 4 protocol.
Because BGP requires TCP, IP connectivity must exist between BGP
peers. TCP connections must also be negotiatedbetween them before
updates can be exchanged. Therefore, BGP inherits those
reliable, connection-oriented properties from TCP.

Default Administrative Distances

Connected 0
Static 1
eBGP 20
EIGRP (internal) 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EIGRP (external) 170
iBGP 200
EIGRP summary route 5
Since the internal EIGRP route has the best administrative distance (the
smaller the administrative distance, the higher the preference), it's
installed in the routing table.

Which layer protocol is BGP? = it is application layer protocol

It rides over our existing TCP/IP structure, Hence BGP is a Application
layer Protocol. And both BGP and RIP are application layer protocols
using TCP 179 and UDP 520 respectively for communication. OSPF and
EIGRP are network layer protocols using protocol number 89 and 88
respectively for communication.

BGP is unicast or multicast.

It is possible to configure BGP peers that exchange both unicast and
multicast network layer reachability information (NLRI), but you cannot
connect multiprotocol BGP clouds with a BGP cloud. That is, you
cannot redistribute multiprotocol BGP routes into BGP.

What are all BGP mandatory attributes?

As path ,next hop and origin

Difference in local pref and MED?

Local pref is used within AS between IBGP .
MED is used between peers in different AS.

Can we use local preference outside the autonomous system?

local preference is NOT communicated outside an autonomous system,
that is to say it is not sent over EBGP connections. Only IBGP neighbors
receive this information

What does non transitive attribute in BGP means?

Weight is not a transitive attribute which means that it can’t influence
the routing decision of the other routers. Same is the case for Local
preference.

Use of access-list and route-map in BGP?

The access-list will classify what prefix we want to manipulate and the
route-map will tell what actions we want to do with that prefix.

Why do we need iBGP if we already have iGP?

Scalability: Imagine that you're receiving 500,000 EBGP routes in more
than one location , and you need to influence the per route exit point in
your AS. BGP can handle many more routes than IGP protocols. Thus,
iBGP is required unless you're willing to redistribute all the routes
you've learned via eBGP
Enforce boundaries of trust / control: BGP has many more knobs than
IGPs for controlling what you advertise and receive.

Flexible tools: BGP communities, BGP Extended communities, local-

pref, etc... these make BGP an attractive way to implement custom
routing policies within your own autonomous system (by using iBGP).

As with everything... the scalability, control, and flexibility you get from
iBGP means that it's a slower converging protocol than IGPs (in
general).

iBGP is usually used with in once administrative boundary of large

enterprises to get the advantage of the BGP route stability and policy
manipulations through the BGP attributes. That doesn't mean you can't
use eBGP with in the administrative boundary but iBGP is preferred due
to some attributes which are only used within the same AS only like
Local preference, ease of management since you are using one AS rather
than different AS numbers. And eBGP (even if there is away) require
direct link due to use of TTL 1.

Why BGP Uses TCP and IGPs Don't?

http://packetlife.net/blog/2010/jun/24/why-bgp-uses-tcp-and-igps-dont/

Convenience:
Arguably the most obvious motivation to design BGP to run over TCP is
simple convenience. Remember that BGP is essentially just another
application layer protocol to the TCP/IP stack; at the time of BGP's
creation TCP was already out there and working, so why not take
advantage of it? From RFC 4271:

BGP uses TCP as its transport protocol. This eliminates the need to
implement explicit update fragmentation, retransmission,
acknowledgement, and sequencing.
Security
Unlike other IPv4 routing protocols, BGP does not provide its own
security mechanism. Sure, you can secure neighbor adjacencies using
MD5 digests, but these aren't actually carried within the BGP header.
Rather, security is facilitated by a TCP option defined in RFC 2385, the
TCP Authentication Option (kind 19).

This TCP option was originally created specifically to secure BGP

adjacencies (which typically have quite long lifetimes), and for a decade
or so has worked quite well. However, as MD5 is beginning to show its
age, a new RFC (5925) was published just this month to provide a more
resilient alternative.

No Need for Neighbor Discovery

Unlike interior routing protocols, BGP has no requirement for dynamic
neighbor discovery. As BGP adjacencies are (or more accurately, should
be) very carefully weighed design considerations, BGP neighbors must
be configured statically at both ends. This is in contrast to a protocol like
OSPF, which uses hello packets to automatically discover and form
adjacencies with neighbors.

Adjacency Traffic is Always Point-to-Point

A corollary of our last point, we know that BGP unicasts advertisements
to each of its adjacent neighbors separately. This is in contrast to interior
routing protocols, which typically employ multicast transmissions to
more efficiently communicate with one or more other neighbors on a
multi access segment.

Default BGP timers?

There are two primary timers in BGP.
The first is the Hold Down timer, the other is the Keepalive Interval.

The Hold Down Timer indicates how long a router will wait between
hearing messages from it's neighbor. The Hold Down Timer defaults to
180 seconds on a Cisco router, but can be reconfigured.
cisco default setting: 60 seconds

To be certain that a BGP session stays up and functional, Keepalive

messages are exchanged.
The Keepalive Interval counts down to zero and then sends out another
Keepalive. There is no timer for route updates, as updates happen
dynamically on an incremental basis.

What are different BGP databases?

BGP Databases
Like most modern routing protocols, BGP has two separate databases
-a neighbor database and a BGP-specific database.

Neighbour Database
Lists all of the configured BGP neighbors
Router# show ip bgp summary
BGP Database
Lists all networks known by BGP along with their attributes.
Router# show ip bgp

What is the major difference between BGP and IGP route

summarization?
When a summary address is created with an IGP (EIGRP, OSPF, and IS-
IS), the specific routes of the summary are not advertised. BGP
advertises the summary, and all the specific routes of the summary
unless they are specifically suppressed.

What does r RIB-Failure mean in the show ip bgp command output

R1> show ip bgp
BGP table version is 5, local router ID is 200.200.200.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

r> 6.6.6.0/24 10.10.13.3 0 130 0 30 i
*> 7.7.7.0/24 10.10.13.3 0 125 0 30 i
A. When BGP tries to install the bestpath prefix into Routing
Information Base (RIB) (for example, the IP Routing table), RIB might
reject the BGP route due to any of these reasons:
Route with better administrative distance already present in IGP. For
example, if a static route already exists in IP Routing table.

How many links can be assigned for load balancing or sharing in

BGP
load sharing can be achieved when there are multiple (up to a maximum
of six), equal-cost links.

When is a BGP route invalid

The next-hop must be accessible and reachable for a path to a BGP
network to be valid.

BGP neighborship is not coming up. Please define the various steps
to troubleshoot it.
Answer: To troubleshoot BGP, first we need to check neighbor state
using “show ip bgp summary.”

If the state is Idle, it means that the peer address or AS is not defined
properly; if the state is Active, it means that TCP port 179 is not open,
the peer is not reachable, network congestion, or BGP misconfiguration.
Common neighbor stability problems of BGP
* Misconfigured neighbor’s IP address and AS number
* Reachability issues when interfaces other than directly connected
interfaces are used while peering (update-source issue).
* Authentication must be properly implemented (if configured)
* Router-ID must be unique

BGP session is not established

BGP uses TCP, so to discover the cause of the problem, you can start
with testing TCP connectivity. One way to do that is as simple as
/system telnet <remote-ip> 179 and check if the TCP connection can be
established, and BGP port 179 is open and reachable.

If this is eBGP, make sure you have configured multihop=yes and TTL
settings as needed. Use routing bgp peer print status to see the current
state of BGP connection.
Also note that if the remote peer is not supporting BGP Capabilities
Advertisement (RFC 2842), some extra time will be needed for session
establishment. The establishment will fail at the first time in this case,
because of unknown options in BGP OPEN message. It should succeed
at second attempt (i.e. after about a minute) and in any further attempts,
because RouterOS will remember the offending options for that peer and
not include them in BGP OPEN messages anymore.
Explain BGP attributes.
A quick copy-and-paste summary on BGP attribute categorisation.

WELL-KNOWN, MANDATORY:
AS-path: A list of the Autonomous Systems (AS) numbers that a route
passes through to reach the destination. As the update passes through an
AS the AS number is inserted at the beginning of the list. The AS-path
attribute has a reverse-order list of AS passed through to get to the
destination.

Next-hop: The next-hop address that is used to reach the destination.

Origin: Indicates how BGP learned a particular route. There are three
possible types -- IGP (route is internal to the AS), EGP (learned via
EBGP), or Incomplete (origin unknown or learned in a different way).

WELL-KNOWN, DISCRETIONARY:
Local Preference: Defines the preferred exit point from the local AS for
a specific route.
Atomic Aggregate: Set if a router advertises an aggregate causes path
attribute information to be lost.

OPTIONAL, TRANSITIVE:
Aggregator: Specifies the router ID and AS of the router that originated
an aggregate prefix. Used in conjunction with the atomic aggregate
attribute.

Community: Used to group routes that share common properties so that

policies can be applied at the group level.

OPTIONAL, NON-TRANSITIVE
Multi-exit-discriminator (MED): Indicates the preferred path into an
AS to external neighbors when multiple paths exist.
A list of path attributes is contained in BGP update messages. The
attribute is variable length and consists of three fields: Attribute type
consisting of a 1-byte attribute flags field and a 1-byte attribute code
field, Attribute length field that is 1 or 2 bytes, and a variable length
attribute value field. The attribute type codes used by Cisco are: 1-
origin, 2-AS-path, 3-Next-hop, 4-MED, 5-Local preference, 6-Atomic
aggregate, 7-aggregator, 8-community, 9-originator-ID, and 10-cluster
list.

What is a router? Or define the basic requirements of a router?

Answer: A router is a layer 3 network device used to establish
communication between different networks. Basic roles performed by a
router are:
* Inter-network communication
* Best path selection
* Packet forwarding
* Packet filtering

What is the use of routing? or Why we use routing?

Answer: By default, a router provides inter-network communication
only for directly connected networks. To establish communication
between indirectly connected networks, we require ROUTING. We can
use static or dynamic (IGP or EGP) routing, according to topology
requirement.

Forwarding decision in the routing table and route selection criteria

The main considerations while building the routing table are:

Administrative distance - This is the measure of trustworthiness of the

source of the route. If a router learns about a destination from more than
one routing protocol, administrative distance is compared and the
preference is given to the routes with lower administrative distance. In
other words, it is the believability of the source of the route.
Metrics - This is a measure used by the routing protocol to calculate the
best path to a given destination, if it learns multiple paths to the same
destination. Each routing protocol uses a different metric.

Prefix length:
To understand this better, let's look at an example. Assume a router has
four routing processes running: EIGRP, OSPF, RIP, and IGRP. Now, all
four of these processes have learned of various routes to the
192.168.24.0/24 network, and each has chosen its best path to that
network through its internal metrics and processes.
Each of these four processes attempts to install their route toward
192.168.24.0/24 into the routing table. The routing processes are each
assigned an administrative distance, which is used to decide which route
to install.

What is the difference between the ip default−gateway, ip

default−network, and ip route 0.0.0.0/0 commands?
The ip default−gateway command is used when IP routing is disabled on
the router. However, ip default−network and ip route 0.0.0.0/0 are
effective when IP routing is enabled on the router and they are used to
route any packets which do not have an exact route match in the routing
table

What is default route?

Also known as the gateway of last resort, a default route is a special type
of static route with an all-zeros network and network mask. The default
route is used to route any packets to a network that a router does not
directly know about to a next-hop router. By default, if a router receives
a packet to a destination network that is not in its routing table, it drops
the packet. When a default route is specified, the router does not drop
the packet. Instead, it forwards the packet to the IP address specified in
the default route.

What is difference in Control plane, Data plane and Forwarding

Plane?
http://networkstatic.net/the-control-plane-data-plane-and-forwarding-
plane-in-networks/

What exactly is a control plane ?

Other control plane protocols (BGP, OSPF, LDP, LACP, BFD ...) are
more clear-cut – they run between individual network devices (usually
adjacent, but there’s also targeted LDP and multihop BGP) and could be
(at least in theory) made to run across a separate control plane network
(or VRF).
Control plane protocols usually run over data plane interfaces to ensure
shared fate – if the packet forwarding fails, the control plane protocol
fails as well – but there are scenarios (example: optical gear) where the
data plane interfaces cannot process packets, forcing you to run control
plane protocols across a separate set of interfaces.

Typical control plane protocols aren’t data-driven: BGP, LACP or BFD

packet is never sent as a direct response to a data plane packet.
ICMP is different: some ICMP packets are sent as replies to other ICMP
packets, others are triggered by data plane packets (ICMP unreachables
and ICMPv6 neighbor discovery).

Trying to classify protocols based on where they’re run is also

misleading. It’s true that the networking device CPU almost always
generates ICMP requests and responses (it doesn’t make sense to spend
silicon real estate to generate ICMP responses). In some cases, ICMP
packets might be generated in the slow path, but that’s just how a
particular network operating system works. Let’s ignore those dirty
details for the moment; just because a device’s CPU touches a packet
doesn’t make that packet a control plane packet.
Vendor terminology doesn’t help us either. Most vendors talk about
Control Plane Policing or Protection, equating control plane with the
device CPU – these mechanisms usually apply to control plane protocols
as well as data plane packets punted from ASICs to the CPU.
Even IETF terminology isn’t exactly helpful – while C in ICMP does
stand for Control, it doesn’t necessarily imply control plane
involvement. ICMP is simply a protocol that passes control messages (as
opposed to user data) between IP devices.

Refer to the below website for more details.

https://sites.google.com/site/amitsciscozone/home/bgp/understanding-
bgp-4-byte
Posted by Manish Bidsar at 09:02
Email ThisBlogThis!Share to TwitterShare to FacebookShare to
Pinterest
Labels: BGP In Nutshell "With"Interview Question on BGP
1 comment:
1.
Unknown12 July 2019 at 11:43
Great one
Reply
Newer PostOlder PostHome
Subscribe to: Post Comments (Atom)
TOTAL PAGEVIEWS
278869
SEARCH THIS BLOG
Search

MY POSTS
 "DHCP SNOOPING" " DAI " "IPSG"
 ARP “Working Example & QA”
 BGP "IMP" NOTES
 BGP Attributes
 BGP Basics
 BGP In Nutshell "With"Interview Question on BGP
 BGP MCQ
 BGP Overview
 BGP Q&A
 BGP Scenarios Based Q&A
 CCNA 200-125 Tips 1: Points to Remember
 CCNA 200-125 Tips 2: Points to Remember
 CCNA 200-125: CHEAT SHEETS
 CCNP Route-300-101: Notes
 CISSP:Notes
 Cisco VPN and ASA Notes
 DHCP Interview Questions
 DHCP OPTION 82
 DNS: Why and How It Works
 Dynamic Host Configuration Protocol
 EAP: Extensible Authentication Protocols
 Enabling MD5-Challenge in WINDOWS
 Ethernet interview questions
 Exam CRAM CCNA-200-125
 Firewall Q&A
 Frequent used commands: ASA/Windows/Linux
 Gratuitous ARP "Explanation & Example"
 HTTP Tutorial and Status Codes
 Hand notes-CCNA Security 210-260-Part-1
 Hand notes-CCNA Security 210-260-Part-2
 How to find out TCP Payloads Are Identical
 Hubs vs. Switches vs. Routers
 ICMP
 ICMP Redirect
 IEEE 802.1X (dot1x) Port Based Authentication
 IP Fragmentation "Explanation & Examples"
 IP Fragmentation Q&A
 IPv4 & IPv6 “Link-Local Addresses”
 IPv4 & IPv6 “Loopback Addresses”
 IPv6 [Internet Protocol Version 6]
 Interview Q/A Routing &Switching
 Linux Commands-Cheat Sheet
 Linux: Command Line Useful Commands:
 Native Vs Default Vlan
 Network Address Translation [NAT]
 Networking Interview Q&A
 PROXY ARP
 Packet Flow through Cisco ASA Firewall
 Packet Formats to Remember
 Packet Transmission: Role of Headers and TCP-IP Protocol Stack
Layers
 Ping And Traceroute
 Puzzles and Riddles
 Python 2.7 Vs 3.4
 Python Basic Programs-1
 Python Basic Programs-2
 Python Basic Programs-3
 Python Basics -1
 Python Basics -2
 Python Basics:Cheat Sheets
 Python Dictionaries & Dictionaries Programs
 Python Functions
 Python IN Nutshell
 Python Important Notes
 Python Interview Questions-1
 Python Interview Questions-2
 Python Interview Questions-3
 Python Lists & Lists Programs
 Python OOPS Basic Examples
 Python OOPS Basic Tips
 Python Quick Reference
 Python Script:Generate Running Config
 Python Sets & Sets Programs
 Python String & String Programs
 Python Tuple & Tuple Program
 Python: (_ & __) in variable names
 Python: Difference between is and equals (==)
 Python: Interview Questions:MCQ's
 Python: Removing Duplicate IP’s
 Python: Script to open a URL
 Python: Subinterfaces on Linux Hosts
 Python: if __name__ == '__main__'
 Python:Assertion
 Python:Basic Notes
 Python:Basic Script Explanation
 Python:Decorators
 Python:Fibonacci Sequence and Memoization
 Python:IMP Programs to Practise
 Python:Lambda Expressions Map and Filter
 Python:Module & Package
 Python:Reverse a String using 5 Different Ways
 RADIUS [Remote Authentication Dial In User Service]
 RIB Vs FIB
 Rapid Spanning Tree Protocol
 Routing Basics
 STP NOTES
 STP Vs RSTP
 STP-BPDU GAURD AND BPDU FLITER
 STP-BPDU TYPES
 STP-PortFast
 STP-ROOT GUARD
 Scenarios Based Q&A
 Spanning Tree Interview Q & A
 Spanning Tree Protocol
 Spanning Tree Protocol:PPT
 Spirent [STC] points to remember!!
 Static Route Explanation with Example
 TCL EXPECT TUTORIAL
 TCL File Handling with Examples
 TCL IMP THINGS TO REMEMBER
 TCL INTERVIEW QUESTIONS -PART2
  TCL Interview Question -Part 1
 TCL List & Basic List Programs
 TCL NAMESPACE
 TCL Overview
 TCL PACKAGES
 TCL PROC
 TCL String
 TCL-Arrays with Examples
 TCL-Regular Expression Examples
 TCL-Regular Expression Explanation
 TCP Interview Questions
 TCl Basic Programs
 TestCases for Elevator
 Traceroute “Working & Example”
 VLAN & VLAN Types
 VPN:Detailed Notes
 VRRP virtual MAC address
 VRRP-Explanation with Example
 Virtual Private Network:VPN
 What happens when you ping a website
 Writing Test Cases:Basic Q & A

BLOG ARCHIVE
 ► 2016 (35)
 ▼ 2017 (71)
o ▼ January (14)
 TCL
NAMESPACE
 Packet Formats to
Remember
 BGP Overview
 BGP MCQ
 BGP Q&A
 EAP: Extensible
Authentication
Protocols
 BGP Basics
 IEEE 802.1X
(dot1x) Port
Based
Authentication
 DHCP OPTION
82
 BGP "IMP"
NOTES
 BGP In Nutshell
"With"Interview
Question on BGP
 BGP Scenarios
Based Q&A
 Routing Basics
 RIB Vs FIB
o ► February (13)
o ► March (3)
o ► August (14)
o ► September (6)
o ► October (12)
o ► November (9)
 ► 2018 (24)
 ► 2019 (1)
TECHNICAL
LINKS
 BGP NOTES
 CCIE Blog
 CCIE-
Security-Notes
 CCNA
Tutorial
 Cisco
Certification
Books
 Cisco
Dreamer
 Cisco Easy
 CISCO-FMC-
FTD
 Coding
Online
 Dumps
 FAQ:IP
Routing
 Firewall.CX
 GNS3Vault
 IT Blogs
 Kevin
Wallace-Youtube
 Online
SubnetCalculator
 PluralSight
 Python Cheat
Sheets
 Python
Problems
 Python
Tutorial
 Python
Tutorial-Python-
Site
 Python-
 Coding Standard
 Python-
Download
 Python-
Regex-Practise
 Regexp
 SNMP-Wiki
 Strongswan
 Subnetting
Practice
 TCL Tutorial
 Tutorialspoint
NON-
TECHNICAL
LINKS
 ACT
 Bangalore
One
 EPF
 IELTS
 ITR
 Lecture-PPT
 PF-Passbook
 SkillSet
 Sphere Social
 TAX-
Information
 TDS
 UAN-PF
Picture Window theme. Powered by Blogger.