----------------------
A IBGP route reflector will eliminate the need for full mesh in BGP (AS IBGP will not
send on routes learnt
as loop prevention mechanism full mesh is requirement)
Like OSPF DR & ISIS DIS mininimize prefix replication
- send one update to the RR
- RR sends the update to its "clients"
Loop prevention through Cluster-ID
- RR discards routes recieved with its own cluser-id
- Does not modify other attributes such as next-hop
Route-Reflector Peerings
-----------------------
Route Reflector can have 3 types of peers
-EBGP Peers
- neighbors in different AS
-Client Peers
-IBGP peers with route-reflector-client
-Non-Client
- IBGP peers with no route-reflector-client
The route reflector will treat the update differently depending on where the update
is coming from + where it is going to
EBGP Learned routes
- can be advertised to EBGP peers,clients & non clients
- client learned routes
- can be advertised to EBGP peers,Clients & Non clients
-non client learned routes
- can be advertised to EBGP Peers & Clients but not other non clients
Originater id prevent potential routes alone with cluster id for multiple route
reflectors
Large Scale Route Reflection
-----------------------------
- large scale BGP desings can not be serviced by only a single rr
- a single rr is a single point of failure
-rr clusters allow redudancy and hierachy
- clusters is defined by the clients a RR serves
- RRS in the same cluster use the same Cluster-id
-inter-cluster peerings between RR can be client or non-client Peerings
- depends on redudancy design
When configuring we tend to configure in peers groups here is the config on route
reflector
router bgp 10
neighbor CLIENTS peer-group
neighbor CLIENTS remote-as 100
neighbor CLIENTS route-reflector-client
neighbor CLIENTS update-source lo0
neighbor 10.28.3.3 peer-group CLIENTS
neighbor 10.28.1.1 peer-group CLIENTS
If you make other rr not in your cluster clients - it will cost you more bandwidth as
you will forward on updates
recieved but it will give you more redudancy
If you do not make them clients- it will not cost bandwidth buy you will have less
redudancy
Imagine a rr is connected to Router4 which is one of the entries to AS
rr will recieve the route via IBGP and the R4 will be nonclient so as of the rules of
RR it will only forward the update to EBGP PEERs & Clients not non clients
You will never see a loop no matter which way you config this client/non client as
BGP will use the cluster list and originator id to prevent against this.
RR in the same cluster should have the same cluster id.
Rules of ROute Reflectors
- Route Reflector clients must not peer with RR outside of their cluster
- RR clients must not be more than one hop away from RR
- RR still need to be full meshed with non RR Clients
- Route reflection is only cofigured on the server
LAB
---
I have configured the tried and tested ine topology for this we will have 4 AS as 54
which is BB1 AS 254 which is BB2 and AS 200 which is R2 all other router are in AS
100
R1 R3 R5 will be route-reflectors
---
bb2(config)#router bgp 54
bb2(config-router)#neighbor 10.229.254.6 remote-as 100
bb2(config-router)#network 122.122.122.122 mask 255.255.255.255
bb2(config-router)#network 222.222.222.222 mask 255.255.255.255
bb2(config-router)#network 22.22.22.22 mask 255.255.255.255
we will inject a few routes into BGP
R6
---
Ok so on r6 i configure peering with the remote AS 54 and IBGP relationship with
r1 and r4 i done this via a peer-group
r6(config)#router bgp 100
r6(config-router)#neighbor 10.229.254.1 remote-as 54
r6(config-router)#neighbor IBGP PEERS ?
% Unrecognized command
r6(config-router)#neighbor IBGP-NEIGHBORS peer-group
r6(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
r6(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
r6(config-router)#neighbor IBGP-NEIGHBORS next-hop-self
r6(config-router)#neighbor 1.1.1.1 peer-group IBGP-NEIGHBORS
r6(config-router)#neighbor 3.3.3.3 peer-group IBGP-NEIGHBORS
r6(config-router)#
BB3
----
bb3(config)#router bgp 254
bb3(config-router)#neighbor 172.25.13.4 remote-as 100
bb3(config-router)#network 33.33.33.33 mask 255.255.255.255
bb3(config-router)#network 133.133.133.133 mask 255.255.255.255
bb3(config-router)#
r4
---
r4(config)#router bgp 100
r4(config-router)#neighbor 172.25.13.3 remote-as 254
r4(config-router)#neighbor IBGP-NEIGHBORS peer-group
r4(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
r4(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
r4(config-router)#neighbor IBGP-NEIGHBORS next-hop-self
r4(config-router)#neighbor 5.5.5.5 peer-group IBGP-NEIGHBORS
r4(config-router)#
r4#
*Jan 20 19:20:01.071: %BGP-5-ADJCHANGE: neighbor 6.6.6.6 Up
we will configure r1 next it just needs ibgp relationships r4,r6,r3,r5
r1
---
r1(config)#router bgp 100
r1(config-router)#neighbor IBGP-NEIGHBORS peer-group
r1(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
r1(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
r1(config-router)#
r1(config-router)#neighbor 6.6.6.6 peer-group IBGP-NEIGHBORS
r1(config-router)#neighbor 5.5.5.5 peer-group IBGP-NEIGHBORS
r1(config-router)#neighbor 3.3.3.3 peer-group IBGP-NEIGHBORS
r1(config-router)#neighbor 2.1.1.1 peer-group IBGP-NEIGHBORS
r1(config-router)#neighbor 2.3.3.3 peer-group IBGP-NEIGHBORS
r1(config-router)#
*Mar 1 00:21:23.651: %BGP-5-ADJCHANGE: neighbor 6.6.6.6 Up
Lets configure r3 now
r3(config-router)#network 155.0.37.0 0.0.0.255
r3(config-router)#exit
r3(config)#router bgp 100
r3(config-router)#neighbor IBGP-NEIGHBORS peer-group
r3(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
r3(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
r3(config-router)#
r3(config-router)#neighbor 1.1.1.1 peer-group IBGP-NEIGHBORS
r3(config-router)#neighbor 2.1.1.1 peer-group IBGP-NEIGHBORS
r3(config-router)#neighbor 5.5.5.5 peer-group IBGP-NEIGHBORS
r3(config-router)#neighbor 2.3.3.3 peer-group IBGP-NEIGHBORS
r3(config-router)#neighbor 6.6.6.6 peer-group IBGP-NEIGHBORS
r3(config-router)#neighbor 155.0.23.2 remote-as 200
s1
---
s1(config)#router bgp 100
s1(config-router)#neighbor IBGP-NEIGHBORS peer-group
s1(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
s1(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
s1(config-router)#
s1(config-router)#neighbor 1.1.1.1 peer-group IBGP-NEIGHBORS
s1(config-router)#neighbor 3.3.3.3 peer-group IBGP-NEIGHBORS
s1(config-router)#neighbor 2.3.3.3 peer-group IBGP-NEIGHBORS
s1(config-router)#
02:05:29: %BGP-5-ADJCHANGE: neighbor 3.3.3.3 Up
s1(config-router)#
we have an issue we are not getting any bgp routes
as the loop prevention in bgp not to advertise on a IBGP route to other ibgp peers
s1#sh ip route bgp
s1#
s3(config)#router bgp 100
s3(config-router)#neighbor IBGP-NEIGHBORS peer-group
s3(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
s3(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
s3(config-router)#
s3(config-router)#neighbor 2.1.1.1 peer-group IBGP-NEIGHBORS
s3(config-router)#neighbor 3.3.3.3 peer-group IBGP-NEIGHBORS
s3(config-router)#neighbor 1.1.1.1 peer-group IBGP-NEIGHBORS
s3(config-router)#exit
s3#sh ip bgp
s3#
we are going need to get this section of the network getting bgp routes
we will bring r2 into equation another external AS
r2
---
r2(config-router)#router bgp 200
r2(config-router)#neighbor 155.0.23.3 remote-as 100
r2(config-router)#network 12.12.12.12 mask 255.255.255.255
r2(config-router)#
Ok we will move on to configuring the rest of the topology
S4
---
s4(config)#router bgp 100
s4(config-router)#neighbor IBGP-NEIGHBORS peer-group
s4(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
s4(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
s4(config-router)#
s4(config-router)#neighbor 22.2.2.2 peer-group IBGP-NEIGHBORS
s4(config-router)#neighbor 5.5.5.5 peer-group IBGP-NEIGHBORS
s2
---
s2(config)#router bgp 100
s2(config-router)#neighbor IBGP-NEIGHBORS peer-group
s2(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
s2(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
s2(config-router)#
s2(config-router)#neighbor 4.4.4.4 peer-group IBGP-NEIGHBORS
s2(config-router)#neighbor 5.5.5.5 peer-group IBGP-NEIGHBORS
s2(config-router)#no neighbor 4.4.4.4 peer-group IBGP-NEIGHBORS
s2(config-router)#neighbor 2.4.4.4 peer-group IBGP-NEIGHBORS
s2(config-router)#
r5
--
r5(config)#router bgp 100
r5(config-router)#neighbor IBGP-NEIGHBORS peer-group
r5(config-router)#neighbor IBGP-NEIGHBORS update-source lo0
r5(config-router)#neighbor IBGP-NEIGHBORS remote-as 100
r5(config-router)#
r5(config-router)#neighbor 4.4.4.4 peer-group IBGP-NEIGHBORS
r5(config-router)#neighbor 22.2.2.2 peer-group IBGP-NEIGHBORS
r5(config-router)#no neighbor 2.4.4.4 peer-group IBGP-NEIGHBORS
r5(config-router)#neighbor 3.3.3.3 peer-group IBGP-NEIGHBORS
r5(config-router)#neighbor 1.1.1.1 peer-group IBGP-NEIGHBORS
r5(config-router)#
OK so in this topology we have done IBGP sessions are not fully meshed not every
router has an IBGP connected to every other router so we will see on some router they
will have routes from some AS and not others etc
Lets look at r3
r3#sh ip bgp summary
BGP router identifier 3.3.3.3, local AS number 100
BGP table version is 5, main routing table version 5
4 network entries using 468 bytes of memory
4 path entries using 208 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1096 total bytes of memory
BGP activity 4/0 prefixes, 4/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 7 8 5 0 0 00:03:55 0
2.1.1.1 4 100 8 10 5 0 0 00:06:56 0
2.3.3.3 4 100 8 10 5 0 0 00:06:57 0
5.5.5.5 4 100 11 11 5 0 0 00:07:10 0
6.6.6.6 4 100 12 12 5 0 0 00:07:14 3
155.0.23.2 4 200 11 11 5 0 0 00:07:07 1
r3#
So r3 has a neighbor relationship with r6 were it should be recieving routes from AS
254 and has direct relationship with r2 (155.0.0.23.2) where it should recieve routes
from AS 200) we have no relationship with r4
r3#sh ip bgp
BGP table version is 5, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 12.12.12.12/32 155.0.23.2 0 0 200 i
*>i22.22.22.22/32 6.6.6.6 0 100 0 54 i
*>i122.122.122.122/32
6.6.6.6 0 100 0 54 i
*>i222.222.222.222/32
6.6.6.6 0 100 0 54 i
r3#
AS such we are only recieving routes from AS 200 and AS54 we are not recieving any
routes from AS200
On s3
------
s3#sh ip bgp summary
BGP router identifier 2.3.3.3, local AS number 100
BGP table version is 40, main routing table version 40
1 network entries using 117 bytes of memory
1 path entries using 52 bytes of memory
2/1 BGP path/bestpath attribute entries using 232 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 425 total bytes of memory
BGP activity 8/7 prefixes, 8/7 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 45 51 40 0 0 00:19:49 0
2.1.1.1 4 100 60 60 40 0 0 00:58:26 0
3.3.3.3 4 100 53 51 40 0 0 00:22:30 1
s3#
we have neighbor relationship with r1 and s1 and r3
s3#sh ip bgp
BGP table version is 40, local router ID is 2.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i12.12.12.12/32 155.0.23.2 0 100 0 200 i
s3#
we are only recieving for AS 200
If we look at the toplogy r1 is recieiving an ibgp route from r6 so it is not going
to pass this on via IBGP to another ibgp route BGP split horizon rule
where as r3 is recieving a ebgp route from r2 this will be passed on As it is an ebgp
been advertised in ibgp.
If we look at r5
r5#sh ip bgp summary
BGP router identifier 155.0.58.5, local AS number 100
BGP table version is 26, main routing table version 26
3 network entries using 387 bytes of memory
3 path entries using 156 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 963 total bytes of memory
BGP activity 10/7 prefixes, 10/7 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 100 40 48 26 0 0 00:23:01 0
3.3.3.3 4 100 48 53 26 0 0 00:26:00 1
4.4.4.4 4 100 52 51 26 0 0 00:47:43 2
22.2.2.2 4 100 49 51 26 0 0 00:48:01 0
r5#
it has neighbor relationships with r1,r3,r4,sw2
r5#sh ip bgp
BGP table version is 26, local router ID is 155.0.58.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r>i12.12.12.12/32 155.0.23.2 0 100 0 200 i
*>i33.33.33.33/32 4.4.4.4 0 100 0 254 i
*>i133.133.133.133/32
4.4.4.4 0 100 0 254 i
it is getting routes from r4 which is advertising the AS 254 routes to r5 Also it is
getting routes from AS 200 via r3
but it knows nothing of AS 54
How we resolve this issue is dependent on multiple factors.
FOr example for best path selection all routers should ibgp to every other router so
in this scenerio every router in the topology would be recieving AS 54 routes AS 254
routes AS 200 routes. IN this lab it would be fine as the routes been advertised is
couple from each AS
But if it was the case which is very likely that each of these AS is internet service
provider which could pontential a 100k + routes each. This means that every router in
our topology must be equiped to deal with these amount routes.( increase CPU
increased control plane traffic ) THis most likely not going be the case
We could say lets designate a route reflector the route reflectors peers with the
EBGP facing neighbors r3,r6,r4 and then the route reflector IBGP peers with all other
routers. This would work aswell. We would probably want to designate one for backup
aswell.
For this lab i will do it that the ibgp sessions are setup and we have been told we
can not have any further ibgp sessions. So this will force me to have multiple route
reflectors servicing different parts of the network. WHich is most likely what you
want in large scale implementation.
I will break down as follows r1 + r3 will service r6,s1,s3
R5 will service r4,s4,s2
The first router i am going look at is r1
r1#sh ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 8, main routing table version 8
6 network entries using 774 bytes of memory
6 path entries using 312 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 bytes of memory
3 BGP AS-PATH entries using 72 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1654 total bytes of memory
BGP activity 6/0 prefixes, 6/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.1.1.1 4 100 7 8 8 0 0 00:05:41 0
2.3.3.3 4 100 7 8 8 0 0 00:05:22 0
3.3.3.3 4 100 10 9 8 0 0 00:05:30 1
5.5.5.5 4 100 9 8 8 0 0 00:05:23 0
6.6.6.6 4 100 10 9 8 0 0 00:05:40 3
r1#
it has a IBGP relationship with r6 where it will be recieving routes it can pass them
to s1,sw3 who under normal ibgp rules would not get them it also has a IBGP
relationship with R3 it can pass routes recieved to r6 which would not normal get
them
r1
---
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor IBGP-NEIGHBORS peer-group
neighbor IBGP-NEIGHBORS remote-as 100
neighbor IBGP-NEIGHBORS update-source Loopback0
neighbor 2.1.1.1 peer-group IBGP-NEIGHBORS
neighbor 2.3.3.3 peer-group IBGP-NEIGHBORS
neighbor 3.3.3.3 peer-group IBGP-NEIGHBORS
neighbor 5.5.5.5 peer-group IBGP-NEIGHBORS
neighbor 6.6.6.6 peer-group IBGP-NEIGHBORS
Xi can apply the route-reflector config to the peer group rather than single to
s3,s1,r6 neighbors
r1(config)#router bgp 100
r1(config-router)#neighbor IBGP-NEIGHBORS route-reflector-client
r1(config-router)#
*Mar 1 00:31:45.211: %BGP-5-ADJCHANGE: neighbor 2.1.1.1 Down RR client config change
*Mar 1 00:31:45.211: %BGP-5-ADJCHANGE: neighbor 2.3.3.3 Down RR client config change
*Mar 1 00:31:45.211: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Down RR client config change
*Mar 1 00:31:45.215: %BGP-5-ADJCHANGE: neighbor 6.6.6.6 Down RR client config change
*Mar 1 00:31:47.239: %BGP-5-ADJCHANGE: neighbor 2.1.1.1 Up
*Mar 1 00:31:47.239: %BGP-5-ADJCHANGE: neighbor 2.3.3.3 Up
*Mar 1 00:31:47.243: %BGP-5-ADJCHANGE: neighbor 6.6.6.6 Up
*Mar 1 00:31:47.331: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Up
the config is above is only done on the server it resetted all the neighbor
relationships and they came back up
lets take a look at the results
on s3
s3#sh ip bgp
BGP table version is 43, local router ID is 2.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* i12.12.12.12/32 155.0.23.2 0 100 0 200 i
*>i 155.0.23.2 0 100 0 200 i
*>i22.22.22.22/32 6.6.6.6 0 100 0 54 i
*>i122.122.122.122/32
6.6.6.6 0 100 0 54 i
*>i222.222.222.222/32
6.6.6.6 0 100 0 54 i
we are seeing now both AS 54 and 200
Now we want to have a look at
same on s1
NOw the issue is if r1 goes down we s1 and s3 will lose connectivity so we have
single point of failure in the route reflector design so we will define r3 as backup
to the route reflector
r3
---
same process on r3
r3(config)#router bgp 100
r3(config-router)#no neighbor 1.1.1.1 peer-group IBGP-NEIGHBORS
r3(config-router)#
*Mar 1 02:17:55.742: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down Neighbor deleted
r3(config-router)#neighbor 1.1.1.1 remote-as 100
r3(config-router)#neighbor 1.1.1.1 update-source lo0
r3(config-router)#
r3(config)#router bgp 100
r3(config-router)#neighbor IBGP-NEIGHBORS route-reflector-client
r3(config-router)#
*Mar 1 02:20:38.953: %BGP-5-ADJCHANGE: neighbor 2.1.1.1 Down RR client config change
*Mar 1 02:20:38.953: %BGP-5-ADJCHANGE: neighbor 2.3.3.3 Down RR client config change
*Mar 1 02:20:38.957: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Down RR client config change
*Mar 1 02:20:38.957: %BGP-5-ADJCHANGE: neighbor 6.6.6.6 Down RR client config change
r5
---
r5(config)#router bgp 100
r5(config-router)#neighbor IBGP-NEIGHBORS route-reflector-client
lets take s3
=============
s3#sh ip bgp
BGP table version is 25, local router ID is 2.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* i12.12.12.12/32 155.0.23.2 0 100 0 200 i
*>i 155.0.23.2 0 100 0 200 i
* i22.22.22.22/32 6.6.6.6 0 100 0 54 i
*>i 6.6.6.6 0 100 0 54 i
* i33.33.33.33/32 4.4.4.4 0 100 0 254 i
*>i 4.4.4.4 0 100 0 254 i
* i122.122.122.122/32
6.6.6.6 0 100 0 54 i
*>i 6.6.6.6 0 100 0 54 i
* i133.133.133.133/32
4.4.4.4 0 100 0 254 i
*>i 4.4.4.4 0 100 0 254 i
* i222.222.222.222/32
6.6.6.6 0 100 0 54 i
*>i 6.6.6.6 0 100 0 54 i
we have full reachability to all we do have duplicates as there redudancy in route
reflection design with r3 and r2 servicing s3.
it is interesting to note although s3 is recieving the route via r3 and r1
the next hop remains the same we do not change the next hop from 6.6.6.6
so when s3 is routing to for example 22.22.22.22 it does not actually have to go
through r1 or r3 for example this network 6.6.6.6 is best reached from s3 via sw1
then r6
s3#traceroute 22.22.22.22
Type escape sequence to abort.
Tracing the route to 22.22.22.22
1 155.0.79.1 0 msec 0 msec 0 msec
2 155.0.67.6 0 msec 0 msec 8 msec
3 *
10.229.254.1 0 msec *
s3#
Another thing that comes up
if we look at r3 bgp table
r3#sh ip bgp
BGP table version is 7, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 12.12.12.12/32 155.0.23.2 0 0 200 i
*>i22.22.22.22/32 6.6.6.6 0 100 0 54 i
* i 6.6.6.6 0 100 0 54 i
* i 6.6.6.6 0 100 0 54 i
* i33.33.33.33/32 4.4.4.4 0 100 0 254 i
*>i 4.4.4.4 0 100 0 254 i
*>i122.122.122.122/32
6.6.6.6 0 100 0 54 i
* i 6.6.6.6 0 100 0 54 i
* i 6.6.6.6 0 100 0 54 i
* i133.133.133.133/32
4.4.4.4 0 100 0 254 i
*>i 4.4.4.4 0 100 0 254 i
*>i222.222.222.222/32
6.6.6.6 0 100 0 54 i
* i 6.6.6.6 0 100 0 54 i
* i 6.6.6.6 0 100 0 54 i
it is recieving multiple updates for each route
for example 22.22.22.22
r3#sh ip bgp 22.22.22.22
BGP routing table entry for 22.22.22.22/32, version 3
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1 3
54, (Received from a RR-client)
6.6.6.6 (metric 156416) from 6.6.6.6 (6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, best
54, (Received from a RR-client)
6.6.6.6 (metric 156416) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal
Originator: 6.6.6.6, Cluster list: 1.1.1.1
54, (Received from a RR-client)
6.6.6.6 (metric 156416) from 5.5.5.5 (155.0.58.5)
Origin IGP, metric 0, localpref 100, valid, internal
Originator: 6.6.6.6, Cluster list: 155.0.58.5, 1.1.1.1
we are recieving from r6,we are recieing from r1 and recieving from r5
so basically r6 is advertisig this to r1 and r2 who advertise it to r5
r5 has r1 and r2 set as route reflector clients so it is advertising it back to us.
There is an option to deal with this. R1 annd r3 are servicing as route-reflectors
to the same clients. THese could be considered one cluster. WHile r5 and it client
would be considered another cluster
Also what is happening is that r6 is sending the update to r3 who reflects to r1
r6 sends the update to r1 who reflects to r3
so on r3 we will set the cluster id
r3(config)#router bgp 100
r3(config-router)#bgp cluster-id 1.1.1.1
r3(config-router)#
also on r1 set the same
r1(config)#router bgp 100
r1(config-router)#bgp cluster-id 1.1.1.1
r1(config-router)#
on r1 we are denying routes from r3 as of same cluster id this should be the same on
r3
*Mar 1 04:16:40.410: BGP(0): updgrp 2 - 2.1.1.1 updates replicated for neighbors:
2.3.3.3 3.3.3.3 5.5.5.5 6.6.6.6
*Mar 1 04:16:40.414: BGP: 3.3.3.3 RR in same cluster. Reflected update dropped
*Mar 1 04:16:40.414: BGP(0): 3.3.3.3 rcv UPDATE w/ attr: nexthop 6.6.6.6, origin i,
localpref 100, metric 0, originator 6.6.6.6, clusterlist 1.1.1.1, path 54, community
, extended community
*Mar 1 04:16:40.414: BGP(0): 3.3.3.3 rcv UPDATE about 222.222.222.222/32 -- DENIED
due to: reflected from the same cluster;
*Mar 1 04:16:40.418: BGP(0): 3.3.3.3 rcv UPDATE about 122.122.122.122/32 -- DENIED
due to: reflected from the same cluster;
*Mar 1 04:16:40.418: BGP(0): 3.3.3.3 rcv UPDATE about 22.22.22.22/32 -- DENIED due
to: reflected from the same cluster;
*Mar 1 04:16:40.418: BGP(0): 3.3.3.3 rcvd UPDATE w/ attr: nexthop 155.0.23.2, origin
i, localpref 100, metric 0, path 200
*Mar 1 04:16:40.418: BGP(0): 3.3.3.3 rcvd 12.12.12.12/32...duplicate ignored
*Mar 1 04:16:40.422: BGP: 3.3.3.3 RR in same cluster. Reflected update dropped
*Mar 1 04:16:40.422: BGP(0): 3.3.3.3 rcv UPDATE w/ attr: nexthop 4.4.4.4, origin i,
localpref 100, metric 0, originator 4.4.4.4, clusterlist 1.1.1.1 2.2.2.2, path 254,
community , extended community
*Mar 1 04:16:40.422: BGP(0): 3.3.3.3 rcv UPDATE about 33.33.33.33/32 -- DENIED due
to: reflected from the same cluster;
*Mar 1 04:16:40.422: BGP(0): 3.3.3.3 rcv UPDATE about 133.133.133.133/32 -- DENIED
due to: reflected from the same cluster;
on r5 we will set a different cluster id
router bgp 100
no synchronization
bgp cluster-id 2.2.2.2
now on r3
*Mar 1 05:51:13.425: BGP(0): 5.5.5.5 rcv UPDATE about 22.22.22.22/32 -- DENIED due
to: CLUSTERLIST contains our own cluster ID;
*Mar 1 05:51:13.425: BGP(0): 5.5.5.5 rcv UPDATE about 122.122.122.122/32 -- DENIED
due to: CLUSTERLIST contains our own cluster ID;
*Mar 1 05:51:13.425: BGP(0): 5.5.5.5 rcv UPDATE about 222.222.222.222/32 -- DENIED
due to: CLUSTERLIST contains our own cluster ID;
*Mar 1 05:51:13.425: BGP: 5.5.5.5 Route Reflector cluster loop; Received cluster-id
1.1.1.1
we are denying the routes that we already sent to r5 as it has our cluster id in it
r5#sh ip bgp 22.22.22.22
BGP routing table entry for 22.22.22.22/32, version 11
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to update-groups:
1
54, (Received from a RR-client)
6.6.6.6 (metric 2300416) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
Originator: 6.6.6.6, Cluster list: 1.1.1.1
54, (Received from a RR-client)
6.6.6.6 (metric 2300416) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 6.6.6.6, Cluster list: 1.1.1.1
r5#
we are recieiving the updates 2 on r5 from both r1 and r3
we were reflecting them back but now as they have the cluster list 1.1.1.1 in them
been sent back they are being denied by r1 and r3
If we take a look at r1 now
r1#sh ip bgp
BGP table version is 14, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r i12.12.12.12/32 155.0.23.2 0 100 0 200 i
r>i 155.0.23.2 0 100 0 200 i
*>i22.22.22.22/32 6.6.6.6 0 100 0 54 i
*>i33.33.33.33/32 4.4.4.4 0 100 0 254 i
*>i122.122.122.122/32
6.6.6.6 0 100 0 54 i
*>i133.133.133.133/32
4.4.4.4 0 100 0 254 i
*>i222.222.222.222/32
6.6.6.6 0 100 0 54 i
r1#sh ip bgp 22.22.22.22
BGP routing table entry for 22.22.22.22/32, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
54, (Received from a RR-client)
6.6.6.6 (metric 156160) from 6.6.6.6 (6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, best
r1#
we are now only receiving the 22.22.22.22 from r6 as it was denied from r3 as it had
the same clusterid and it was denied from r5 as it had our cluster id in the cluster
list.
No comments:
Post a Comment