iBGP - Route Reflector

R5#sh run | sec bgp
router bgp 101
 bgp asnotation dot
 bgp log-neighbor-changes
 network 55.5.5.5 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 101
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 6.6.6.6 remote-as 1.301
 neighbor 6.6.6.6 disable-connected-check

R1#sh run | sec bgp
router bgp 101
 bgp asnotation dot
 bgp log-neighbor-changes
 network  11.11.1.1 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 101
 neighbor 2.2.2.2 shutdown
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 101
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 5.5.5.5 remote-as 101
 neighbor 5.5.5.5 update-source Loopback0

R2#sh run | sec bgp
router bgp 101
 bgp log-neighbor-changes
 net 22.22.2.2 mask 255.255.255.255
 neighbor 1.1.1.1 remote-as 101
 neighbor 1.1.1.1 shutdown
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 101
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 5.5.5.5 remote-as 101
 neighbor 5.5.5.5 update-source Loopback0
R2#


R3#sh run | sec bgp
router bgp 101
 bgp log-neighbor-changes
 network 33.3.3.3 mask 255.255.255.255
 neighbor 1.1.1.1 remote-as 101
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 2.2.2.2 remote-as 101
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 4.4.4.4 remote-as 201
 neighbor 4.4.4.4 ebgp-multihop 255
 neighbor 4.4.4.4 update-source Loopback0

Problem area-----

R1 Neighbor

3.3.3.3         4          101      13      14       89    0    0 00:05:13        2
5.5.5.5         4          101      21      18       89    0    0 00:10:55        2

R1#sh ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 *>  11.11.1.1/32     0.0.0.0                  0         32768 i
 *>i 33.3.3.3/32      3.3.3.3                  0    100      0 i      Route from R3 (iBGP)
 * i 44.4.4.4/32      4.4.4.4                  0    100      0 201 i
 *>i 55.5.5.5/32      5.5.5.5                  0    100      0 i    From R5 (iBGP)
 * i 66.6.6.6/32      6.6.6.6                  0    100      0 1.301 i
R1#

we can see there is no prefix  from R2 .

Same in R2

     Network          Next Hop            Metric LocPrf Weight Path
 *>  22.22.2.2/32     0.0.0.0                  0         32768 i
 *>i 33.3.3.3/32      3.3.3.3                  0    100      0 i
 * i 44.4.4.4/32      4.4.4.4                  0    100      0 201 i
 *>i 55.5.5.5/32      5.5.5.5                  0    100      0 i
 * i 66.6.6.6/32      6.6.6.6                  0    100      0 65837 i
R2#

No prefix from R1    but R2 has prefix from R6  because R5 will forward prefix to any iBGP peer if prefix is coming from EBGP.


in  R3


     Network          Next Hop            Metric LocPrf Weight Path
 *>i 11.11.1.1/32     1.1.1.1                  0    100      0 i
 *>i 22.22.2.2/32     2.2.2.2                  0    100      0 i
 *>  33.3.3.3/32      0.0.0.0                  0         32768 i
 *>  44.4.4.4/32      4.4.4.4                  0             0 201 i
R3#

No Prefix from R5 ,

in rule, iBGP never forward prefix coming from iBGP peer to any iBGP peer, but this will be forward to EBGP peer.

see in R6.

R6 and R5 EBGP.

R6#sh ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>  11.11.1.1/32     5.5.5.5                                0 101 i   
 *>  22.22.2.2/32     5.5.5.5                                0 101 i
 *>  55.5.5.5/32      5.5.5.5                  0             0 101 i
 *>  66.6.6.6/32      0.0.0.0                  0         32768 i

R6#

*>  11.11.1.1/32 (R1 Prefix)  is coming from R5 where R5-R1 has iBGP peering.
*>  22.22.2.2/32  (R2 Prefix)  is coming from R5 where R5-R2 has iBGP peering.

but no prefix from R3 & R4.

----Router reflector ---

To make prefix visible in all  router Route reflector is the sloution.
In Route reflector,A route reflector can have three types of peers: 
EBGP peers, 
client peers, 
nonclient peers

route reflector has the following three rules:
1. Routes learned from EBGP peers can be sent to other EBGP peers, clients, and nonclients.

2. Routes learned from client peers can be sent to EBGP peers, other client peers, and
non-clients.

3. Routes learned from non-client peers can be sent to EBGP peers, and client peers,
but not other non-clients..

Solution..

making R5 as Route reflector.

R1 & R2 are  RR client

router bgp 101

 neighbor 1.1.1.1 route-reflector-client

 neighbor 2.2.2.2  route-reflector-client

Now  in R1

R1#sh ip bgp 


     Network          Next Hop            Metric LocPrf Weight Path
 *>  11.11.1.1/32     0.0.0.0                  0         32768 i
 *>i 22.22.2.2/32     2.2.2.2                  0    100      0 i
 *>i 33.3.3.3/32      3.3.3.3                  0    100      0 i
 * i 44.4.4.4/32      4.4.4.4                  0    100      0 201 i
 *>i 55.5.5.5/32      5.5.5.5                  0    100      0 i
 * i 66.6.6.6/32      6.6.6.6                  0    100      0 1.301 i

All prefix

prefix 22.22.2.2/32 is from R2 .

in R5
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 11.11.1.1/32     1.1.1.1                  0    100      0 i
 *>i 22.22.2.2/32     2.2.2.2                  0    100      0 i
 *>  55.5.5.5/32      0.0.0.0                  0         32768 i
 *>  66.6.6.6/32      6.6.6.6                  0             0 1.301 i
R5#

R5#sh ip bgp 22.22.2.2
BGP routing table entry for 22.22.2.2/32, version 245
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     37         48         49
  Refresh Epoch 1
  Local, (Received from a RR-client)
    2.2.2.2 (metric 156160) from 3.3.3.3 (33.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 2.2.2.2, Cluster list: 33.3.3.3
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  Local, (Received from a RR-client)
    2.2.2.2 (metric 156160) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

We still don't have all prefix now to solve this problem , there can be different solultions  here we will make iBGP peering with R3and R3 as RR client.

R5#sh ip bgp sum
 neighbor 3.3.3.3 remote-as 101
 neighbor 3.3.3.3 update-source Loopback0

 neighbor 3.3.3.3 route-reflector-client

Now in R5 

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 11.11.1.1/32     1.1.1.1                  0    100      0 i
 * i 22.22.2.2/32     2.2.2.2                  0    100      0 i
 *>i                  2.2.2.2                  0    100      0 i
 *>i 33.3.3.3/32      3.3.3.3                  0    100      0 i
 * i 44.4.4.4/32      4.4.4.4                  0    100      0 201 i
 *>  55.5.5.5/32      0.0.0.0                  0         32768 i
 *>  66.6.6.6/32      6.6.6.6                  0             0 1.301 i
R5#

we have all prefix

in R3

   Network          Next Hop            Metric LocPrf Weight Path
 * i 11.11.1.1/32     1.1.1.1                  0    100      0 i
 *>i                  1.1.1.1                  0    100      0 i
 * i 22.22.2.2/32     2.2.2.2                  0    100      0 i
 *>i                  2.2.2.2                  0    100      0 i
 *>  33.3.3.3/32      0.0.0.0                  0         32768 i
 *>  44.4.4.4/32      4.4.4.4                  0             0 201 i
 *>i 55.5.5.5/32      5.5.5.5                  0    100      0 i
 * i 66.6.6.6/32      6.6.6.6                  0    100      0 65837 i
R3#

in R2

     Network          Next Hop            Metric LocPrf Weight Path
 * i 11.11.1.1/32     1.1.1.1                  0    100      0 i
 *>i                  1.1.1.1                  0    100      0 i
 *>  22.22.2.2/32     0.0.0.0                  0         32768 i
 * i 33.3.3.3/32      3.3.3.3                  0    100      0 i
 *>i                  3.3.3.3                  0    100      0 i
 * i 44.4.4.4/32      4.4.4.4                  0    100      0 201 i
 * i 55.5.5.5/32      5.5.5.5                  0    100      0 i
 *>i                  5.5.5.5                  0    100      0 i
 * i 66.6.6.6/32      6.6.6.6                  0    100      0 65837 i
R2#

in R6

R6#

     Network          Next Hop            Metric LocPrf Weight Path

 *>  11.11.1.1/32     5.5.5.5                                0 101 i

 *>  22.22.2.2/32     5.5.5.5                                0 101 i

 *>  33.3.3.3/32      5.5.5.5                                0 101 i

 *>  55.5.5.5/32      5.5.5.5                  0             0 101 i

 *>  66.6.6.6/32      0.0.0.0                  0         32768 i

R6#

in R6 we still don't have route from R4

R4#

     Network          Next Hop            Metric LocPrf Weight Path

 *>  11.11.1.1/32     3.3.3.3                                0 101 i

 *>  22.22.2.2/32     3.3.3.3                                0 101 i

 *>  33.3.3.3/32      3.3.3.3                  0             0 101 i

 *>  44.4.4.4/32      0.0.0.0                  0         32768 i

 *>  55.5.5.5/32      3.3.3.3                                0 101 i

R4#

in R4 we still don't have route from R6

Note ---Route reflector does not change path attribute like Next Hop 

to solve above problem see    BGP -Next hop Self

Establishing BGP Peerings

BGP- Authentication

R6#sh ip bgp nei 1.1.1.1 | in md5
Option Flags: nagle, path mtu capable, md5, Retrans timeout

R1#sh ip bgp nei 6.6.6.6 | in md5
Option Flags: nagle, path mtu capable, md5

BGP Basics- Path Attribute

Path Attributes

A path attribute is a characteristic of an advertised BGP route. Path attributes are what allow BGP to set and communicate routing policy.

Each path attribute falls into one of four categories: 

•       Well-known mandatory
•       Well-known discretionary
•      Optional  transitive
•    Optional non-transitive

The ORIGIN Attribute- Well-known mandatory,

It specifies the origin of the routing update,

    IGP— The Network  was learned from a protocol  internal to the originating AS. An IGP origin                      gets the highest preference of the ORIGIN values.” i”

   EGP— The NLRI was learned from the Exterior Gateway Protocol. EGP is preferred second to

   IGP. “e”

    Incomplete— The NLRI was learned by some other means like disribution. Incomplete is the                                      lowest-preferred ORIGIN value. Incomplete does not imply that the route is in any                              way faulty, only that the information for determining the origin of the route is                                      incomplete “ ?”

 AS_PATH - Well-known mandatory

AS_PATH is a well-known mandatory attribute that uses a sequence of AS numbers to describe the

inter-AS path, or route, to the destination specified by the NLRI,

AS_PATH describes all the  autonomous systems it has passed through, beginning with the most recent AS and ending with the originating AS

NEXT_HOP - Well-known mandatory

It describes the IP address of the next-hop router on the path to the advertised destination,

There are three condition for next_hop .

1.   If the advertising router and receiving router are in different autonomous systems (external

peers), the NEXT_HOP is the IP address of the advertising router's interface.

2. If the advertising router and the receiving router are in the same AS (internal peers), and the

NLRI of the update refers to a destination within the same AS, the NEXT_HOP is the IP

address of the neighbor that advertised the route.

3. If the advertising router and the receiving router are internal peers and the NLRI of the

update refers to a destination in a different AS, the NEXT_HOP is the IP address of the

external peer from which the route was learned

NEXT_HOP IP must be reachable to install route into routing table

LOCAL_PREF - well-known discretionary

LOCAL_PREF is short for local preference, is used only in updates between internal BGP peers; it is not passed to other autonomous systems,

 The attribute is used to communicate a BGP router's degree of preference for an advertised route.The route with the highest LOCAL_PREF is selected.

MULTI_EXIT_DISC -optional nontransitive

To influence incoming traffic, the MULTI_EXIT_DISC attribute, known as the MED for short, is used.

 This attribute is carried in EBGP updates and allows an AS to inform another AS of its preferred ingress points. The lowest MED value is preferred.

MED is considered a metric, and with a metric the lowest value—the lowest distance—is preferred

MEDs also are not compared if two routes to the same destination are received from two different 

autonomous systems

ATOMIC_AGGREGATE and AGGREGATOR Attributes

when summarization (route aggregation) is performed, some  route information is lost and routing can become less precise. When aggregation is performed in a BGP-speaking router, path detail is lost.

ATOMIC_AGGREGATE is a well-known discretionary attribute that is used to alert downstream routersthat a loss of path information has occurred.

In  summarization, BGP speaker must attach  the ATOMIC_AGGREGATE  attribute to the aggregate route, and receiver when advertising the route to other peers, the ATOMIC_AGGREGATE attribute must remain attached.

When the ATOMIC_AGGREGATE attribute is set, the BGP speaker has the option of also attaching theAGGREGATOR attribute, This is a optional transitive attribute provides information about where theaggregation was performed by including the AS number and the IP address of the router thatoriginated the aggregate route.

ORIGINATOR_ID and CLUSTER_LIST-- optional, nontransitive

ORIGINATOR_ID and CLUSTER_LIST are optional, nontransitive attributes used by route reflectors,

ORIGINATOR_ID is a 32-bit value created by a route reflector. The value is the router ID of the originator of the route in the local AS, If the originator sees its RID in the ORIGINATOR_ID of a received route, it knows that a loop has occurred, and the route is ignored.

CLUSTER_LIST is a sequence of route reflection cluster IDs through which the route has passed, If a route reflector sees its local cluster ID in the CLUSTER_LIST of a received route, it knows that a loop has occurred, and the route is ignored.

COMMUNITY Attribute,

COMMUNITY is an optional transitive attribute that is designed to simplify policy enforcement.

The COMMUNITY attribute is a set of four octet values.

RFC 1997 specifies that the first two octets are the autonomous system and the last two octets are an administratively defined identifier, giving a format of AA:NN.

The default Cisco format, on the other hand, is NN:AA. It can be changed  to the RFC 1997 format with the command ip bgp-community new-format.

We known communities are,

INTERNET

NO_EXPORT

NO_ADVERTISE

LOCAL_AS 

NO_EXPORT_SUBCONFED. 

Administrative Weight  -Cisco Specific

Administrative weight is a Cisco-specific BGP parameter that applies only to routes within an

individual router. It is not communicated to other routers. The weight is a number between 0 and

65,535 that can be assigned to a route; the higher the weight, the more preferable the route

All routes learned from a peer have a weight of 0, and all routes generated by the local router have a weight of 32,768.

a    

BGP Basic- State

Idle State

BGP always begins in the Idle state, in which it refuses all incoming connections. When a Start event

, the BGP process initializes all BGP resources, starts the ConnectRetry timer, initializes

a TCP connection to the neighbor, listens for a TCP initialization from the neighbor, and changes its

state to Connect.

Connect State

In this state, the BGP process is waiting for the TCP connection to be completed. If the TCP

connection is successful, the BGP process clears the ConnectRetry timer, completes initialization,

sends an Open message to the neighbor, and transitions to the OpenSent state.,

If the ConnectRetry timer expires while in the Connect state, the timer is reset, another attempt is

made to establish a TCP connection with the neighbor, and the process stays in the Connect state.

Active State

In this state, the BGP process is trying to initiate a TCP connection with the neighbor. If the TCP

connection is successful, the BGP process clears the ConnectRetry timer, completes initialization,

sends an Open message to the neighbor, and transitions to OpenSent. The Hold timer is set to 4

minutes.

If the ConnectRetry timer expires while BGP is in the Active state, the process transitions back to the

Connect state and resets the ConnectRetry timer.

OpenSent State

In this state, an Open message has been sent, and BGP is waiting to hear an Open from its neighbor.

When an Open message is received, all its fields are checked. If errors exist, a Notification message is sent and the state transitions to Idle.

If no errors exist in the received Open message, a Keepalive message is sent and the Keepalive timer

is set.

OpenConfirm State

In this state, the BGP process waits for a Keepalive or Notification message. If a Keepalive is

received, the state transitions to Established. If a Notification is received, or a TCP disconnect is

received, the state transitions to Idle.

Established State

In this state, the BGP peer connection is fully established and the peers can exchange Update,

Keepalive, and Notification messages

BGP - Basics Message Type

BGP Message

BGP messages are unicast to the one neighbor over the TCP connection.

BGP uses four message types:

·         Open

·         Keepalive

·         Update

·         Notification

Open Message

After the TCP session is established, both neighbors send Open messages,

 1. BGP version number— This specifies the version (2, 3, or 4) of BGP that the originator is running.it defaults to BGP-4. If a neighbor is running an earlier version of BGP, it rejects the Open message specifying version 4; the BGP-4 router then changes to BGP-3 and sends another Open message specifying this version. This negotiation continues until both neighbors agree on the same version.

2. Autonomous system number— This is the AS number of the originating router. It determines whether the BGP session is EBGP (if the AS numbers of the neighbors differ) or IBGP (if the AS numbers are the same).

3.    Hold time— This is the maximum number of seconds that can elapse before the router must receive either a Keepalive or an Update message. The hold time must be either 0 seconds (in which case, Keepalives must not be sent) or at least 3 seconds; the default Cisco hold time is 180 seconds. If the neighbors' hold times differ, the smaller of the two times becomes the accepted hold time.

4.  BGP identifier— This is an IP address that identifies the neighbor.

 The numerically highest loopback address is used.

.

5.   Optional parameters—optional capabilities, as authentication, multiprotocol support, and route refresh.

Keepalive Message

If a router accepts the parameters specified in its neighbor's Open message, it responds with a

Keepalive. Subsequent Keepalives are sent every 60 seconds by Cisco default, or a period equal to

one-third the agreed-upon hold time.

The Keepalive message consists of only the 19-octet BGP message header, with no additional data.

Update Message

The Update message advertises feasible routes, withdrawn routes, or both.

Network Layer Reachability Information (NLRI)— This is one or more (Length, Prefix)

tuples that advertise IP address prefixes and their lengths

Path Attributes. The attributes provide the information that allows BGP to choose a shortest path, detect routing loops, and determine routing policy

Withdrawn Routes— These are (Length, Prefix) tuples describing destinations that have

become unreachable and are being withdrawn from service.

**each update message describes only a single BGP route (because the path attributes describe only a single path, but that path might lead to multiple destinations

The Attribute Type Part of the Path Attributes Field

Notification Message 

The Notification message is sent whenever an error is detected and always causes the BGP

connection to close

BGP Basics- Points to remember

BGP Basic Points

• BGP is called a path vector routing protocol.
• List of AS no associated with a BGP route is called AS_PATH.
• AS_Path provide shortest path and Loop Prevention
• i in the end of AS_PATH indicate that the path is terminating at an IGP.
• Load balancing works only in EBGP( i.e Maximum Path), IBGP can use only one path.
• BGP does not use periodic routing updates. Peers  use keepalive to ensure that the connection is live.
• BGP Use TCP threeway handshake and open a TCP connection to port 179 before establishing any BGP peer connection.
•   TCP does fragmentation, retransmission, acknowledgment, and sequencing functions necessary for a reliable connection for BGP .

• Next_hop must be reachable in order to install route into IGP routing table.
• During Summarization, Path detail (AS_PATH)  is lost.