Thursday 23 July 2015

The routing table is concerned with two types of protocols:

The routing table is concerned with two types of protocols:
PROTOCOL:- Protocol are a set of rules and regulation that define data transfer over the network. Which are rules that govern end-to-end communication between devices. Protocols are rules that govern how devices communicate and share information across a network.

  •  ROUTED PROTOCOL :-  Routed protocol is a layer 3 protocol that applies logical addresses to devices and routes data between networks. It is used to Forward the packet over the network. Examples would be IP, IPX, SPX, AppleTalk.
  • ROUTING PROTOCOL:-  Routing protocol dynamically builds the network, topology, and next hop information in routing tables. It is used Exchange information from one router to other router and to find out the best route for packet to reach the right destination. Examples would be RIP, IGRP, EIGRP,OSPF, IS-IS, BGP etc.
IP ROUTING
It is a technique in which we can interconnect two or more different network with each other and transfer data based on IP header in data packet by the help of router device and router devices used some routing protocol to find out the best route for particular destination and routing protocol used it’s metrics.
There are following types of routing:-
Ø  Static Routing
Ø  Default Routing
Ø  Dynamic Routing
STATIC ROUTING:- In static routing we define the route manually in routing table of a router.
DEFAULT ROUTING:- In default routing , router doesn’t aware about  destination network In that case We can define destination as 0.0.0.0   and their subnet mask also 0.0.0.0 . it create Only that router which has only one enter and exit interface.
Note: It is used for STUB ROUTER (A Router which has only one entry and exit point)
DYNAMIC ROUTING:-  IN this routing , we used routing protocol  they dynamically learn the route and learn next hop address and do send the own  routing information to their neighbor router and  routing information is exchanged automatically with the help of routing protocols.



ROUTING PROTOCOL
There are Two types of Routing Protocol:
1:- INTERIOR GATEWAY PROTOCOL:-  These types of protocol can communicate between two or more same autonomous system number. This types of protocol used to route the packet inside an autonomous system. They work within AS.
TYPES OF INTERIOR GATEWAY PROTOCOL:-
a.      Distance-vector Routing Protocols. Ex.- RIP, (RIP v1,v2), IGRP.
b.      Enhanced Distance-vector Routing protocol (Hybrid). Ex.- EIGRP.
c.       Link-State Routing Protocols.  Ex.- OSPF, IS-IS.
2:- EXTERIOR GATEWAY PROTOCOL:-  These types of protocol can communicate between two or more different autonomous system number. They work over AS.
TYPES OF EXTERIOR GATEWAY PROTOCOL:-
Path-vector. Ex.- BGP.(ibgp, ebgp)
METRICS– It is unit of hop count, bandwidth, Reliability, load, cost, delay, MTU (maximum transmission unit ) to identify the appropriate path. Routing metric are value that allow the router decide the best route for the data packet.
ADMINISTRATIVE DISTANCE (AD) --  AD is an integer assigned to every  rooting protocol in the range of (0 to 255). A number between 0 and 255 that expresses the level of trustworthiness of a routing information source. lower AD value routing protocol more reliable to provides routing information .
 IF two protocol have same AD then router used it’s metrics to find out the best route to data packet.
IF the AD and Metric for both protocol are the same, then the router send equal amount of packet through the connected link. This term as load balancing.
Protocol
AD Value
Connected Interface
0
Static Route
1
EIGRP
EXTERNAL EIGRP
Summary EIGRP
90 IP Protocol No. 88
170
5
IGRP
100 IP Protocol No.=9
OSPF
110 IP Protocol No.=89
IS-IS
115
RIP
120 UDP Port No.=520
BGP
External=20  TCP=179
Internal=200
Unknown
It is never used




1.DISTANCE-VECTOR ROUTING PROTOCOLS    ( RIP & IGRP)
All distance-vector routing protocols share several key characteristics:-
·         A distance –vector routing protocol select the route based on distance that is called  “HOP COUNT”.
·         Periodic updates of the full routing table are sent to  their neighbors router. Distance-vector protocols suffer from slow convergence, and are highly susceptible to loops.
·         Some form of distance is used to calculate a route’s metric.
·         The Bellman-Ford algorithm is used to determine the shortest path.
·         A distance-vector routing protocol begins by advertising directly-connected networks to its neighbors. These updates are sent regularly (RIP – every 30 seconds; IGRP – every 90 seconds).
·         Neighbors will add the routes from these updates to their own routing tables. Each neighbor trusts this information completely, and will forward their full routing table (connected and learned routes) to every other neighbor. Thus, routers fully (and blindly) rely on neighbors for route information, a concept known as routing by rumor.
·         There are several disadvantages to this behavior. Because routing information is propagated from neighbor to neighbor via periodic updates.
·         Distance-vector protocols suffer from slow convergence. This, in addition to blind faith of neighbor updates, results in distance-vector protocols being highly susceptible to routing loops.
·         Distance-vector protocols utilize some form of distance to calculate route’s metric.
·         RIP uses  hop count as its distance metric, and IGRP uses a composite of bandwidth and delay.
2 ENHACED DISTANCE VECTOR ROUTING PROTOCOL (HYBRID)   (EIGRP):-
·         It is combination of both distance-vector and link-state characteristics, and is considered a hybrid protocol.
  • It is based on distance vector algorithm.
  • It send incremental update like  link-state.
3 Link-State Routing Protocols (OSPF  & IS-IS ):-
  • These protocol send update based on the link when a link comes up and goes down it send update that time.
  • Link-state routing protocols were developed to alleviate the convergence and loop issues of distance-vector protocols. Link-state protocols maintain three separate tables:
-          Neighbor table – contains a list of all neighbors, and the interface each neighbor is connected off of. Neighbors are formed by sending Hello packets.
-          Topology table – otherwise known as the “link-state” table, contains a map of all links within an area, including each link’s status.
-          Shortest-Path table – contains the best routes to each particular destination (otherwise known as the “routing” table”)
·         Link-state protocols do not “route by rumor.” Instead, routers send updates advertising the state of their links (a link is a directly-connected network).All routers know the state of all existing links within their area, and store this information in a topology table. All routers within an area have identical topology tables.
·         The best route to each link (network) is stored in the routing (or shortest path) table. If the state of a link changes, such as a router interface failing, an advertisement containing only this link-state change will be sent to all routers within that area. Each router will adjust its topology table accordingly, and will calculate a new best route if required. 
·         By maintaining a consistent topology table among all routers within an area, link-state protocols can converge very quickly and are immune to routing loops.
·         Additionally, because updates are sent only during a link-state change, and contain  only the change (and not the full table), link-state protocols are less bandwidth intensive than distance-vector protocols. However, the three.
·         Link-state tables utilize more RAM and CPU on the router itself.
·         Link-state protocols utilize some form of cost, usually based on bandwidth, to calculate a route’s metric. The Dijkstra formula is used to determine the shortest path.
4 Path-vector: Path-vector routing protocol select the route based on the AS path. It select  a route which provides a network at least AS.



ROUTING INFORMATION PROTOCOL (RIP)
RIP is a standardized Interior Gateway, Distance-Vector protocol, designed for use on smaller networks. RIP was one of the first true Distance Vector routing protocols, and is supported on a wide variety of systems.
RIP adheres to the following Distance Vector characteristics:
1.  RIP sends out periodic routing updates (every 30 seconds)
2.  RIP sends out the full routing table every periodic update
3.  RIP uses a form of distance as its metric (in this case, hop count)
4. RIP uses the Bellman-Ford Distance Vector algorithm to determine the best “path” to a particular destination.
5.  RIP supports IP and IPX routing.
6.  RIP utilizes UDP port 520
7.  RIP routes have an administrative distance of 120.
8.  RIP has a maximum hop count of 15 hops. Any network that is 16 hops away or more is considered unreachable to RIP, thus the maximum diameter of the network is 15 hops. A metric of 16 hops in RIP is considered a poison route or infinity metric.
9.   If multiple paths exist to a particular destination, RIP will load balance between those paths (by default, up to 4) only if the metric (hop count) is equal. RIP uses a round-robin system of load-balancing between equal metric routes, which can lead to pinhole congestion.
RIP TIMERS
RIP has four basic timers:-
Update Timer (default 30 seconds) –  Indicates how often the router will send out a routing table update.
Invalid Timer (default 180 seconds) –  Indicates how long a route will remain in a routing table before being marked as invalid, if no new updates are heard about this route. The invalid timer will be reset if an update is received for that particular route before the timer expires.
A route marked as invalid is not immediately removed from the routing table. Instead, the route is marked (and advertised) with a metric of 16, indicating it is unreachable, and placed in a hold-down state.
Hold-down Timer (default 180 seconds) –   Indicates how long RIP will “suppress” a route that it has placed in a hold-down state. RIP will not accept any new updates for routes in a hold-down state, until the hold-down timer expires.
A route will enter a hold-down state for one of three reasons:
·         The invalid timer has expired.
·         An update has been received from another router, marking that route with a metric of 16 (or unreachable).
·         An update has been received from another router, marking that route with a higher metric than what is currently in the routing table. This is to prevent loops.
Flush Timer (default 240 seconds) –  Indicates how long a route can remain in a routing table before being flushed, if no new updates are heard about this route. The flush timer runs concurrently with the invalid timer, and thus will flush out a route 60 seconds after it has been marked invalid.
RIP timers must be identical on all routers on the RIP network, otherwise massive instability will occur. 
RIP LOOP AVOIDANCE MECHANISMS
RIP, as a Distance Vector routing protocol, is susceptible to loops. How can we prevent this from happening? There is several loop avoidance mechanisms:
SPLIT-HORIZON:-   Prevents a routing update from being sent out the interface it was received on. It is able to prevent counting to infinity problem over a single link. Split-horizon is enabled by default on Cisco Routers.
ROUTE POISONING :-   A router will advertise a route to an unreachable network with an infinite metric to ensure all routers do not believe any rumor about the availability of the unreachable network. Poisoned routes are placed into hold down instead of waiting for the invalid timer to expire.
It is used to prevent routing loops due to inconsistent routing updates through alternative or redundant paths.
 POISON REVERSE:-
·         When the network is stable, routers use split horizon. When a link has failed and a router received an infinite metric route, the route will be advertised out to all interfaces (route poisoning), including those prevented by split horizon.
·         This ensures that all routers on the segment receive the poisoned route and will not use the invalid route.
·         It is able to prevent counting to infinity problem.
·         It is also known as split horizon with poison reverse.
MAXIMUM HOP COUNT:-
·         Hop count metric increases each time a route passes through a router.  It is able to solve counting to infinity problem by defining a maximum hop count. This is not a good solution since packets will still loop in the network until all routers removed or flushed the bad route from their routing tables.
HOLD-DOWN TIMERS:-  
·         Prevents RIP from accepting any new updates for routes in a hold-down state, until the hold-down timer expires.

                                

TRIGGERED UPDATES:-
·         Without waiting for the regular scheduled routing update timer to expire, a router will immediately send out an update as soon as a directly connected subnet has changed state (up or down), which intends to speed up convergence time. Also known as flash updates.
Loop-avoidance features on distance-vector routing protocols are enabled and activated by default.
RIP VERSIONS
RIP has two versions, Version 1 (RIPv1) and Version 2 (RIPv2).
RIPv1:-
·         It is Classfull routing protocol, and thus does not include the subnet mask with its routing table updates. Because of this, RIPv1 does not support.
·         It doesn’t support Variable Length Subnet Masks (VLSMs). When using RIPv1, networks must be contiguous, and subnets of a major network must be configured with identical subnet masks. Otherwise, route table inconsistencies (or worse) will occur.
·         It doesn’t support Triggered Update.
·         RIPv1 sends periodic updates within 30 sec as broadcasts to address 255.255.255.255.
·         It doesn’t support authentication & Summarization.
·         It is default configure in Cisco router.
RIPv2:-
·         It is classless routing protocol , and thus does include the subnet mask with its routing table updates.
·         RIPv2 fully supports VLSMs, allowing discontinuous networks and varying subnet masks to exist. Other enhancements offered by RIPv2 include.
·         Routing updates are sent via multicast, using address 224.0.0.9.
·         Encrypted authentication can be configured between RIPv2 routers.
·         Route tagging is supported.
·         It does support authentication & Summarization
·         It does support Triggered Update.
RIPv2 can interoperate with RIPv1. By default:
         RIPv1 routers will sent only Version 1 packets.
         RIPv1 routers will receive both Version 1 and 2 updates.
         RIPv2 routers will both send and receive only Version 2 updates.
We can control the version of RIP a particular interface will “send” or “receive.” Unless RIPv2 is manually specified, a Cisco will default to RIPv1 when configuring RIP.

AUTONOMOUS SYSTEM:-- A group of networks under mutual administration  control that share the same routing methodology. Autonomous systems are subdivided by areas and must be assigned an individual 16-bit number by the IANA. The AS enable the gateway to decide which routing protocol & table to used.
Range of ASN. (1 to 65535)
·         PUBLIC ASN (1 - 65511)-- The ASN in the public range are globally unique and may be announced on the global Internet. ASN are used to uniquely identify networks or systems of networks which appear to the outside world to be running a single consistent routing policy.
·         PRIVATE ASN (65512 - 65535)--The private ASN should not be seen on the global Internet (they shouldn't be announced via your exterior gateway routing protocol). Private AS numbers are used by ISP's who use BGP confederations. Private AS numbers are also used to provide an AS number to customers with multiple connections who have no connections to any other Internet service provider.

DATA CIRCUIT-TERMINATING EQUIPMENT DCE is used to provide clocking to DTE equipment.
DCE DATA COMMUNICATIONS EQUIPMENT-- (as defined by the EIA) Electronic Industries Alliance or data circuit-terminating equipment (as defined by the ITU-T) International Telecommunication union–Telecommunication:  The mechanisms and links of a communications network that make up the network portion of the user-to-network interface, such as modems.
The DCE supplies the physical connection to the network, forwards traffic, and provides a clocking signal to synchronize data transmission between DTE and DCE devices. Compare with: DTE.  The connection to a data network is made through data communication equipment (DCE) such as a modem, using the clocking signals generated by that device.
DTE DATA TERMINAL EQUIPMENT:--  Any device located at the user end of a user-network interface serving as a destination, a source, or both. DTE includes devices such as multiplexers, routers, protocol translators, and computers.
 DTE connect computer to WAN with the help of DCE. DTE is end user equipment like router, pc. A device where a communication path begins or end is called DTE.



IGRP (INTERIOR GATEWAY ROUTING PROTOCOL)
IGRP is a Cisco-proprietary Distance-Vector protocol and interior gateway routing protocol, designed to be more scalable than RIP, its standardized counterpart. IGRP adheres to the following Distance-Vector characteristics:
·         IGRP sends out periodic routing updates (every 90 seconds).
·         IGRP sends out the full routing table every periodic update.
·         IGRP uses a form of distance as its metric (in this case, a composite of bandwidth and delay).
·         IGRP uses the Bellman-Ford Distance Vector algorithm to determine the best “path” to a particular destination.
Other characteristics of IGRP include:
·         IGRP supports only IP routing.
·         IGRP is classful routing protocol it is doesn’t support VLSM.
·         IGRP utilizes IP protocol 9.
·         IGRP routes have an administrative distance of 100.
·         IGRP, by default, supports a minimum of 100 hops. This value can be adjusted to a maximum of 255 hops.
·         IGRP uses Bandwidth and Delay of the Line, by default, to calculate its distance metric. Reliability, Load, and MTU are optional attributes that can be used to calculate the distance metric.
·         IGRP requires that you include an Autonomous System (AS) number in its configuration. Only routers in the same Autonomous system will send updates between each other.
IGRP TIMERS:-
IGRP has four basic timers:-
UPDATE TIMER (DEFAULT 90 SECONDS) :- Indicates how often the router will send out a routing table update.
INVALID TIMER (DEFAULT 270 SECONDS):-  Indicates how long a route will remain in a routing table before being marked as invalid, if no new updates are heard about this route. The invalid timer will be reset if an update is received for that particular route before the timer expires.
A route marked as invalid is not immediately removed from the routing table. Instead, the route is marked (and advertised) with a metric of 101 (remember, 100 maximum hops is default), indicating it is unreachable, and placed in a hold-down state.
HOLD-DOWN TIMER (DEFAULT 280 SECONDS) :-   Indicates how long IGRP will “suppress” a route that it has placed in a hold-down state. IGRP will not accept any new updates for routes in a hold-down state, until the hold-down timer expires.
A route will enter a hold-down state for one of three reasons:
·         The invalid timer has expired.
·         An update has been received from another router, marking that route with a metric of 101 (unreachable).
·         An update has been received from another router, marking that route with a higher metric than what is currently in the routing table (this is  to prevent loops).
FLUSH TIMER (DEFAULT 630 SECONDS):-  Indicates how long a route can remain in a routing table before being flushed, if no new updates are heard about this route. The flush timer runs concurrently with the invalid timer, and thus will flush out a route 360 seconds V after it has been marked invalid.
NOTE:-
IGRP timers must be identical on all routers on the IGRP network, otherwise massive instability will occur.
IGRP LOOP AVOIDANCE MECHANISMS
IGRP, as a Distance Vector routing protocol, is susceptible to loops. How can we prevent this from happening? There are several loop avoidance mechanisms:
SPLIT-HORIZON:-   Prevents a routing update from being sent out the interface it was 
received on. It is able to prevent counting to infinity problem over a single link. Split-  
horizon is enabled by default on Cisco Routers.
ROUTE POISONING :-   A router will advertise a route to an unreachable network with an infinite metric to ensure all routers do not believe any rumor about the availability of the unreachable network. Poisoned routes are placed into hold down instead of waiting for the invalid timer to expire.
It is used to prevent routing loops due to inconsistent routing updates through alternative or redundant paths.
POISON REVERSE:-
·         When the network is stable, routers use split horizon. When a link has failed and a router received an infinite metric route, the route will be advertised out to all interfaces (route poisoning), including those prevented by split horizon.
·         This ensures that all routers on the segment receive the poisoned route and will not use the invalid route.
·         It is able to prevent counting to infinity problem.
·         It is also known as split horizon with poison reverse.
MAXIMUM HOP COUNT:- Hop count metric increases each time a route passes through a router.  It is able to solve counting to infinity problem by defining a maximum hop count. This is not a good solution since packets will still loop in the network until all  routers removed or flushed the bad route from their routing tables.
HOLD-DOWN TIMERS:- Prevents RIP from accepting any new updates for routes in a hold-down state, until the hold-down timer expires.
TRIGGERED UPDATES:-Without waiting for the regular scheduled routing update timer to expire, a router will immediately send out an update as soon as a directly connected  subnet has changed state (up or down), which intends to speed up convergence time. Also known as flash updates.
Loop-avoidance features on distance-vector routing protocols are enabled and activated by default.
EIGRP (ENHANCED INTERIOR GATEWAY ROUTING PROTOCOL)
EIGRP is a Cisco-proprietary Hybrid routing protocol, incorporating features of both Distance-Vector and Link-State routing protocols.
EIGRP adheres to the following Hybrid characteristics:
·         EIGRP uses Diffusing Update Algorithm (DUAL) to determine the best path among all “feasible” paths. DUAL also helps ensure a loop free routing environment.
·         EIGRP will form neighbor relationships with adjacent routers in the same Autonomous System (AS).
·         EIGRP traffic is either sent as unicasts, or as multicasts on address 224.0.0.10, depending on the EIGRP packet type.
·         Reliable Transport Protocol (RTP) is used to ensure delivery of most EIGRP packets. For Ex. A router are send update packet using multicast and the packet are delivered to their neighbor is sequence, however the router didn’t receive the acknowledgement in a sequential order, then it can re-send the packet unicast. It is ensured that EIGRP is a reliable transport protocol.
·         EIGRP routers do not send periodic and full-table routing updates. Updates are sent when a change occurs, and include only the change.
·         It send incremental update to their neighbor router
·         EIGRP modification DV algorithm. It’s provides loop free failover path. 
·         EIGRP is a class full protocol till IOS version 12.4 by default and IOS version 15.0  it is by default classless protocol, and thus supports VLSMs
·         EIGRP supports IP, IPX, and Apple talk routing that’s way it is called PDM protocol dependent module.
·         Default max path for reach the destination 4. maxi 16 path
·         EIGRP Use IP Protocol  No. 88.
·         EIGRP applies an Administrative Distance of 90 for routes originating within the local Autonomous System.
·         EIGRP applies an Administrative Distance of 5 for summary route.
·          EIGRP applies an Administrative Distance of 170 for external routes coming from outside the local Autonomous System.
·         EIGRP uses Bandwidth and Delay of the Line, by default, to calculate its distance metric. It also supports three other parameters to calculate its metric: Reliability, Load, and MTU.
·         EIGRP has a maximum hop-count of 255, though the default maximum hop-count is set to 100.
EIGRP, much like OSPF, builds three separate tables:
·         NEIGHBOR TABLE:-  List of all neighboring routers. Neighbors must belong to the same Autonomous System.
·         TOPOLOGY TABLE:-  List of all routes in the Autonomous System.
·         ROUTING TABLE:- Contains the best route for each known network.
EIGRP NEIGHBORS:-It is used to maintain Neighborship.
1- First it determined that how many neighbors exist.
2- How many “hello” or “ack” will be excepted.
3- It will not receive hello till hold down time then it is erase the neighbors details from the neighbor table.
4- If it will not receive the hello then it send 16 unicast message to the neighbor. If neighbor is still un-responsible then it is erase the neighbors details from the neighbor table.
·         EIGRP forms neighbor relationships, called adjacencies, with other routers in the same AS by exchanging Hello packets. Only after an adjacency is formed can routers share routing information. Hello packets are sent as multicasts to address 224.0.0.10.
·         By default, on LAN and high-speed WAN interfaces, EIGRP Hellos are sent every 5 seconds. On slower WAN links (T1 speed or slower), EIGRP Hellos are sent every 60 seconds by default.
In addition to the Hello timer, EIGRP neighbors are stamped with a Hold timer. The Hold timer indicates how long a router should wait before marking a neighbor inactive, if it stops receiving hello packets from that Neighbor.
·         By default, the Hold timer is three times the Hello timer. Thus, on high speed links the timer is set to 15 seconds, and on slower WAN links the timer is set to 180 seconds.
·         Changing the Hello timer does not automatically change the Hold timer. Additionally, Hello and Hold timers do not need to match between routers for an EIGRP neighbor relationship to form.
NEIGHBORS  TABLE CONTAINS:-
A neighbor table is constructed from the EIGRP Hello packets, which includes the following information:
I.        IP address of the neighboring router.
II.      Local interface that received the neighbor’s Hello packet.
III.    Up time.
IV.    Hold down timer.
V.      Sequence number of  last received update.
VI.    Packet in queue.
VII.  Retransmission Time Out (RTO).
VIII.                        Smooth round Trip Time (SRTT)
TOPOLOGY TABLE CONTAINS:-
i.        Successor Route
  1. Feasible Successor Route
ROUTING TABLE CONTAINS:-
i.        Internal Route (90 AD)
  1. External Route (170AD)
  2. Summary Route (5 AD)
EIGRP TERMINOLOGY:-
A.     Successor:-   A best route to reach the destination subnet or network.
B.      Feasible Distance:-  Calculated metric of successor is called FD.
C.      Feasible successor:-  Another best route which is provides backup for successor route.
Feasible successor requirement:-  A route who’s AD/RD is less then FD of current successor.
D.     Advertise Distance/Reported Distance (AD/RD):-  A router FD will be called AD/RD for it’s neighbor.
E.      Input Event:-  An information which has capabilities to change the database.
F.       Local Computation:-  A term it has two function
a.      If successor goes down, it use feasible successor.
b.      If feasible successor is not available then it become Active for that route.
Going Active:-  It means a router it sending query to it’s neighbor for a route.
Requirement for Neighborship:
1.      Autonomous System No.
  1. K Values
  2. Authentication
  3. If you are using static neighbor ship than you have to define static neighbor ship both site.
EIGRP METRICS:-
EIGRP can utilize 5 separate metrics to determine the best route to a Destination. It is called composite metric. It contain 5 element. These elements are called K Value.
1)      Bandwidth (K1-Used)–    Slowest link in the route path, measured in kilobits
2)      Load (K2-Not used) –   Cumulative load of all outgoing interfaces in the path, given as a fraction of 255
3)      Delay of the Line (K3-Used) –   Cumulative delay of all outgoing interfaces in the path in tens of microseconds.
4)      Reliability (K4-Not used) –    Average reliability of all outgoing interfaces in the path, given as a fraction of 255.
5)      MTU (K5-Not used) –    The smallest Maximum Transmission Unit in the path.
The MTU value is actually never used to calculate the metric By default, only Bandwidth and Delay of the Line are used. This is identical to IGRP, except that EIGRP provides a more granular metric by multiplying the bandwidth and delay by 256. Bandwidth and delay are determined by the interfaces that lead towards the destination network.
By default, the full formula for determining the EIGRP metric is:
                                [10000000/bandwidth + delay/10] * 256
The bandwidth value represents the link with the lowest bandwidth in the path, in kilobits. The delay is the total delay of all outgoing interfaces in the path. As indicated above, each metric is symbolized with a “K” and then a number. When configuring EIGRP metrics, we actually identify which metrics we want EIGRP to    consider. Again, by default, only Bandwidth and Delay are considered. Thus, using on/off logic:
                            K1 = 1, K2 = 0, K3 = 1, K4 = 0, K5 = 0
If all metrics were set to “on,” the full formula for determining the EIGRP metric would be:
[K1 * bandwidth * 256 + (K2 * bandwidth) / (256 - load) + K3 * delay * 256] * [K5 / (reliability + K4)]
Remember, the “K” value is either set to on (“1”) or off (“0”).
EIGRP PACKET TYPES:-
EIGRP employs five packet types:
Hello packets                              multicast                    -------         
Update packets                          unicast or multicast   RTP
Query packets                      –      multicast                    RTP
Reply packets                       –      unicast                       RTP
Acknowledgement packets --     unicast                       -------

HELLO PACKETS:-  Hello packet are used to form neighbor relationships, and were explained in detail previously. Hello packets are always multicast to address 224.0.0.10.
UPDATE PACKETs:- Update packets are sent between neighbors to build the topology and routing tables. Updates sent to new neighbors are sent as unicasts. However, if a route’s metric is changed, the update is sent out as a multicast to address 224.0.0.10.
QUERY PACKETS:- Query packets are sent by a router when a Successor route fails, and there are no Feasible Successors in the topology table. The router places the route in an Active state, and queries its neighbors for an alternative route. Query packets are sent as a multicast to address 224.0.0.10.
REPLY PACKETS :-  Reply packets are sent in response to Query packets, assuming the responding router has an alternative route (feasible successor). Reply packets are sent as a unicast to the querying router.
·         Recall that EIGRP utilizes the Reliable Transport Protocol (RTP) to  ensure reliable delivery of most EIGRP packets. Delivery is guaranteed by having packets acknowledged using…..Acknowledgment packets!
·         Acknowledgment packets (also known as ACK’s) are simply Hello packets with no data, other than an acknowledgment number. ACK’s are always sent as unicasts.
The following packet types employ RTP to ensure reliable. Delivery via ACK’s:-
1.      Update Packets
2.      Query Packets
3.      Reply Packets
Hello and Acknowledgments (ha!) packets do not utilize RTP, and thus do not require acknowledgement.
EIGRP ROUTE STATES:-
An EIGRP route can exist in one of two states, in the topology table:
1)      ACTIVE STATE
2)      PASSIVE STATE

1)      PASSIVE STATE :-  A passive state  indicates that a route is reachable, and that EIGRP is fully converged. A stable EIGRP network will have all routes in a Passive state. When a successor goes down and route is reachable through Feasible Successors.
2)      ACTIVE STATE:-   A route is placed in an Active state when the Successor and router has no Feasible Successors or Feasible Successors fail, forcing the EIGRP to send out Query packets and recon verge.
Multiple routes in an Active state indicate an unstable EIGRP network. If a Feasible Successor exists, a route should never enter an Active state.
STUCK-IN-ACTIVE (SIA):-
When a successor goes down and router has no Feasible Successors router will come in Active state. Routes will become Stuck-in-Active (SIA) when a router sends out a Query Packet to its neighbor, but does not receive a Reply packet within three minutes. This state is called Stuck-in-Active (SIA).      
In Stuck-in-Active (SIA)  router breaks neighborship with all pears of neighbors and again reestablished neighborship.
·         In other words, a route will become SIA if EIGRP fails to re-converge. The local router will clear the neighbor adjacency with any router(s) that has failed to Reply, and will place all routes from that neighbor(s) in an Active state.
·         Stuck-in-Active (SIA) is not include previous  version of 11.0 IOS. Router send SIA query Don’t receive SIA reply  within 3 minutes  then route break the neighborship of all pear and again reestablished neighborship so all route down in 3 min..      In 15.0  Router send SIA query  and after  90 sec receive or not receive SIA reply  don’t  break neighborship I am finding that route.
LIMIT SIA QUERY:-
  1. Active timer disable ---  Only query not wait SIA reply (3 min)
  2. Summarization----  Save memory, routing  table short, not forward all route information and query to all router.
  3. Stub router ---  NO query, no wait (3 min)
EIGRP ADDITIONAL FEATURE:-
  1. Incremental update– send only changes occur.
  2. Multicast
  3. Unequal load balance --  Best FD multiple by multiplier and we get product. If another route are lower that product they are eligible for unequal load balancing. 
EIGRP Load-Balancing
By default, EIGRP will automatically load-balance across equal-metric routes (four by default, sixteen maximum). EIGRP also supports load-balancing across routes with an unequal metric.
Consider the following example:
Earlier in this section, we established that Router A would choose the route through Router D as its Feasible Distance to the destination network. The route through Router B became a Feasible Successor.
By default, EIGRP will not load-balance between these two routes, as their metrics are different (11 through Router D, 16 through Router B). We must use the variance command to tell EIGRP to load-balance across these unequal-metric links:
RouterA(config)# router eigrp 10
RouterA(config-router)# variance 2
RouterA(config-router)# maximum-paths 16
The variance command assigns a “multiplier,” in this instance of 2. We multiply this variance value by the metric of our Feasible Distance (2 x 11 = 22). Thus, any Feasible Successors with a metric within twice that of our Feasible Distance (i.e. 12 through 22) will now be used for load balancing by EIGRP.
Remember, only Feasible Successors can be used for load balancing, not Possibilities (such as the route through Router C).
The maximum-paths command adjusts the number of links EIGRP can load balance across.
EIGRP Stubs---
Consider the above hub-and-spoke environment. If Router C were to fail, Router A (the hub router) would mark the 10.2.0.0/16 route as Active, and send out Query packets to the spoke routers for an alternate path.
However, it is obvious that no other route exists to the 10.2.0.0/16 network. Thus, the querying process is a waste of bandwidth and resources.
To prevent unnecessary querying, “spoke” routers in a hub-and-spoke environment can be configured as Stub routers. A stub router builds a neighbor adjacency with its hub router(s), and will inform neighbors of its stub status. The stub router will still build the full topology table.
However, the stub router will immediately respond to any Query packets with an Inaccessible message. Neighbors will eventually stop querying the stub router, which helps EIGRP converge quicker and conserves bandwidth.
Configuration of an EIGRP stub is always performed on the spoke router:
RouterB(config)# router eigrp 10
RouterB(config-router)# eigrp stub connected
The eigrp stub command configures this router as Stub, and supports four possible parameters:
Receive-only – router will not share updates with neighbors
Connected – router will only advertise connected networks
Static – router will only advertise static networks
Summary – router will only advertise summary routes
The connected and static parameters will only advertise those networks if they have been injected into the EIGRP process, either using network statements or using route redistribution. By default, EIGRP stubs will only send connected and summary routes to neighbors.



Open Shortest Path First
OSPF is a standardized IG Classless Link-State routing protocol, designed to scale efficiently to support larger networks.
OSPF adheres to the following Link State characteristics:
·         OSPF send increment update. These update are called LSA.
·         It is use IP Protocol No. 89.
·         IT send multicast hello on 224.0.0.5, 224.0.0.6.
·         OSPF employs a hierarchical network design using Areas.
·         OSPF will form neighbor relationships with adjacent routers in the same Area. Instead of advertising the distance to connected networks, OSPF advertises the status of directly connected links using Link-State Advertisements (LSAs).
·         OSPF sends updates (LSAs) when there is a change to one of its links, and will only send the change in the update. LSAs are additionally refreshed every 30 minutes.
·         OSPF traffic is multicast either to address 224.0.0.5 (all OSPF routers) or 224.0.0.6 (all Designated Routers).
·         OSPF uses the Dijkstra Shortest Path First algorithm to determine the shortest path.
·         OSPF is a classless protocol, and thus supports VLSMs.
·         OSPF supports only IP routing.
·         OSPF routes have an administrative distance is 110.
·         OSPF uses cost as its metric, which is computed based on the bandwidth of the link. OSPF has no hop-count limit.
·         OSPF metric is called Cost.  (100mbps/bandwidth==cost)
The OSPF process builds and maintains three separate tables:
·         Neighbor table – contains a list of all neighboring routers.
·         topology table – contains a list of all possible routes to all known networks within an area.
·         routing table – contains the best route for each known network.
PROCESS ID--They are locally significant only, and have no bearing on the structure of any OSPF packet or LSA update. So you can have a separate process-id on every single router in your network if you so desire! Cisco routers may have up to 32 simultaneous processes. A single interface can only belong to a single process   (although you can redistribute to "share").
OSPF Neighbors
OSPF forms neighbor relationships, called adjacencies, with other routers in the same Area by exchanging Hello packets to multicast address 224.0.0.5. Only after an adjacency is formed can routers share routing information.
Hello & Dead Interval—
By default, Hello packets are sent out OSPF-enabled interfaces every 10 seconds for broadcast and point-to-point interfaces, and 30 seconds for non-broadcast and point-to-multipoint interfaces.
OSPF also has a Dead Interval, which indicates how long a router will wait without hearing any hellos before announcing a neighbor as “down.” Default for the Dead Interval is 40 seconds for broadcast and point-to-point interfaces, and 120 seconds for non-broadcast and point-to-multipoint interfaces. Notice that, by default, the dead interval timer is four times the Hello interval.
OSPF Designated Routers & Backup Designated  Routers
DR---  When OSPF Router are connect to a Multi  access Network then there is a responsibilities of one router who is responsible for making  Adjacency with other router that is called DR(F/R & Switch).
Ex-- If a link off of Router A in were to fail, it would flood this information to all neighbors. Each neighbor, in turn, would then flood that same information to all other neighbors. This is a waste of bandwidth and processor load.
To prevent this, OSPF will elect a Designated Router (DR) for each multi-access networks, accessed via multicast address 224.0.0.6. For redundancy purposes, a Backup Designated Router (BDR) is also elected.
OSPF routers will form adjacencies with the DR and BDR. If a change occurs to a link, the update is forwarded only to the DR, which then forwards it to all other routers. This greatly reduces the flooding of LSAs.
DR Req.
1.      DR and BDR elections are determined by a router’s OSPF priority, which is configured on a per-interface basis (a router can have interfaces in multiple multi-access networks). The router with the highest priority becomes the DR; second highest becomes the BDR.
Default Priority      = 1
Maximum Priority = 255
Default priority on Cisco routers is 1. A priority of 0 router will not participate in DR or BDR election.
2.      HIGHER ROUTER ID----Each OSPF router is identified by a unique Router ID. The Router ID can be determined in one of three ways:
-          The Router ID  you can be manually specified.
-          If not manually specified, the highest IP address configured on any Loopback interface on the router will become the Router ID.
-          If no loopback interface exists, the highest IP address configured on any Physical interface will become the Router ID.
NOTES– DR is only used to reduce the no of adjacencies..
1- Adjacencies without DR & BDR  - (n(n-1)/2)
2- Adjacencies with DR & BDR – (n*2—3)
3- Adjacencies with DR only – (n--1)
OSPF Packet Format----
Below list of the 5 types of OSPF packets:
Message Type and Packet Type  Purposes
Type-1 –  Hello-- Discovers neighbors, negotiate capabilities, establishes and maintains   adjacencies between neighbors.
Type-2 – Database Description (DBD) --Elects the Master and Slave, determines the initial sequence number for database exchange, and summarizes the LSDB contents using LSA headers during the database exchange process between routers.
Type-3 – Link-State Request (LSR) --Requests specific LS records (LSAs) that are seen during the database exchange process.
Type-4 – Link-State Update (LSU) --Sends specifically requested LS records to a neighbor and sends triggered updates upon a topology change. LSU packets are also used in the flooding process.
Type-5 – Link-State Acknowledgment (LSAck)--Acknowledges the receipt of LSU packets. A single LSAck packet can acknowledge multiple LSU packets.
OSPF Neighbors (continued) Hello contents
OSPF routers will only become neighbors if the following parameters within a Hello packet are identical on each router:
Unique Attribute                  Common Attribute 
Router ID                              Priority
 Interface & Network ID      DR & BDR Information
                                             Area ID
                                             Area Type (stub, NSSA, etc.) stub Information
                                             Prefix (Subnet Mask)
                                             Hello Interval & Dead Interval
                                             Network Type (broadcast, point-to-point, etc.)
                                             Authentication
The Hello packets also serve as keepalive to allow routers to quickly discover if a neighbor is down. Hello packets also contain a neighbor field that lists the Router IDs of all neighbors the router is connected to.
A neighbor table is constructed from the OSPF Hello packets, which includes the following information:
• The Router ID of each neighboring router
• The current “state” of each neighboring router
• The interface directly connecting to each neighbor
• The IP address of the remote interface of each neighbor
OSPF Neighbor States---
Neighbor adjacencies will progress through several states, including:
Down – When hello is not exchange between 2 ospf router that is called down. indicates that no Hellos have been heard from the neighboring router.
Attempt–  This is valid for Non Broadcast network(Frame Relay). In this state Router sends unicast hello to its Neighbors.
Init –  When a router receive hello that is call INIT. indicates a Hello packet has been heard from the neighbor, but two way communication has not yet been initialized.
2-Way – When hello is exchange between ospf router that is called 2-way.  indicates that bidirectional communication has been established. Recall that Hello packets contain a neighbor field. Thus, communication is considered 2-Way once a router sees its own Router ID in its neighbor’s Hello Packet.
Note-- Designated and Backup Designated Routers are elected at this stage.
ExStart – In this state they are elect master & slave.  indicates that the routers are preparing to share link state information. Master/slave relationships are formed between routers to determine who will begin the exchange.
 MASTER– A router who sends DBD First.
 master req– 1- Highest priority  2- Higher RID
Exchange – indicates that the routers are exchanging Database Descriptors (DBDs) master first send then slave . DBDs contain a description of the router’s Topology Database. A router will examine a neighbor’s DBD to determine if it has information to share.
DBD– It sends brief information of database.
Loading – indicates the routers are finally exchanging actual data LSR, LSU, Link State Advertisements, containing information about all links connected to each router. Essentially, routers are sharing their topology tables with each other.
Full – indicates that the routers are fully synchronized. The topology table of all routers in the area should now be identical. Depending on the “role” of the neighbor, the state may appear as:
Full/DR – indicating that the neighbor is a Designated Router (DR)
Full/BDR – indicating that the neighbor is a Backup Designated Router (BDR)
Full/DROther – indicating that the neighbor is neither the DR or BDR
 Drother to Drother (Two way or neighbor ship only hello exchange )
 Drother to DR/BDR (full sync)
On a multi-access network, OSPF routers will only form Full adjacencies with DRs and BDRs. Non-DRs and non-BDRs will still form adjacencies, but will remain in a 2-Way State. This is normal OSPF behavior.
NOTES– When OSPF sends update it add sequence no. with the update
0x80000001 to 0xffff- ffff Lower is old update and higher is new update.
When a router receive a update it check sequence no.
1- If sequence no. higher update will be accepted.
2- If sequence no. same update will be ignore.
3- If sequence no. lower update will be ignore but router will send new update to its neighbor.
OSPF Network Types---
OSPF’s functionality is different across several different network topology types. OSPF’s interaction with Frame Relay will be explained in another section
1– Cisco specific-- Broadcast Multi-Access, Point-to-Point, Point-to-Multipoint Non-broadcast
2-  Rfc Specific-- Non-broadcast Multi-access Network (NBMA, Point-to-Multipoint
Broadcast Multi-Access – indicates a topology where broadcast occurs.
·         Examples include Ethernet, Token Ring, and ATM.
·         OSPF will elect DRs and BDRs.
·         Traffic to DRs and BDRs is multicast to 224.0.0.6. Traffic from DRs and BDRs to other routers is multicast to 224.0.0.5.
·         Neighbors do not need to be manually specified.
Point-to-Point – indicates a topology where two routers are directly connected.
·         An example would be a point-to-point T1.
·         OSPF will not elect DRs and BDRs.
·         All OSPF traffic is multicast to 224.0.0.5.
·         Neighbors do not need to be manually specified.
Point-to-Multipoint – indicates a topology where one interface can connect to multiple destinations. Each connection between a source and destination is treated as a point-to-point link.
·         An example would be Point-to-Multipoint Frame Relay.
·         OSPF will not elect DRs and BDRs.
·         All OSPF traffic is multicast to 224.0.0.5.
·         Neighbors do not need to be manually specified.
Non-broadcast Multi-access Network (NBMA) – indicates a topology where one interface can connect to multiple destinations; however, broadcasts cannot be sent across a NBMA network.
·         An example would be Frame Relay.
·         OSPF will elect DRs and BDRs.
·         OSPF neighbors must be manually defined, thus All OSPF traffic is unicast instead of multicast.
Remember: on non-broadcast networks, neighbors must be manually specified, as multicast Hello’s are not allowed.
N/w Type
Hello
Dead
Automatic
Neighbor Ship
Manually
Neighbor Ship
DR/BDR
Election
Broadcast
10 Sec
40 Sec
Yes
No
Yes
Point-to-Point
10 Sec
40 Sec
Yes
No
No
Point-to-MultiPoint
30 Sec
120 Sec
Yes
No
No
Point-to-MultiPoint
Non-Broadcast
30 Sec
120 Sec
No
Yes
No
Non-Broadcast
30 Sec
120 Sec
No
Yes
Yes

OSPF Router types—
·         Internal Routers – All router interfaces belong to only one Area or regular area is called Internal router.
Area- Logical grouping of OSPF Router.
Area structure-
1- Backbone Area (0)--- Area 0 is backbone area. It provides higher IP packet transmission between regular area. That is why it’s called Transit area.
2- Regular Area (1 to 65535)--  Off Backbone Area – A part from area 0 all other area is called regular area.
3- Standard Area(single area ) A “normal” OSPF area. An area which contain entire OSPF domain itself.     
Backbone Routers – contain at least one interface in Area 0. A Router is backbone of OSPF Domain is called Backbone Router.
Area Border Routers (ABRs) – A router which connect backbone area to regular area contains interfaces in at least two separate areas
Autonomous System Border Routers (ASBRs )– A router which connects OSPF routing domain to another routing domain. contain a connection to a separate Autonomous System.
A router can become an ASBR in one of two ways:
a.      By connecting to a separate Autonomous System, such as the Internet
b.      By redistributing another routing protocol into the OSPF process. ASBRs provide access to external networks. OSPF defines two “types” of external routes:
Type 2 (E2) – Includes only the external cost to the destination network. External cost is the metric being advertised from outside the OSPF domain. This is the default type assigned to external routes.
Type 1 (E1) – Includes both the external cost, and the internal cost to reach the ASBR, to determine the total metric to reach the destination network. Type 1 routes are always preferred over Type 2 routes to the same destination.
LSAs  Types and the OSPF Topology Database
OSPF, as a link-state routing protocol, does not rely on routing-by-rumor as RIP and IGRP do.
Instead, OSPF routers keep track of the status of links within their respective areas. A link is simply a router interface. From these lists of links and their respective statuses, the topology database is created. OSPF routers forward link-state advertisements (LSAs) to ensure the topology database is consistent on each router within an area.
Several LSA types exist:
Router LSA (Type 1) – Contains Router ID of router and  a list of all links local to the router, and the status and “cost” of those links. Type 1 LSAs are generated by all routers in OSPF, and are flooded (send) to all other routers within the local (with in ) area.
Network LSA (Type 2) – It contain the DR Router ID and Generated by all Designated Routers in OSPF, and contains a list of all routers attached to the Designated Router.
Network Summary LSA (Type 3) – when the route of one area go to another area they go as Summary LSA. Generated (send) by all ABRs in OSPF, and contains a list of all destination networks within an area. Type 3 LSAs are sent between areas to allow inter-area communication to occur.
ASBR Summary LSA (Type 4) – It contain ASBR router ID. Generated by ABRs in OSPF, and contains a route to any ASBRs in the OSPF system. Type 4 LSAs are sent from an ABR into its local area, so that Internal routers know how to exit the Autonomous System.
External LSA (Type 5) – It contain the external routes which are redistributed into OSPF. Generated by ASBRs in OSPF, and contain routes to destination networks outside the local Autonomous System. Type 5 LSAs can also take the form of a default route to all networks outside the local AS. Type 5 LSAs are flooded to all areas in the OSPF system. Type 5 LSAs will be flooded to routers of all areas.
·         Group membership LSA- Multicast OSPF (MOSPF) utilizes a Type 6 LSA, but that goes beyond the scope of this guide.
·         NSSA LSA-- Type 7 NSSA External LSAs Used in NSSA area. It conation external route.
The OSPF Metric
OSPF determines the best (or shortest) path to a destination network using a cost metric, which is based on the bandwidth of interfaces. The total cost of a route is the sum of all outgoing interface costs. Lowest cost is preferred.
Cisco applies default costs to specific interface types:
Type                                                Cost
Serial (56K)                                    1785
Serial (64K)                                    1562
T1 (1.544Mbps)                                64
Token Ring (4Mbps)                         25
Ethernet (10 Mbps)                         10
Token Ring (16 Mbps)                       6
Fast Ethernet                                      1
On Serial interfaces, OSPF will use the configured bandwidth (measured in Kbps) to determine the cost:
Router(config)# interface s0
Router(config-if)# bandwidth 64
The default cost of an interface can be superseded:
Router(config)# interface e0
Router(config-if)# ip ospf cost 5
Changing the cost of an interface can alter which path OSPF deems the “shortest,” and thus should be used with great care.
To alter how OSPF calculates its default metrics for interfaces:
Router(config)# router ospf 1
Router(config-router)# ospf auto-cost reference-bandwidth 100
The above OSPF auto-cost command has a value of 100 configured, which is actually the default. This indicates that a 100Mbps link will have a cost of 1 (because 100/100 is 1). All other costs are based off of this. For example, the cost of 4 Mbps Token Ring is 25 because 100/4 = 25.
OSPF Area Types--
In order to control the propagation of LSAs in the OSPF domain, several area types were developed.
Standard Area(single area ) A “normal” OSPF area. An area which contain entire OSPF domain Itself.
Stub Area– It filter the external route and place them as default route.
Totally Stub Area- It filter the External & inter Area routes and place them as default routes.
NSSA- Not- so Stub Area– It allow an ASBR to send external routes through stub area to backbone area using LSA 7(NSSA LSA)
NOTES- Its filter the external routes coming from ABR. Is doesn’t generate default route.
Totally NSSA- It allow an ASBR to send external routes through stub area to backbone area using LSA 7(NSSA LSA)
NOTES- Its filter the external & inter area routes coming from ABR. Is does generate default route.
Virtual Link– OSPF designing say that all regular area must be connected to backbone area. If it not possible we have used Virtual link.
STUB area Limitation- Area 0 can't be stub,, virtual link are not allowed in stub area,,, all router must be agree that we part of stub area.



                         Border Gateway Protocol
Border Gateway Protocol (BGP)
BGP is a standardized exterior gateway protocol (EGP) classless path vector routing protocol, as opposed to RIP,OSPF, and EIGRP which are interior gateway protocols (IGP’s). BGP Version 4 (BGPv4) is the current standard deployment.
PATH VECTOR—It select the route based on the AS Path. IT select the route which provides a network at least AS.
BGP is considered a “Path Vector” routing protocol. BGP was not built to Route within an Autonomous System (AS), but rather to route between AS’s. BGP maintains a separate routing table based on shortest AS Path and Various other attributes, as opposed to IGP metrics like distance or cost.

BGP is the routing protocol of choice on the Internet. Essentially, the Internet is a collection of interconnected Autonomous Systems.

BGP Autonomous Systems are assigned an Autonomous System Number (ASN), which is a 16-bit number ranging from 1 – 65535. A specific subset of this range, 64512 – 65535, has been reserved for private (or internal) use.BGP utilizes TCP for reliable transfer of its packets, on port 179.

When to Use BGP
Contrary to popular opinion, BGP is not a necessity when multiple Connections to the Internet are required. Fault tolerance or redundancy of outbound traffic can easily be handled by an IGP, such as OSPF or EIGRP.

BGP is also completely unnecessary if there is only one connection to an external AS (such as the Internet). There are over 100,000 routes on the Internet, and interior routers should not be needlessly burdened.

BGP should be used under the following circumstances:
1- Multiple connections exist to external AS’s (such as the Internet) via different providers.
2-Multiple connections exist to external AS’s through the same provider, but connect via a separate CO or routing policy.
3-The existing routing equipment can handle the additional demands.

BGP’s true benefit is in controlling how traffic enters the local AS, rather than how traffic exits it.

BGP Peers (Neighbors)
For BGP to function, BGP routers (called speakers) must form neighbor relationships (called peers).

There are two types of BGP neighbor relationships:
1-iBGP Peers –200- BGP neighbors within the same autonomous system.
2-eBGP Peers -20– BGP neighbors connecting separate autonomous systems.

Note: Do not confuse an IGP, such as OSPF, with iBGP!
In the above figure, RouterB and RouterC in AS 200 would form an iBGP peer relationship. RouterA in AS 100 and RouterB in AS 200 would form an eBGP peering.
Once BGP peers form a neighbor relationship, they share their full routing table. Afterwards, only changes to the routing table are forwarded to peers. By default, BGP assumes that eBGP peers are a maximum of one hop away. This restriction can be bypassed using the ebgp-multihop option with the neighbor command (demonstrated later in this guide).
iBGP peers do not have a hop restriction, and are dependent on the underlying IGP of the AS to connect peers together. By default, all iBGP peers must be fully meshed within the Autonomous System. A Cisco router running BGP can belong to only one AS. The IOS will only allow one BGP process to run on a router.
The Administrative Distance for routes learned outside the Autonomous System (eBGP routes) is 20, while the AD for iBGP and locally-originated routes is 200.

BGP Peers Messages—
1-OPEN
2-KEEPALIVE
3-UPDATE
4-NOTIFICATION

BGP forms its peer relationships through a series of messages.

OPEN-  Open message is sent between peers to initiate the session using  TCP port 179.
OPEN message contains several parameters:
Ø BGP Version – must be the same between BGP peers
Ø Local AS Number
Ø BGP Router ID
Ø Hold-time  180 sec

KEEPALIVE -- Keepalive messages are sent periodically (every 60 seconds by default) to ensure that the remote peer is still available. If a router does not receive a KEEPALIVE from a peer for a Hold-time period (by default, 180 seconds),the router declares that peer dead.

UPDATE--  Update messages are used to exchange routes between peers. When two router become BGP neighborship then they send update m/s to each other.


Finally, NOTIFICATION messages are sent when there is a fatal error condition. If a NOTIFICATION message is sent, the BGP peer session is torn down and reset.
As a BGP peer session is forming, it will pass through several states. This process is known as the BGP Finite-State Machine (FSM):
Idle – the initial BGP state
Connect - BGP waits for a TCP connection with the remote peer. If successful, an OPEN message is sent. If unsuccessful, the session is placed in an Active state.
Active – BGP attempts to initiate a TCP connection with the remote peer. If successful, an OPEN message is sent. If unsuccessful, BGP will wait for a ConnectRetry timer to expire, and place the session back in a Connect State.
OpenSent – BGP has both established the TCP connection and sent an OPEN Message, and is awaiting a reply OPEN Message. Once it receives a reply OPEN Message, the BGP peer will send a KEEPALIVE message.
OpenConfirm – BGP listens for a reply KEEPALIVE message.
Established – the BGP peer session is fully established. UPDATE messages containing routing information will now be sent. If a peer session is stuck in an Active state, potential problems can include:
no IP connectivity (no route to host), an incorrect neighbor statement, or an access-list filtering TCP port 179.

Configuring BGP Neighbors
The first step in configuring BGP is to enable the BGP process, and specify the router’s Autonomous System (AS):
RouterB(config)# router bgp 100
RouterB is now a member of AS 100. Next, neighbor relationships must be established. To configure a neighbor relationship with a router in the same AS (iBGP Peer):
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 10.1.1.1 remote-as 100
To configure a neighbor relationship with a router in a separate AS (eBGP Peer):
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 remote-as 900
Notice that the syntax is the same, and that the remote-as argument is always used, regardless if the peering is iBGP or eBGP.
For stability purposes, the source interface used to generate updates to a particular neighbor can be specified:
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 update-source lo0
RouterC must then point to RouterB’s loopback (assume the address is 1.1.1.1/24) in its neighbor statement:
RouterC(config)# router bgp 900
RouterC(config-router)# neighbor 1.1.1.1 remote-as 100
RouterC must have a route to RouterB’s loopback in its routing table. BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
5
Configuring BGP Neighbors (continued)
Remember though: by default, BGP assumes that external peers are exactly one hop away. Using the loopback as a source interface puts RouterB two hops away from RouterC. Thus, the ebgp-multihop feature must be enabled:
RouterC(config)# router bgp 900
RouterC(config-router)# neighbor 1.1.1.1 ebgp-multihop 2
The 2 indicates the number of hops to the eBGP peer. If left blank, the default is 255.
To authenticate updates between two BGP peers:
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 password CISCO
Configuring BGP Timers
To globally adjust the Keepalive and Hold-time timers for all neighbors:
RouterB(config)# router bgp 100
RouterB(config-router)# timers bgp 30 90
The above command sets the Keepalive timer to 30 seconds, and the Holdtime timer to 90 seconds. If the configured Hold-time timers between two peers are different, the peer session will still be established, and the smallest timer value will be used.
To adjust the timers for a specific neighbor (which overrides the global timer configuration):
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 timers 30 90
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
6
Viewing BGP Neighbors
To view the status of all BGP neighbors:
RouterB# show ip bgp neighbors
BGP neighbor is 172.16.1.2, remote AS 900, external link
Index 1, Offset 0, Mask 0x2
Inbound soft reconfiguration allowed
BGP version 4, remote router ID 172.16.1.2
BGP state = Established, table version = 27, up for 00:03:45
Last read 00:00:19, hold time is 180, keepalive interval is 60
seconds
Minimum time between advertisement runs is 30 seconds
Received 25 messages, 0 notifications, 0 in queue
Sent 20 messages, 0 notifications, 0 in queue
Inbound path policy configured
Route map for incoming advertisements is testing
Connections established 2; dropped 1
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 172.16.1.1, Local port: 12342
Foreign host: 172.16.1.2, Foreign port: 179
Enqueued packets for retransmit: 0, input: 0, saved: 0
Event Timers (current time is 0x530C294):
Timer Starts Wakeups Next
Retrans 15 0 0x0
TimeWait 0 0 0x0
AckHold 15 13 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
<snip>
To view the status of a specific BGP neighbor:
RouterB# show ip bgp neighbors 172.16.1.2
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
7
BGP Synchronization
Consider the above example. AS 200 is serving as a transit between AS 100 and AS 300. BGP follows a synchronization rule that states that all routers in a transit AS, including non-BGP routers, must learn of a route before BGP can advertise it to an external peer.
Confused?
Consider the above example again. If RouterA advertises a BGP route to RouterB (an eBGP peer) for the 10.5.0.0/16 network, that same BGP route will eventually be forwarded to RouterD (an iBGP peer).
However, a blackhole would exist if RouterD then advertised that update to RouterE, as RouterC would not have the 10.5.0.0/16 network in its routing table. If RouterE attempts to reach the 10.5.0.0 network, RouterC will drop the packet.
BGP’s synchronization rule will force RouterD to wait until RouterC learns the 10.5.0.0/16 route, before forwarding that route to RouterE. How will RouterD know when RouterC learns the route? Simple! When it receives an update from RouterC via an IGP (such as OSPF), containing that route.
BGP synchronization can be disabled under two circumstances:
The local AS is not a transit between two other AS’s
All routers in the transit AS run iBGP, and are fully meshed.
To disable BGP synchronization:
RouterD(config)# router bgp 200
RouterD(config-router)# no synchronization
As of IOS 12.2(8)T, synchronization is disabled by default.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
8
Originating Prefixes in BGP
There are three ways to originate a prefix (in other words, advertise a network) into BGP:
By using network statements
By using aggregate-address statements (explained later in this guide)
By redistributing an IGP into BGP
Using the network statement informs BGP which networks to advertise to eBGP peers, not which interfaces to run BGP on. The network command can be used to inject any network from the local AS into BGP, include dynamic routes learned from an IGP, and not just the routes directly connected to the router.
However, the route must be in the routing table before BGP will advertise the network to an eBGP peer. This is a fundamental BGP rule.
Consider the above example. RouterB may inject the 10.5.0.0/16 network into BGP using the network command. However, unless that route is in the local routing table (in this case, via an IGP), RouterB will not advertise the route to RouterC.
Furthermore, the network statement must match the route exactly as it is in the routing table:
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 remote-as 900
RouterB(config-router)# network 10.5.0.0 mask 255.255.0.0
The above configuration would match the route perfectly, while the
following configuration would not:
RouterB(config-router)# network 10.5.0.0 mask 255.255.255.0
If no mask is specified, a classful mask will be assumed.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
9
The BGP Routing Table
Recall that BGP maintains its own separate routing table. This table contains a list of routes that can be advertised to BGP peers.
To view the BGP routing table on RouterB:
RouterB# show ip bgp
BGP table version is 426532, local router ID is 2.2.2.2
Status codes: s suppressed, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.5.0.0 0.0.0.0 0 0 32768 i
The route has been injected into BGP using the network command. The Next Hop of 0.0.0.0 indicates that the route was locally originated into BGP.
The Path is empty, as the route originated in the Autonomous Systems.
Notice the Status Codes of “*>”. The * indicates that this route is valid (i.e. in the routing table). The > indicates that this is the best route to the destination.
BGP will never advertise a route to an eBGP peer unless it is both valid and the best route to that destination. BGP routes that are both valid and best will also added the IP routing table as well.
To view the BGP routing table on RouterC:
RouterC# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 10.5.0.0 172.16.1.1 0 100 0 100 i
Notice that AS 100 has been added to the path, and that the Next Hop is now RouterB.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
10
BGP Route-Reflectors
Recall that BGP requires all iBGP peers to be fully meshed. Route- Reflectors allow us to bypass this restriction. Fewer neighbor connections will result in less bandwidth and CPU usage. Route-reflector clients form neighbor adjacencies with the route-reflector server. BGP updates will flow from the server to the clients, without the clients having to interact with each other. Consider the above example. In AS 100, there are three BGP speakers. Normally, these iBGP peers must be fully-meshed. For example, RouterB would need a neighbor statement for both RouterA and RouterD.
As an alternative, RouterA can be configured as a route-reflector server.
Both RouterB and RouterD would only need to peer with RouterA.
All route-reflector specific configuration takes place on the route reflector server:
RouterA(config)# router bgp 100
RouterA(config-router)# neighbor 10.2.1.2 remote-as 100
RouterA(config-router)# neighbor 10.2.1.2 route-reflector-client
RouterA(config-router)# neighbor 10.1.1.2 remote-as 100
RouterA(config-router)# neighbor 10.1.1.2 route-reflector-client
Route-reflectors are Cisco’s recommended method of alleviating the iBGP
full-mesh requirement.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
11
BGP Confederations
Confederations are an alternative method to alleviate the requirement that all iBGP routers be fully meshed. Confederations are essentially AS’s within an AS, and are sometimes referred to as sub-AS’s.
In the above example, RouterA belongs to AS 777 and RouterB belongs to AS 888. Both of those AS’s belong to a parent AS of 300. RouterA and RouterB will form an eBGP peer session.
Configuration is simple:
RouterB(config)# router bgp 888
RouterB(config-router)# bgp confederation identifier 300
RouterB(config-router)# bgp confederation peer 777
RouterB(config-router)# neighbor 10.1.1.1 remote-as 777
RouterB(config-router)# neighbor 172.16.1.2 remote-as 500
Notice that the sub-AS (777) is used in the router bgp statement.
Additionally, the parent AS must be specified using a bgp confederation identifier statement. Finally, any confederation peers must be identified.
RouterC will be unaware of RouterB’s confederation status. Thus,
RouterC’s neighbor statement will point to AS 300, and not AS 888:
RouterC(config)# router bgp 500
RouterC(config-router)# neighbor 172.16.1.1 remote-as 300
(Reference: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm#wp6834)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
12
BGP Peer-Groups
Peer-groups simplify configuration of groups of neighbors, assuming those neighbors share identical settings. Additionally, peer-groups conserve processor/memory resources by sending updates to all peer-group members simultaneously, as opposed to sending individual updates to each neighbor.
All neighbor parameters are applied to the peer-group itself. Configuration is simple:
Router(config)# router bgp 200
Router(config-router)# neighbor MYPEERGROUP peer-group
Router(config-router)# neighbor MYPEERGROUP remote-as 200
Router(config-router)# neighbor MYPEERGROUP update-source lo0
Router(config-router)# neighbor MYPEERGROUP route-reflector-client
The above configuration creates a peer-group named MYPEERGROUP, and
applies the desired settings. Next, we must “assign” the appropriate
neighbors to the peer-group:
Router(config-router)# neighbor 10.10.1.1 peer-group MYPEERGROUP
Router(config-router)# neighbor 10.10.2.2 peer-group MYPEERGROUP
Router(config-router)# neighbor 10.10.3.3 peer-group MYPEERGROUP
The above neighbors now inherit the settings of the peer-group named
MYPEERGROUP.
All “members” of a peer-group must exclusively be internal (iBGP) peers or
external (eBGP) peers. A mix of internal and external peers is not allowed in
a peer-group.
Outbound route filtering (via a distribution-list, route-map, etc.) must be identical on all members of a peer-group. Inbound route filtering can still be applied on a per-neighbor basis.
(Reference: http://www.cisco.com/warp/public/459/29.html)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
13
BGP Attributes
BGP utilizes several attributes to determine the best path to a destination.
Well-known attributes are supported by all implementations of BGP, while optional attributes may not be supported by all BGP-speaking routers. Several subcategories of attributes exist:
Well-known Mandatory – Standard attributes supported by all BGP implementations, and always included in every BGP update.
Well-known Discretionary – Standard attributes supported by all BGP implementations, and are optionally included BGP updates.
Optional Transitive – Optional attribute that may not be supported by all implementations of BGP. Transitive indicates that a noncompliant BGP router will forward the unsupported attribute unchanged, when sending updates to peers.
Optional Non-Transitive - Optional attribute that may not be supported by all implementations of BGP. Non-Transitive indicates that a non-compliant BGP router will strip out the unsupported attribute, when sending updates to peers.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
14
BGP Attributes (continued)
The following describes several specific BGP attributes:
AS-Path (well-known mandatory) – Identifies the list (or path) of traversed AS’s to reach a particular destination.
Next-Hop (well-known mandatory) – Identifies the next hop IP address to reach a particular destination.
Origin (well-known mandatory) – Identifies the originator of the route.
Local Preference (well-known, discretionary) – Provides a preference to determine the best path for outbound traffic.
Atomic Aggregate (well-known discretionary) – Identifies routes that have been summarized, or aggregated.
Aggregator (optional transitive) – Identifies the BGP router that performed an address aggregation.
Community (optional transitive) – Tags routes that share common characteristics into communities.
Multi-Exit-Discriminator (MED) (optional non-transitive) –
Provides a preference to eBGP peers to a specific inbound router.
Weight (Cisco Proprietary) – Similar to Local Preference, provides a local weight to determine the best path for outbound traffic.
Each attribute is identified by a code:
Origin
AS-Path
Next Hops
MED
Local Preference
Automatic Aggregate
Aggregator
Community
Code 1
Code 2
Code 3
Code 4
Code 5
Code 6
Code 7
Code 8
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
15
BGP “Best Path” Determination
If BGP contains multiple routes to the same destination, it compares the routes in pairs, starting with the newest entries (listed higher in the routing table), and working towards the oldest entries (listed lower in the table). BGP determines the best path by successively comparing the attributes of each “route pair.” The attributes are compared in a specific order:
Weight – Which route has the highest weight?
Local Preference – Which route has the highest local preference?
Locally Originated – Did the local router originate this route? In other words, is the next hop to the destination 0.0.0.0?
AS-Path – Which route has the shortest AS-Path?
Origin Code – Where did the route originate? The following origin codes are listed in order of preference:
o IGP (originated from an interior gateway protocol)
o EGP (originated from an exterior gateway protocol)
o ? (Unknown origin)
MED – Which path has the lowest MED?
BGP Route Type – Is this an eBGP or iBGP route? (eBGP routes are preferred)
Age – Which route is the oldest? (oldest is preferred)
Router ID – Which route originated from the router with the lowest BGP router ID?
Peer IP Address – Which route originated from the router with the lowest IP?
When applying attributes, Weight and Local Preference are applied to inbound routes, dictating the best outbound path.
AS-Path and MED are applied to outbound routes, dictating the best inbound path.
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
16
Weight
The Weight attribute is applied to inbound routes, dictating the best outbound path. It is a Cisco-proprietary attribute, and is only locally significant (and thus, is never passed on to BGP neighbors). The weight value can range from 0 – 65535, and the highest weight is preferred. By default, a route originated on the local router will be assigned a weight of 32768. All other routes will be assigned a weight of 0, by default. A weight value can be specified for all routes advertised from a specific neighbor:
RouterA(config)# router bgp 100
RouterA(config)# neighbor 10.1.1.2 weight 200
Otherwise, a weight value can be specified for specific routes from a particular neighbor. First, the prefixes in question must be identified:
RouterA(config)# ip prefix-list MYLIST 192.168.1.0/24
Then, a route-map is used to apply the appropriate weight:
RouterA(config)# route-map WEIGHT permit 10
RouterA(config-route-map)# match ip address prefix-list MYLIST
RouterA(config-route-map)# set weight 200
RouterA(config-route-map)# route-map WEIGHT permit 20
Finally, the route-map is applied to the preferred neighbor:
RouterA(config)# router bgp 100
RouterA(config)# neighbor 10.1.1.2 route-map WEIGHT in
(Reference: http://www.cisco.com/warp/public/459/bgp-toc.html#weight)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
17
Local Preference
The Local Preference attribute is applied to inbound external routes, dictating the best outbound path. Unlike the Weight attribute, Local Preference is passed on to iBGP peers when sending updates. Local Preference informs iBGP routers how to exit the AS, if multiple paths exist.
Local Preference is a 32-bit number, and can range from 0 to 4294967295.
The highest Local Preference is preferred, and the default preference is 100.
The Local Preference value can be specified for all inbound external routes, on a global basis for BGP:
RouterB(config)# router bgp 100
RouterB(config-router)# bgp default local-preference 200
RouterD(config)# router bgp 100
RouterD(config-router)# bgp default local-preference 300
Both RouterB and RouterD will include the Local Preference attribute in
updates to iBGP neighbors. Thus, RouterA (and RouterB) will now prefer
the route through RouterD to reach any destination outside the local AS.
Local Preference can be applied on a per-route basis:
RouterD(config)# ip prefix-list MYLIST 192.168.1.0/24
RouterD(config)# route-map PREFERENCE permit 10
RouterD(config-route-map)# match ip address prefix-list MYLIST
RouterD(config-route-map)# set local-preference 300
RouterD(config)# router bgp 10
RouterD(config)# neighbor 172.17.1.2 route-map PREFERENCE in
(Reference: http://www.cisco.com/warp/public/459/bgp-toc.html#localpref)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
18
AS-Path Prepend
The AS-Path attribute is applied to outbound routes, dictating the best inbound path. Two things can be accomplished with the AS-Path attribute, prepend or filter. To prepend to (or add to) the existing AS-Path results in a longer AS-Path, which makes the route less desirable for inbound traffic:
RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map ASPREPEND permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set as-path prepend 200 200
RouterB(config-route-map)# route-map ASPREPEND permit 20
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 route-map ASPREPEND out The artificial AS-Path information is not added to a route until it is advertised to an eBGP peer. RouterC’s BGP routing table will now look as follows:
RouterC# show ip bgp
Network Next Hop Metric LocPrf Weight Path
* 10.5.0.0 172.16.1.1 0 100 0 100 200 200 i
*> 10.5.0.0 172.17.1.1 0 100 0 100 i
Notice the inflated AS-Path through RouterB. RouterC will prefer the path through RouterD to reach the 10.5.0.0/16 network.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
19
AS-Path Filtering
Additionally, routes can be filtered based on AS-Path values, using an aspath access-list. This requires the use of regular expressions:
^ = Start of a string
$ = End of a string
. = Any one character
* = Any one or more characters, including none
+ = Any one or more characters
? = Any one character, including none
_ = Serves the function of virtually all of the above
The following examples illustrate the use of regular expressions:
^100_ = learned from AS 100
_100$ = originated from AS 100
^$ = originated locally
.* = matches everything
_100_ = any instance of AS 100
To configure RouterF to only accept routes that originated from AS100:
RouterF(config)# ip as-path access-list 15 permit _100$
RouterF(config)# route-map ASFILTER permit 10
RouterF(config-route-map)# match as-path 15
RouterF(config)# router bgp 50
RouterF(config-router)# neighbor 10.5.1.1 route-map ASFILTER in To view what BGP routing entries the AS-Path access-list will match:
RouterF# show ip bgp regexp _100$
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a92.shtml)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
20
Origin
The Origin attribute identifies the originating source of the route. The origin codes are as follows (listed in order of preference for route selection):
i (IGP) – Originated from an interior gateway protocol, such as OSPF. This usually indicates the route was injected into BGP via the network command under the BGP process. An origin code of “i” is most preferred.
e (EGP) – Originated from an external gateway protocol.
? (incomplete) - Unknown origin. This usually indicates the route was redistributed into BGP (from either connected, static, or IGP routes). An origin code of “?” is the least preferred.
When viewing the BGP routing table, the origin code is listed at the end of each line in the table:
RouterB# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 10.5.0.0 10.1.1.1 0 0 0 i
*> 192.168.1.0 172.16.1.2 0 100 0 900 ?
The i at the end of the first routing entry indicates the 10.5.0.0 network was originated via an IGP, probably with the BGP network command. The 192.168.1.0 network was most likely redistributed into BGP in AS 900, as evidenced by the ? at the end of that routing entry.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
21
MED
The MED (MultiExit Discriminator) attribute is applied to outbound routes, dictating the best inbound path into the AS (assuming multiple paths exist). The MED is identified as the BGP metric when viewing the BGP routing table. A lower metric is preferred, and the default MED value is 0.
In the above example, there are two entry points into AS 100. To force AS 900 to prefer that path through RouterD to reach the 10.5.0.0/16 network, the set metric command can be used with a route-map:
RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map SETMED permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set metric 200
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 route-map SETMED out
RouterC will now have two entries for the 10.5.0.0/16 route:
RouterC# show ip bgp
Network Next Hop Metric LocPrf Weight Path
* 10.5.0.0 172.16.1.1 200 100 0 100 i
*> 10.5.0.0 172.17.1.1 0 100 0 100 i
Notice that the route from RouterB has a higher metric, and thus is less preferred. Note specifically the lack of a > on the route with a higher metric. The MED value is exchanged from one AS to another, but will never be advertised further than that. Thus, the MED value is passed from AS 100 to all BGP routers in AS 900, but the metric will be reset to 0 if the route is advertised beyond AS 900.
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
22
MED (continued)
A key aspect to consider when using the MED attribute is BGP’s method of route selection. Recall that if BGP contains multiple routes to the same destination, it compares the routes in pairs, starting with the newest entries and working towards the oldest entries.
This can lead to sub-optimal routing, depending on the order of routes in the BGP routing table. BGP employs two MED-related commands to alleviate potential sub-optimal routing selections. The bgp deterministic-med command forces the MED value to be compared, when multiple routes to the same network are received via multiple routers from the same AS, regardless of the order of routes in the BGP routing table.
RouterE(config)# router bgp 100
RouterE(config-router)# bgp deterministic-med
The bgp deterministic-med command is disabled by default. If used, the command should be enabled on all routers within the AS.
The bgp always-compare-med command forces the MED value to be compared, when multiple routes to the same network are received via multiple routers from different AS’s, regardless of the order of routes in the
BGP routing table.
RouterE(config)# router bgp 100
RouterE(config-router)# bgp always-compare-med
The bgp always-compare-med command is disabled by default. Thus, by default, the MED value is not compared between paths from different AS’s.
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094925.shtml;
http://www.cisco.com/warp/public/459/bgp-toc.html#metricattribute)
BGP v2.01 – Aaron Balchunas
* * *
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written
consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.
23
MED (continued)
The MED metric on routes sent to eBGP neighbors can be dynamically set to the actual metric of an IGP (such as OSPF). This is accomplished using the set metric-type internal command with a route-map:
RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map MED_INTERNAL permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set metric-type internal
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.17.1.2 route-map MED_INTERNAL out
If the 10.5.0.0/16 network originated in OSPF, the link-state cost metric for that route will be applied as the MED metric.
BGP v2.01 – Aaron Balchunas
* * *
24
Communities
BGP allows routes to be placed (or tagged) into certain Communities. BGP routers can make route policy decisions based on a route’s community membership.
BGP communities can be assigned using one of three 32-bit formats:
Decimal (1000000)
Hexadecimal (0x1A2B3C)
AA:NN (100:20)
The AA:NN format specifies a 16-bit AS number (the AA), and a 16-bit generic community identifier (NN).
By default, the decimal format for communities will be displayed when viewing a route. To force the router to display the AA:NN format:
RouterA(config)# ip bgp-community new-format
Additionally, there are four well-known communities that can be referenced
by name:
No-export – prevents the route from being advertised outside the local AS to eBGP peers.
No-advertise – prevents the route from being advertised to either internal or external peers.
Internet – allows the route to be advertised outside the local AS.
Local-AS – prevents the route from being advertised outside the local AS to either eBGP or confederate peers.
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#four;
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#communityattribute)
BGP v2.01 – Aaron Balchunas
* * *
25
Communities (continued)
To set the community for a specific route, using a route-map:
RouterB(config)# access-list 5 permit 10.5.0.0 0.0.255.255
RouterB(config)# route-map COMMUNITY permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set community no-export
RouterB(config)# route-map COMMUNITY permit 20
RouterB(config)# router bgp 100
RouterB(config-router)# neighbor 172.16.1.2 send-community
RouterB(config-router)# neighbor 172.16.1.2 route-map COMMUNITY out
The community attribute will not be advertised to a neighbor unless the send-community parameter is applied to the neighbor command, regardless if a community value is applied using a route-map.
The above configuration will place the 10.5.0.0/16 route into the no-export community once it is advertised into AS 900. RouterC will advertise this network to all iBGP peers, but the community attribute will prevent RouterC (and all iBGP peers) from advertising the route outside of AS 900.
By default, the set community route-map command will overwrite any existing community parameters for a route. To instead append additional community values, the additive parameter must be specified:
RouterB(config)# route-map COMMUNITY permit 10
RouterB(config-route-map)# match ip address 5
RouterB(config-route-map)# set community no-export additive
RouterB(config)# route-map COMMUNITY permit 20
BGP v2.01 – Aaron Balchunas
* * *
26
BGP Summarization
Routes that are redistributed into BGP are automatically summarized. To disable auto-summary:
Router(config)# router bgp 100
Router(config-router)# no auto-summary
To manually create a summary address for the following group of networks:
172.16.0.0/24
172.16.1.0/24
172.16.2.0/24
172.16.3.0/24
The aggregate-address command must be used:
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0
BGP’s default configuration is to send both the summary (or aggregated) address and the more specific individual routes. To only send the summary route:
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0 summaryonly
To suppress (or summarize) only specific routes, instead of all routes, a route-map must be used:
Router(config)# access-list 5 permit 172.16.0.0 0.0.0.255
Router(config)# access-list 5 permit 172.16.1.0 0.0.0.255
Router(config)# route-map SUPPRESS permit 10
Router(config-route-map)# match ip address 5
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0 summaryonly suppress-map SUPPRESS
The access-list details the routes that should be suppressed. To allow the summarized routes to retain their AS-Path information:
Router(config)# router bgp 100
Router(config-router)# aggregate-address 172.16.0.0 255.255.252.0 summaryonly suppress-map SUPPRESS as-set
BGP v2.01 – Aaron Balchunas
* * *
27
BGP Route Dampening
Route dampening “suppresses” routes that are flapping, minimizing unnecessary convergence and updates. If a route flaps (goes up and down), it is assigned a penalty (default is 1000). All routes start with a penalty of 0, and the local router maintains a history of routes that have flapped. Once the penalty reaches a specific threshold, the route is suppressed. When a route is suppressed, it is neither advertised nor used locally on the router. First, the routes to be “observed” must be identified using an access-list or prefix-list:
Router(config)# ip prefix-list MYLIST seq 10 permit 10.1.0.0/16
Router(config)# ip prefix-list MYLIST seq 20 permit 10.2.0.0/16
Next, dampening values must be configured using a route-map:
Router(config)# route-map MYMAP permit 10
Router(config-route-map)# match ip address prefix-list MYLIST
Router(config-route-map)# set dampening 15 750 2000 60
The above values for the set dampening command represent the defaults.
The 15 (measured in minutes) indicates the half-life timer. If a route is assigned a penalty, half of the penalty will decay after this timer expires.
The 750 (arbitrary penalty measurement) indicates the bottom threshold. Once a penalized route falls below this threshold, it will no longer be suppressed.
The 2000 (arbitrary penalty measurement) indicates the top threshold. If a route flaps to the point that its penalty exceeds this threshold, it is suppressed.
The 60 (measured in minutes) indicates the maximum amount of time a route can be suppressed.
Finally, route-dampening must be enabled under the BGP process:
Router(config)# router bgp 100
Router(config-router)# bgp dampening route-map MYMAP
(Reference: http://www.cisco.com/warp/public/459/bgp-rec-routing.html)
BGP v2.01 – Aaron Balchunas
* * *
28
BGP Next-Hop-Self
Consider the above diagram. If RouterC sends the 192.168.1.0/24 route to its eBGP peer RouterB, the Next Hop for that route will be through RouterC:
RouterB# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 172.16.1.2 0 100 0 900 i
A serious problem arises when RouterB sends this route to its iBGP peers (RouterA and RouterD). The Next Hop value is not changed:
RouterA# show ip bgp
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 172.16.1.2 0 100 0 900 i
Notice the lack of >, indicating this is no longer the best route to the destination. This is because RouterA has no route to the next hop address. There are two workarounds. Either the 172.16.0.0/16 network must be added to RouterA’s and RouterD’s routing tables, or the Next-Hop field must be adjusted to identify RouterB as the next hop.
The configuration is simple, and is completed on RouterB:
RouterB(config)# router bgp 200
RouterB(config-router)# neighbor 10.1.1.1 next-hop-self
RouterB(config-router)# neighbor 10.2.1.2 next-hop-self
RouterB now advertises itself as the next hop for all eBGP routes it learns:
RouterA# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.1.2 0 100 0 900 i
BGP v2.01 – Aaron Balchunas
* * *
29
BGP Backdoor
Recall that an external BGP route has an Administrative Distance (AD) of 20, which is less than the default AD of IGP’s, such as OSPF or EIGRP. Under certain circumstances, this may result in sub-optimal routing. If both an IGP route and eBGP route exist to the same network, and the IGP route should be preferred, there are two workarounds:
Globally change BGP’s default Administrative Distance values.
Use the BGP network backdoor command.
Cisco does not recommend changing BGP’s default AD values. If necessary, however, the distance bgp will adjust the AD for external, internal, and locally-originated BGP routes, respectively:
Router(config)# router bgp 100
Router(config-router)# distance bgp 150 210 210
The preferred workaround is to use the BGP network backdoor command, which adjusts the AD for a specific eBGP route (by default, from 20 to 200), resulting in the IGP route being preferred:
Router(config)# router bgp 100
Router(config-router)# network 10.5.0.0 mask 255.255.0.0 backdoor
(Reference: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#bgpbackdoor)
BGP v2.01 – Aaron Balchunas
* * *
30
Misc. BGP Commands
To restrict the number of routes a BGP router can receive from its neighbor:
Router(config)# router bgp 200
Router(config-router)# neighbor 10.1.1.1 maximum-prefix 10000
To immediately reset an eBGP session if a link connecting two peers goes
down, the bgp fast-external-fallover feature must be enabled. To enable this feature globally:
Router(config)# router bgp 200
Router(config-router)# bgp fast-external-fallover
To enable this feature on a per-interface basis:
Router(config)# int serial0/0
Router(config-if)# ip bgp fast-external-fallover permit
To reset the BGP session between all neighbors:
Router# clear ip bgp *
To force a resend of routing updates, without resetting any BGP sessions between neighbors:
Router# clear ip bgp * soft
To view a summary of all BGP connections, including the total number of BGP routes and a concise list of neighbors:
Router# show ip bgp summary
All original material copyright © 2007 by Aaron Balchunas (aaron@routeralley.com),
unless otherwise noted. All other material copyright © of their respective owners.
This material may be copied and used freely, but may not be altered or sold without the expressed written

consent of the owner of the above copyright. Updated material may be found at http://www.routeralley.com.

No comments:

Post a Comment