Continue....
Border Gateway Protocol 
BGP-version 4- Part 7

BGP RIB Failure



Sometimes when configuring BGP we come accross routes that show rib-failure.  
BGP RIB-Failure is a situation where some routes from the BGP process cannot be installed in the main routing table due to different reasons::

• A route with a better administrative distance is already installed in the routing table.
• Installing the route in the routing table is causing the configured route-limit for a particular VRF to be exceeded. 
• A memory problem on the BGP speaker prevents the route from getting installed in the RIB,

Irrespective of BGP RIB failure cause, all the routes are advertised to other BGP peers through BGP and those routes are treated there independently on destination BGP router based on above condition of RIB failure.


Here we discuss one of the condition.


BGP routes with higher administrative distance than other route sources were silently ignored (similar to all other routing protocols) but you can display BGP routes that are not inserted in the IP routing table with the "show ip bgp rib-failure" command, The output explains why the BGP route was not inserted in the IP routing table. Contrary to all other routing protocol, BGP routes that are not used due to higher administrative distance are still advertised to all BGP peers, unless you configure "bgp suppress-inactive" command.


What exactly does this mean? Have a look at this output:

R3#sh ip bgp    Network          Next Hop            Metric LocPrf Weight Path r> 172.16.220.0/24  172.16.220.1        0             0 3 i *> 192.68.0.0/16    172.16.220.1        0             0 3 {2,1} i *> 192.68.10.0      172.16.220.1                      0 3 2 i

172.16.220.0/24 is showing up as r> in BGP table– but what exactly is going on? There is a command you can use to see what’s happened: show ip bgp rib-failure

R3#sh ip bgp rib-failure Network            Next Hop                      RIB-failure   RIB-NH Matches 172.16.220.0/24    172.16.220.1        Higher admin distance              n/a

Here it’s clearly indicating that the BGP could not be injected into the routing table as there is already a route with a higher administrative distance there. This is proved with the ip routing table below:

R3#sh ip route 172.16.220.0 Routing entry for 172.16.220.0/24   Known via "connected", distance 0, metric 0 (connected, via interface)   Routing Descriptor Blocks:   * directly connected, via FastEthernet0/1       Route metric is 0, traffic share count is 1

As this is not best route for the routing table, it was not injected into the IP routing table but it is a valid and best bgp route, therefore it is still advertised to other BGP peers.

BGP PEER GROUPS


Configuring one or two iBGP neighborship may not consume much time or results any overhead but in a large ISP environment, it is often required to config several iBGP neighborship. This consumes lots of time and configuration overhead. It has also impact on routers memory and processing power.


Instead of configuring each individual IBGP neighborship seperatly, BGP Peer Groups concept was designed to allow do configuration in groups and saves routers memory instead of applying same set of configuration commands for each individual neighbor again and again.


example:
There are three routers R1, R2 and R3 and we need to create neighborship between loopback addresses of R1 to R2 and R1 to R3.


R1(lo1 1.1.1.1)=====IBGP======R2(lo1 2.2.2.2)
R1(lo1 1.1.1.1)=====IBGP======R3(lo1 3.3.3.3)


Creating Peer Group Config on R1


R1(config-router)#neighbor PEERS1 peer-group
R1(config-router)#neighbor PEERS1 remote-AS 200
R1(config-router)#neighbor PEERS1 next-hop-self
R1(config-router)#neighbor PEERS1 update-source lo1


Here PEERS1 is the peer-group name that we created.


Applying Peer-Group Config


Neighborship between R1 and R2
R1(config-router)#neighbor 2.2.2.2 peer-group PEERS1


Neighborship between R1 and R3
R1(config-router)#neighbor 3.3.3.3 peer-group PEERS1




                                        Please read BGP-version 4- Part 7 for more information.

Continue....
Border Gateway Protocol 
BGP-version 4- Part 5



BGP Next Hop and AS PATH processing.


BGP Next Hop: BGP by default take whole AS as single entity and therefore, as already discussed, BGP next hop does not change in iBGP updates assuming that all the routers are in same subnet (shared multi-access domain or Ethernet). For eBGP updates, next hop is changed to make inter-AS reach-ability which is the primary goal of BGP.


AS PATH: As far as BGP updates travel through the Autonomous Systems hop-by-hop( here hop means one AS), AS PATH is another attribute which travels along with that BGP update. It means, once a BGP update NLRI (prefix) leaves the autonomous system, AS number is pre-pended to AS PATH. When an AS receive an update with its AS number in AS PATH, it discards the route. This is an inbuilt loop prevention mechanism in eBGP.


Network Layer Reachability Information (NLRI): It is BGP terminology for prefix and a field in BGP update message.


below example will dictate the things in pretty simple way.

We will see default next hop and AS path processing for prefix 172.16.1.0/24.


Router R1 which is residing in AS 100, will process this prefix in its routing table. Prefix will have next hop address 0.0.0.0 because route is originated in same AS where R1 belongs. Here AS PATH will be empty (^$).


Router R2 will receive the prefix from R1. As this is inter-AS routing, now next hop will be changed to 1.1.1.1. It means 1.1.1.1 is the gateway to reach the prefix 172.16.1.0/24. AS PATH will have 100 in the list indicating that route is originated in AS 100.


Router R3 is in same AS where R2 is residing, therefore, it will not change next hop for this prefix assuming that both the routers are in same subnet. Here next hop will remain 1.1.1.1.
AS PATH also will remain same.


Router R4 receives the prefix from R3 which is eBGP neighbor, therefore, Next Hop will be changed now to 2.2.2.2. Now router 2.2.2.2 is the gateway for the prefix. AS PATH list will prepend AS 200. Now AS path will be 200,100.


Similarly, Router R5 will not change next hop and AS path . Next hop will remain 2.2.2.2 and AS path 200,100.


On Router R6, new Next hop will be 3.3.3.3 and AS PATH will be 300,200,100. This AS path concludes that route has processed AS 300, AS 200 and AS 100 through the path and AS 100 is the originator.


Update Source

As already stated, BGP neighbors do not need to be directly connected and can use their loopback interfaces to form the peer relationships. 
Sometimes, it can be beneficial to use loopbacks to form peer relationships rather than the actual interface facing the potential neighbor. For example losing one of the physical connections does not necessarily mean the BGP peering is lost; as long as the routers have reachability to each other´s loopback addresses, the BGP peer relationship will remain up.
For example, consider a router that has two paths to a BGP speaker. The interfaces are numbered like this: 


Router1: Serial0, 192.16.1.1 /24, Serial2, 172.16.1.1 /24, loopback0, 1.1.1.1
Router2: Serial0, 192.16.1.2/24, Serial2 172.16.1.2/24, loopback0, 2.2.2.2 


We could configure Router1 like this: 


router bgp 200 
neighbor 192.16.1.2 remote-as 200 


In this case, BGP would automatically use 192.16.1.1 as the update source but if the remote peer´s serial0 interface is shut down or goes down for another reason, the peer relationship would be lost even though Router2 is still available via some other means.


Instead of using one of the physical interfaces, we can use the loopbacks on each router to establish the BGP neighborship, we can use "update-source" command.


neighbor <loopback ip> update-source <loopback_interface>


The configurations would look like this: 


Router1: 
router bgp 200 
neighbor 2.2.2.2 remote-as 200 
neighbor 2.2.2.2 update-source loopback0 


Router2: 
router bgp 200 
neighbor 1.1.1.1 remote-as 200 
neighbor 1.1.1.1 update-source loopback0 


In this case, BGP peer relationship will remain in place in spite of any physical link goes down because router is somehow reachable.

                          Please read BGP-version 4- Part 6 for more information.

Continue....
Border Gateway Protocol 
BGP-version 4- Part 6

BGP "Next Hop Self" Command



Please take the fact into consideration where we discussed BGP next hop processing in iBGP advertisement. As we already discussed that in iBGP route advertisement, next hop address do not change. But with this command: "next-hop-self", we will be able to change  next hop address to BGP source address rather than letting the protocol choose the nexthop. 


for example:
Suppose we have two potential IBGP neighbors Router1 (172.16.1.1) and Router 2 (172.16.1.2). When we use below commands on Router 1, it means that Router1 has been configured to change the next hop address of the routes before updating them to Router 2. 


R1#router bgp 100 
neighbor 172.16.1.2 remote-as 100 
neighbor 172.16.1.2 next-hop-self


For every prefix that is being advertised by Router 1 to Router 2 will have a next hop address 172.16.1.1 no matter which AS it is originated from.



BGP Routing Policy (Path Selection Criteria)


Below BGP route selection criteria will apply when we have same route with different Next hop addresses.


BGP route selection
1. Next Hop should be reachable.
2. Highest Weight is preferred (local to router)
3. Higher local preference is preferred(global within autonomous system)
4. Origin (Routers self originated routes are preferred)
5. Shortest AS-PATH (compare length only)
6. Origin Code --IGP< EGP <Incomplete(?)
7. lowest MED is preferred
8. Prefer eBGP path over iBGP
9. Prefer path through closest iBGP neighbor
10.Prefer oldest (most stable) route in eBGP neighbors.
11.Lowest BGP router ID
12.Lowest IP address


The best BGP routes are then copied into the IP routing table


Mnemonic


We Love Others And Original MECORI

We=Highest Weight
Love=Highest local preference
Others=Originated locally(router originated)
And=Shortest AS path
Original=Origin code (AS originated routes)
M=Lowest MED
E=Prefer eBGP
C=Closest iBGP neighbor
O=oldest eBGP neighbor
R=Lowest router ID
I=Lowest IP address


Administrative Distance ( to identify the routing protocol that is to be preferred)

    Based on BGP route selection criteria, only one best route is taken into consideration and then best route is put into routing table on the basis of AD value(compare BGP and IGP).

BGP Table structure and process tree.


BGP has three tables to maintained Neighbor Table, BGP table and local-rib(bgp routing table) but BGP routing process has further three parts. Sometimes, these parts are reffered as table. One for storing incoming routes from neighbours, one for sending the routes to neighbours and one for installing the routes where you actually find the routes with next-hop address. The tables are given below:-
a) Adj-RIB-in
b) Adj-RIB-out
c) Loc-RIB


Decision Process


Adj-RIB-in--->inbount policy--->BGP decision process--->Local-RIB--->Outbound policy--->Adj-RIB-out




Adj-RIB-in stores the unprocessed information received from its peers. Here the best path selection occurs as per BGP attributes and after conformation path is entered into the local bgp table i.e Loc-RIB. From the local RIB table it conform the next-hop address if it reachable by IGP then the route is entered into the main routing table. 


Or more logically we describe the process this way. 


1.All the routes from peer BGP neighbor are included in Adj-RIB-in table. Each BGP peer has its own Adj-RIB-in table.lets see the Adj-RIB-in:


R6#show ip bgp neigh 100.5.5.5 received-routes




2.After applying inbound policy and BGP decision process tree, prefixes are including in Local-RIB table.
lets see the Local-RIB:


R6#show ip route bgp


3.After applying outbound policy, prefix are kept in Adj-RIB-out table and will be sent to specific bgp peer. It means that router has a adj-RIB-out table for each bgp peer. lets see the Adj-RIB-out table:


R6#show ip bgp neigh 100.5.5.5 advertised-routes

                                        Please read BGP-version 4- Part 7 for more information.

Continue....
Border Gateway Protocol 
BGP-version 4- Part 4



BGP Next Hop Processing

1. BGP next hop is set to router’s own address on EBGP sessions. Or you can say, next hop address is changed on eBGP advertisement.

For example, when PE-B sends BGP prefix 10.0.1.0/24 (with next-hop 10.0.0.1) to X3, it sets BGP next hop to 192.168.2.1.


But, we can always set the BGP next hop to any value you like with an outbound route-map. But, First reason, we do not prefer it because, it is risky (because it is hard to check whether the next hop you advertise is actually reachable) and second reason is that you do not want neighboring AS to know your internal next hop addresses.

Exceptions:


EBGP next hop is not changed if the BGP next hop in the BGP table belongs to the same IP subnet as the EBGP neighbor to which the update is sent. 


Example: X1 sends BGP prefix 172.16.0.0/16 to PE-A. Next hop is set to the source address of the EBGP session between X1 and PE-A (192.168.0.1). When PE-A propagates the BGP prefix to X2, it does not change the next hop (X1, PE-A and X2 are in the same subnet).


If you still want to change next hop in this case, next-hop-self command can be used towards eBGP session where you want to advertise the routes.


Example: Assuming neighbor 192.168.0.2 next-hop-self is configured on PE-A, the BGP next hop of all BGP routes sent to X2 from PE-A will be 192.168.0.3 and the traffic between X1 and X2 will flow through PE-A.


   2.  For iBGP route advertisement, next hop address will not be change.


All routers within an autonomous system are assumed to be able to reach the same set of subnets (advertised through IGP). Therefore, when an AS edge router propagates external BGP prefixes to internal BGP peers, it does not change the BGP next hop.


example: X1 sends BGP prefix 172.16.0.0/16 with next hop 192.168.0.1 to PE-A. Assuming neighbor 10.0.0.2 next-hop-self has been configured on PE-A, the BGP next hop of the BGP route sent to RR will be 10.0.0.1.
So you have two options:

• Redistribute external subnet (eBGP next hop) into IGP.it is never a good idea to allow external links.
• Alternatively, we can use next-hop-self on ingress router towards iBGP session. Along with, we also require to set the next hop address as loopback address of ingress router.

Second method is most preferred.


Other important info to note about next hop processing:


BGP next hop is set to 0.0.0.0 for routes with unknown next hops, connected interfaces, static routes to null 0 or summary routes configured with aggregate-address router configuration command. 


BGP route reflectors should not change any attribute of the routes they reflect. Thus all BGP attributes including next hop advertised by an edge router is reflected unchanged by Route Reflectors.




                    Please read BGP-version 4- Part 5 for more information.

Continue....
Border Gateway Protocol 
BGP-version 4- Part 3



BGP Neighbor Configuration.


Start BGP Neighborship


Unlike all other routing protocols, BGP neighborship is unicast by default. Other difference is that BGP keeps neighborship establishipment separate from actual route advertisement. In other routing protocols (IGPs), there is no need to statically configure the neighbors. It means, BGP neighbors are not discovered automatically, they are statically configured. This is why it is called a connection oriented protocol.


R1(config_router)#neighbor <neigbor IP address> remote-as <neighbor AS number>


There are two ways to get subnets into BGP

• With "network" Command
• With Redistribution

BGP Network Command (Subnet advertisement)


network <subnet> mask <mask> ===>>  classless
network <subnet/ip address>  ====>>classful


If you leave the mask keyword out it uses the default.


Take into consideration that the network command reveals the actual subnet to advertise, not the interface participating in the routing process unlike all other routing protocols.




Redistribution in BGP


Use the redistribute command to redistribute routes from one routing domain to another.
The redistribute command is used to inject routes from one routing domain into another routing domain. You can conditionally control the redistribution of routes between routing domains by defining route maps


Q.Can "redistribute" command redistribute the loopback interface/addresses?

• redistribute connected (optional-route map)
• redistribute static (optional-route map)
• redistribute ospf/rip/is-is/eigrp

If you have a need to dynamically advertise directly connected networks, you might choose to "redistribute connected " command to advertise connected networks into the local BGP process, which will limit the amount of static configuration. You could get the same result by using the BGP "network" command, which would require more configuration and dynamic updation of routes.


This is not a recommended practice to advertise IGP routes into BGP via network command because IGP routes tend to change often and you will not want BGP to constantly add, change, or remove IGP redistributed routes on a regular basis. Rather, you can configure BGP to have IGP routes redistributed directly into BGP by using the "redistribute protocol(ospf/rip/eigrp)" command. 


Resetting BGP Neighborship

If you change a BGP filter, weight, distance, version, or timer, or make a similar configuration change, we must reset BGP connections for the configuration change to take effect. Use either of the following commands in EXEC mode to reset BGP connections:

Command	Purpose
clear ip bgp <neighbor-address>	Reset a particular BGP connection.
clear ip bgp *	Reset all BGP connections.

Soft reset 

The traditional method of clear ip bgp * is disruptive. Soft reconfiguration was introduced in Cisco  to facilitate non disruptive changes in BGP.

clear ip bgp {* | address | peer-group-name} soft out

Soft reset allows policies to be configured and activated without clearing the BGP session like clear ip bgp * command.  It is always applied on outgoing routes and does not have any effect on incoming policy change. This command is always preferred because of its non disruptive nature.


If all BGP routers support the route refresh capability, use the clear ip bgp {* | address | peer-group name} in command. You need not use the soft keyword, because soft reset is automatically assumed when the route refresh capability is supported.


For example::

The following example clears all entries from the host name-and-address cache (hard reset):

clear host *

The following example clears the inbound session with the neighbor 131.108.1.1 without resetting the session:

clear ip bgp 131.108.1.1 soft in

The following example clears the outbound session with the peer-group corp without resetting the session:

clear ip bgp corp soft out

                                  Please read BGP-version 4- Part 4 for more information.

Continue....
Border Gateway Protocol 
BGP-version 4- Part 2


BGP Split Horizon


Routes learned from eBGP neighborhip on ingress router will never be advertised to another iBGP peer in the same AS.


This rule is BGPs loop prevention method in iBGP. Rule is enabled by default assuming that there is a full mess between all the BGP running Routers within an AS. So to prevent any loop in full BGP mess, this rule is kept enabled.


It is also unreal to have BGP neighborship from ingress BGP router with all BGP running routers in an AS(or ISP environment) or you can say ONE-to-ALL relationship is not recommended when number of bgp routers are in thousands which will increase processre overload and config overhead. 


In this case also, Route Reflector came to the picture. Neighbor relationship is established with RRs(backup and primary). RR as the name suggest RRs reflect the route learned from one bgp router to another bgp client or non-client routers. We will discuss Route Reflector concept in detail in coming sessions.


BGP Attributes


BGP path attributes describe the values that belong to the the routes sent in a BGP UPDATE message. All attributes contained in an UPDATE message apply to all routes specified by the NLRI field of the UPDATE.


Well Known
Attributes those are supported by all BGP running routers and processes.

• Mandatory: Attributes those are supported by all BGP running processes and also must be in all BGP update message. For example: ORIGIN. AS-PATH, NEXT HOP
• Discretionary:Attributes those are supported by all BGP running processes and administrator decides whether to include them in BGP update message or not. For example: LOCAL PREFERENCE, ATOMIC AGGREGATE

Optional
 Some BGP processes on different routers/devices may not support these attributes.

• Transitive: These attributes traverse autonomous systems other than its own. For example: AGGREGATER, COMMUNITY.
• Non-Transitive: These attributes remain in autonomous system where they are generated from. For example : MED, Originator_ID, CLUSTOR_LIST.

Note: Why BGP WEIGHT attribute does not fall under any path attribute category?


eBGP (Non-directly connected) neighbors


By the rule, eBGP neighbor-ship should be directly connected. To overrule this rule, neighbor "ebgp-multihop" command is used.


In other words, to accept and attempt BGP connections to the external peers residing on networks that are not directly connected, we need to use either 'neighbor ebgp-multihop ' or 'neighbor ttl-security ' command. These two commands are interchangable. We can use another command 'neighbor disable-connected-check' to accomplish the same task if the BGP neighbor is one-hop away.


Router1(config_router)# neighbor 5.5.5.5 ebgp-multihop 2
Above command means eBGP neighbor is 2 hops away.


Difference between "ebgp-multihop" and "ttl-security" command


This is additional   lightweight security mechanism  in BGP to protect BGP peering sessions from CPU utilization-based attacks. These types of attacks are typically brute force Denial of Service (DoS) attacks that attempt to disable the network by flooding the network with IP packets that contain forged source and destination IP addresses in the packet headers.



iN SUMMARY, Where ebg-multihop depends on routers to drop it as the ttl is decremented to 0, TTL Security expects a minimum value. 


neighbor ebgp-multihop <ttl value>   
As already said TTL value for packet will be set here and decreaments as it passes hop by hop.


neighbor ttl-security hops <number of hops>


Clearly specifies how many hops away the ebgp neighbor is.
In this case routers set initial TTL to 255 and will not accept packets with TTL value of lest than 255-<hops>


In this example


If "neighbor 10.1.1.1 ttl-security hops 2" is set.

example sets the hop count to 2 because the hop-count argument is set to 2 and BGP will accept only IP packets with a TTL count in the header that is equal to or greater than 253 (253 or 254). If a packet is received with any other TTL value in the IP packet header, the packet will be silently discarded.


If we are using Router1(config_router)# neighbor 5.5.5.5 ebgp-multihop 2 command, TTL value will be taken as 2 and 1 only but hop count is still 2. This given an opportunity to hacker to reduce TTL value to a significant number and sent fake IP packets to cause high CPU utilization.


So this way ttl-security helps reduce the opportunity for an attacker to be successful, due to perhaps not knowing how many hops are required between the attacker and the BGP speaker. 

When this feature is enabled, BGP will establish or maintain a session only if the TTL value in the IP packet header is equal to or greater than the expected TTL value configured for the peering session. This feature only verifies the number of hops that separate the two BGP peers. The BGP peering session can still expire if keepalive packets are not received. If a packet is received with a TTL count that is less than expected number, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. 

Command "neighbor disable-connected-check"


This option (disable-connected-check) does not increment TTL but relies on the fact that the routers ARE directly connected only peering between loopbacks is used. The difference between this and ebgp-multihop is that in the latter one we can tune TTL value allowing multiple transit routers between the two BGP peers. In the former option (disable-connected-check), the routers must be directly connected (1 hop since TTL=1).

                                              Please read BGP-version 4- Part 3 for more information.

Border Gateway Protocol 
BGP-version 4- Part 1


First Internet-How BGP evolved.

ARPANET-first internet backbone(core Gateway and non-core Gateway)

• ARPANET core gateways used the Gateway-to-Gateway Protocol, to exchange routing information.In addition to this role, it had to route data grams that were passing through the core system.
• ARPANET used Exterior Gateway Protocol (EGP) to collect connectivity information from non-core Gateways.

In the ARPANET system, the core gateways which made up the backbone were maintained by a central authority, the Internet Network Operations Center(INOC). They provided reliable and authoritative routes for all possible Internet networks, and connected the ARPANET to the other Internet networks


Non core-gateways were maintained by the organizations responsible for the individual Autonomous Systems and forwarded information about networks in their areas to the core gateways using EGP.


NSFNET-replaced ARPANET with new technological backbone and completely based on AS concept.


Model was different in aspect that it provided space for multi-core Internet during development though it was also initially based on single core Internet(NSFNET in centre). Its routing architecture and protocols have evolved accordingly.


After evolution of BGP in NSFNET, this requirement was eliminated that NSFNET will play central role. Thereon Internet is multi-core network in its present form.


Why there was a need of a defined and true exterior gateway protocol like BGP

• Most significant reason is a Single Internet backbone concept resulted to slow core due to scarcity of resources. Therefore, solution was not salable at all.
• High processing time and CPU overhead for EGP updates (With EGP the complete information is exchanged periodically usually every 3 minutes).
• As part of the BGP authentication mechanism, the protocol allows BGP to carry an encrypted digital signature in every BGP message. There was no such mechanism in EGP.
• EGP did not have any support for CIDR and summarization.
• EGP did not allow an AS to advertise any route that doesn't belong to that particular AS. Means there was no concept of AS path.
• Recall that the EGP was designed as a protocol to exchange reachability information between autonomous systems, rather than a true routing protocol. Therefore, there was not any loop prevention mechanism to make it simple.
• No support for path attributes and policy routing.

Therefore, even if one assumes extreme instabilities of BGP, its worst case behavior will be the same as the steady state behavior of EGP.



BGP History

• BGP-4 is the successor of BGP v2 and v3 and replaced EGP
• Design to route traffic through Autonomous System.

BGP facts

• Two flavors- iBGP and eBGP
• BGP uses TCP port 179 and currently in verson 4
• Router with the higher BGP router-id initiates BGP session from a random port.
• BGP finds BEST PATH to a network by using the best AS-PATH. So somewhat acts like RIP by default.
• Routing Policies are configured using BGP attributes
• BGP converge slowly. BGP process waits for update timer to expire before sending updates. Explained below in details in BGP update interval section.
• Neighbor relationship is kept separate from actual network advertisement.

REASON to RUN BGP

• If you are a service provider and configuring a transit AS
• If you have redundant connection to different ISPs and whant to utilize both the links
• Advance routing policies and traffic engineering.

BGP recommendations

• Min RAM 128 MB recommended by IETF (Cisco recommends 512 MB.)
• Requires upper end IOS version to run BGP in CISCO router.

BGP Neighbor Relationship.

• Neighbors do not need to be directly connected.
• Neighbors are manually configured.
• All neighbors start in IDLE state.
• Once Neighborship is formed HELLO messages are sent in form of KEEPALIVES in every 60 secs. Dead Time is 180 secs.
• BGP neighbors are capable of MD5 authentication.

BGP update interval

BGP is a reliable protocol and designed with scalability as first objective. After initial connection setup, process does not require to send periodic updates. Instead of sending periodic updates, BGP process waits for update interval to expire and send triggered and increamental updates.

When there is a change in the network, BGP process waits for update interval time. Instead of using flash updates triggered by a change BGP waits for the expiration of the BGP advertise-interval before sending out the BGP update.In this way If there are other changes that should be advertised or changes are restored during that time the BGP process can prepare a more efficient update.

BGP update interval: after 5 secs for IBGP and 30 secs for EBGP routes.

State of BGP

• IDLE
• Active
• OPEN sent
• OPEN confirmed
• Established

Message/Packet types in BGP

• OPEN (Initialize)
• KEEPALIVES (Hello)
• UPDATE (Routing updates)
• NOTIFICATION(Errors)

Tables in BGP Router

• Neighbor Table
• BGP Table
• Routing Table

Sychronization


Routes learned via BGP must be validated by any IGP (Routing table) before they are advertised to other autonomous systems (AS) by eBGP process. If synchronization is enables(ON) Router3 will not advertise 203.0.0.0/16 route to Router5 unless that route is learned via some IGP (RIP or OSPF). Here we should note that Router 5 is in different AS.
Therefore we have two solutions::

• First, Run BGP everywhere and keep the synchronization off.
• Second, redistribute BGP routes into IGP(RIP,OSPF,ISIS), do vice versa at other end and keep the synchronization on.

In real scenario it is unreal to run BGP in every router in ISP network which will eventually slow down the backbone.


It is also not a good bgp design practice to redistribute all bgp routes to IGP and viceversa which increases configuration overhead and security risks, , therefore synchronization is kept disabled by default in order to discourage it. For many years this technique is being used and optimized.

In the diagram if Synchronisation is disabled (off) which is disabled by default on cisco router, Router 3 will advertise the route to Router 5 but it will not appear in the router table of R5(appear only in BGP table).Therefore those routes will appear as Non-best BGP routes in R5. That is the reason when R5 tries to send traffic to 203.0.0.1, the non-BGP Router (R2) will create back-hole in the path and will discard the packet.


Route Reflectors came to the rescue to get full use of BGP and optimize route learing process in BGP. Further more in conjunction with MPLS/IP VPN RRs have provided best of solution in the industry.With MPLS core routers do not require to involve in customer routing anymore. 

Remember: BGP run over TCP which is Layer 4 protocol. It is layered approach that for Layer 4 to work perfectly, all layer below should be up and running. It means, Layer 1, Layer 2 and Layer 3 should be established.


This approach put BGP in Layer 4 whereas it is said to be Layer 7 protocol which claims that all 6 lower layers should be up and running perfectly. Whatever the approach we posses, there should have IP connectivity between the potential BGP neighbor to BGP to work perfectly.


Continues...

Next Read

BGP Split Horizon
BGP Attributes and more...

Please read BGP-version 4- Part 2 for more information.

Quality of Service (QoS)-Part1


Timeline and history of QOS


Best Effort:Back to year 1992, earlier all TCP IP traffic was treated equally with the Best Effort system. Conventional Internet routers and LAN switches operates on a best effort basis. These equipment generally less expensive, less complex and faster and thus more popular than competing more complex technologies that provided QoS mechanisms.  Moreover, ordinary applications that are not time sensitive or tend not to be “drop sensitive” flourished in this environment. 


Essentially, the first person who get into the network and tries to send the data, got the bandwidth. And as more people came, they fought for the bandwidth and It became the survival of the fittest. That system works great and still works for the most of the application because applications have built in mechanism allow them to recover or slow down when bandwidth utilization at the peak. This system worked perfectly fine until the new applications came out that require priority traffic/bandwidth and need to get from source to destination very quickly.


Integrated Services: That was when the first QOS implementation was released known as Integrated Services (intServe). IETF came up with a protocol called RSVP or Resource Reservation Protocol. RSVP used to reserve bandwidth for specific applications. RSVP signals bandwidth and latency requirements for each discrete session or flow of traffic, and uses constant messaging to ensure the bandwidth and latency requirements can be maintained throughout the call. For example, you reserved bandwidth at every router for that particular type of application and it guarantees that no matter what bandwidth is reserved to that application. In case that application doesnt use that bandwidth, no other application can use that unused bandwidth. This method worked great, until a lot of application that needed bandwidth came out and there was a need felt to utilized that unused bandwidth. Moreover, The problem with this is that it’s not too scalable, especially when you are the service provider with lots of enterprise customers making hundreds of calls each, and then add on having to carry not only the calls but all the “state” information of RSVP on a per-call basis across your backbone.


Then in late 1993 and early 1994, something else began happening to enterprise customers. Hackers started pushing out malicious, time-based software to unknowing enterprise employees and launching this Trojan software on corporate laptops and workstations. Then, when the appropriate time hit in the Trojan software code, all these infected systems turned into an attack mechanism by sending massive amounts of traffic all at once to each other. The intention was to rob you of your ability to use your campus or remote site infrastructure, thus taking down your core and business applications.


This was not pretty, and quite a few very large corporations reported at one time or another, having their core down for up to 3 days. So then in 1994 corporations switched from the mentality of “I need QoS for voice and video”, to “I need QoS to protect my business applications”.  

Differentiated Services:Seeing this was a big issue, the IETF drafters came up with DSCP or DiffServ (Differentiated Services) model. This is one of the most popular QoS method is still being used today. It can also be used with IntServe. Diff Serve gives a per hop mechanism. Means, every router you get to, will re-queue you and re-prioritise you based on different markings. Unlike RSVP, DSCP does not give any bandwidth or latency guarantees to individual traffic flows, but provides the same service hop-by-hop by using packet marking in  type of Service header in your IP packet and would treat the traffic the same 
way hop by hop. This allows more flexibility as you do not have reservations of bandwidth for a particular application that locked out all traffic abilities. Instead, you have the ability to prioritize at each point/router, and when priority traffic reach to certain level, you can go ahead and cut it off and keep it from overwhelming the network.This is scalable, however it lacks a Call Admission Control mechanism that was built into RSVP. In other words, no guarantees could be made when trying to make the call since there was not enough bandwidth, the call would be rejected.


MPLS/VPN QOS:Around year 2000, that was when we came out with MPLS/VPN Qos, MPLS is a method essentially route at layer 2. Service provided used MPLS to route the traffic from one end to another to the fastest way possible. With new QoS implementation, we were also able to use QoS in such MPLS networks and within VPN that allow people to connect from a home network with an IP phone or some sort of high priority traffic.


Auto QOS/Template:Around year 2002-2003, Cisco came out with something called as Auto Qos or Template Qos, which is essentially a automated system on Cisco routers and switches.It has a standard template filled with all required valued. But with auto QoS, there can still be lot of little tuning and tweaking that you might have to do depending on your specific network type/environment.


QOS for security:From year 2004-2005, Finally QoS is being used for security, we are seeing QoS service mechanism like NBAR. NBAR mechanism can recognize application itself instead of port numbers. This can be very helpful when any application with a traffic pattern, keep changing its port numbers and tries to get into the network.




Candidates for Quality of Service (QoS) 


An interface experiences congestion when it is presented with more traffic than it can  handle. Network congestion points are strong candidates for Quality of Service (QoS) mechanisms. The following is an example of typical congestion points:figure

Types of Traffic


Data



Data traffic can be smooth for a few application but can be burstly at the same time like FTP. An Application, 

Cetrix is very sensitive to drop and delay but it is smooth and benign whereas FTP is greedy and bursty but not that sensitive to drop and delay.

• Citrix- Smooth, sensitive to drop
• FTP-Bursty, non-sesitive to drop

Voice



Voice is very smooth. It requires constant stream of bandwidth. It is benign, ,means when start consuming traffic, it doesn't ask for more. Voice traffic is very predictable. 
For Example, audio codec G.711 (used for uncompressed stream), uses 80 kbps per call. For two calls, we need 160 kbps constant stream. But here we will not have sudden burst of traffic because it requires constant stream of bandwidth but it is very sesitive to any drop or delay.

• Smooth
• Not bursty
• Sensitive to drop/delay
• Highest priority

Video


This stream is very predictable and sensitive to drop and delay but bursty kind. Video traffic is very greedy based on a sudden burst of traffic. Nice thing is video is not as important as voice. In video conferencing, we can have voice call and sees somebodys video at the same time. But when comes to priority, voice get higher priority than video because if we drop a voice packet, people instantly notice.

• Bursty
• Greedy
• Sensitive to drop/delay
• Not as critical as voice traffic.

Villains for VOICE and VIDEO


If we have severe scarcity of bandwidth, QOS cannot help but QOS can work on these terms to improve the network performance.

• Packet Loss: Too much traffic in the network causes the network to drop packets
• Delay: Delay for packet delivery. Sometimes is referred as latency.
• Jitter= Variations in delay of packet delivery

QoS design strategies

• Best Effort Based
• Integrated Services (Int Serve)-IETF standard
• Differentiated Services (Diff Serve)-IETF standard

==> Best Effort Based

1. Just like working without QOS
2. No differenciation of traffic types-web traffic, FTP traffic, Peer-to Peer traffic (bit torrent)
3. This is default queuing method
4. No control on type of traffic
5. Original design of Internet

==>Integrated Services

1. Provides guaranteed Delivery(No other application can use it)
2. Model designed and optimized for application
3. Not scalable, most of the bandwidth wasted if unused

==>Differentiated Services

1. Identifies classes of Network Traffic
2. Allows to choose the level of services for each class.

Continue.... Search for QOS- Part2 for more reading.