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 negotiated between 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