BGP Route Reflecting

 

image

 

Before we start the lab we need to know why using route reflector, so for our topology

R1 R2 R3 R4 are in AS 100

iBGP peering

R1-R2

R1-R3

R1-R4

EBGP

R1-R5

R1-R6

each router advertises the following subnets in the  BGP

R1 1.1.0.0/24  10.1.15.0/24 10.1.16.0/24

R2  2.2.0.0/24

R3 3.3.0.0/24

R4 4.4.0.0/24

R5 5.5.0.0/24

R6 6.6.0.0/24

Now lets check the BGP on various routers

on R1

image

As we can see R1 BGP table looks good, we have all the routes from all neighbors

image

R5 also looks good, all routes are received into BGP

now let’s check R2

image

so on R2 we haven’t received the 2 loopbacks of R3 and R4

what about R3

image

Also on R3 the loopbacks of R2 and R4 are missing

Tis normal behavior for BGP, routes received from iBGP peers are only advertised to EBGP peers but not to other iBGP  to prevent loops

so in order for us to overcome this we basically have 3 solutions:

1- configure full mesh between all iBGP peers

2- use route reflectors

3- use confederation

The full mesh topology maybe feasible for small numbers of iBGP peers but using (N x (N – 1))/2 rule this means that if we have 6 routers we need 15 iBGP sessions which is not very scalable

in our case we will use route reflectors

so we will configure R2 and R3 as Route-Reflector clients and we will not configure R4 as route reflector client for now 

The way we do this is under R1 BGP configurations

router  bgp 100

neighbor 10.1.12.2 route-reflector-client

neighbor 10.1.13.3 route-reflector-client

 

Now let’s see the BGP table on R2

image

so we can see that now we are receiving the routes from R3 and R4

one thing to notice here that route-reflectors don’t change th next hop attribute as we can see

Also if we check R4 BGP table

image

we see that R2 and R3 are now received in R4 although R4 is not configured as route-reflector client

These are the 3 rules for route-reflecting

1-Routes learned from EBGP peers will be advertised to other EBGP peers, RR clients and non-clients

2- Routes learned from RR clients will be advertised to EBGP  peers, other RR clients and non clients

3- Routes learned from non clients will be advertised to EBGP peers, RR clients but not to other non clients

That’s why R4 loopback was advertised to R1 and R2 and R1 and R2 loopback were advertised no R4

The term luster is basically RR and it’s clients

so when we check the BGP route 4.4.0.0 we will see the cluster list :10.1.16.1

this is R1 router-id

R3(config-router)#do sh ip bgp 4.4.0.0
BGP routing table entry for 4.4.0.0/24, version 16
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  Local
    10.1.14.4 (metric 30720) from 10.1.13.1 (10.1.16.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.1.34.4, Cluster list: 10.1.16.1

R1(config-router)#do sh ip bgp | in ID
BGP table version is 13, local router ID is 10.1.16.1

Cluster lists are used to prevent loops when we have multiple clusters in the BGP domains as advertisements will be discarded if they have our own cluster-list

Comments

Post a Comment

Popular posts from this blog

BPDU Filter vs BPDU Guard

        Today we will try to explore the difference between these 2 options, BPDU guard and BPDU filter We know that BPDU are used to communicate between switches in L2 networks  to ensure loop free topology. BPDU Guard is used to protect our access (or trunks incase of servers) ports from receiving undesired BPDU packets, this feature is helpful in enforcing your network boundary in access layer BPDU Guard can be enabled on global configuration as well as under the interface configuration BPDU Filter on the other hand is used to filter BPDU packets outbound when configured  in global configuration (after sending 11 BPDU out ) and will filter BPDU inbound/outbound when configured under the interface level To better understand these two features, let’s use this simple topology R1 is connected to SW1 through F0/0 to have R1 send and receive BPDU we will simple configure bridging group 1 on the router and we will join the bridge group when desired to test our configuration BPDU
Read more

BGP Weight Attribute

Image
Before we start the lab let's see the BGP path selection process If the path specifies a next hop that is inaccessible, drop the update. •Prefer the path with the highest weight. •If the weights are the same, prefer the path with the largest local preference. •If the local preferences are the same, prefer the path that was originated by BGP running on this router. •If no route was originated, prefer the route that has the shortest AS_path. •If all paths have the same AS_path length, prefer the path with the lowest origin code (where IGP is lower than EGP, and EGP is lower than incomplete). •If the origin codes are the same, prefer the path with the lowest MED attribute. •If the paths have the same MED, prefer the external path over the internal path. •If the paths are still the same, prefer the path through the closest IGP neighbor. •Prefer the path with the lowest IP address, as specified by the BGP router ID. I read this on CCIE Pursuit blog We Love Oranges As O
Read more

OSPF–Point To Multipoint Non-Broadcast

Image
Using same setup that we have been using in the last 3 posts, we will change the network type to point-to-multipoint Non-Broadcast we will also add a Ethernet link between R2 and R3 and enable OSPF on it Our final configuration should be something like this R1 interface Serial0/0   no ip address   encapsulation frame-relay   no frame-relay inverse-arp ! interface Serial0/0.123 multipoint   ip address 10.1.123.1 255.255.255.0   ip ospf network point-to-multipoint non-broadcast   ip ospf 1 area 0   frame-relay map ip 10.1.123.2 102   frame-relay map ip 10.1.123.3 103 !          router ospf 1   router-id 1.1.1.1   log-adjacency-changes   neighbor 10.1.123.2   neighbor 10.1.123.3 R2 interface Serial0/0   no ip address   encapsulation frame-relay   no frame-relay inverse-arp ! interface Serial0/0.123 multipoint   ip address 10.1.123.2 255.255.255.0   ip ospf network point-to-multipoint non-broadcast   ip ospf 1 area 0   frame-relay map ip 10.1.123.1 201 R3 interface
Read more