Lessons Learned:
iBGP Route Reflection
Eliminates need for full mesh
-only need peering(s) to the RR(s)
Like OSPF DR and IS-IS DIS, minimizes prefix replication
--Send one update to the RR
--RR sends the update to its “clients”
Loop prevention through Cluster-ID
--RR discards routes received with its oven Cluster-ID
--Does not modify other attributes such as next-hop
======================================================
The overall principal in Route Reflection can be thought of
like the DR in OSPF. Where there is some sort of centralized device, which is
used to minimize the amount of control plane routing information that is sent
throughout the network.
With a full mesh of iBGP peers it’s a lot of administrative
overhead to maintain all the peering’s. It’s also a lot of control plane information
that the router needs to process as it’s sending all of the duplicate updates
to all the peers in the network. With Route Reflection we can centralize the
peering arrangements so that the clients are sending one copy of their routing
updates to the RR then the RR can turn around and send to all the clients in
the network.
Note: you can have more than one RR I a network, it just
depends on what your redundancy goals are based on the physical topology of the
network.
With RR we’re breaking the loop prevention mechanism of the
IBGP PEERS where is says if you learn a route from and ibgp neighbor, you’re
not allowed to advertise it to another ibgp neighbor.
We will now need to implement another form of loop
prevention – in RR – this comes in the form of the Cluster-ID.
When a RR receives an update from a client and then forwards
it on to another client or another ibgp peer.
The RR’s router-id, also known as the Cluster-ID, is going
to get added to the update in the cluster list.
If a RR receives an update with its own Cluster-ID in the
cluster list, it will automatically filter those updates out.
Route Reflector
Peering’s.
Route Reflectors can have three types of peers
EBGP Peers
--Neighbors in different AS (routers that are in a different
AS than us locally)
Client Peers
--iBGP peers with # route-reflector-client (routers that
have the RR-Client configured in their neighbor command)
Non-Client peers
--ibgp peers without #route-reflector-client (regular ibgp
neighbors – W/O the client command configured)
The reason that it is significant to separate these peers
into these 3 separate roles is because the RR is going to treat routing updates
differently depending on where the update is coming from and where the update
is going to.
Route Reflector
Update Processing
RR processes updates differently depending on what type of
peer the came from.
EBGP learned routes….
--Can be advertised to EBGP peers & clients &
Non-clients
Client learned routes
--can be advertised to EBGP peers, clients, and Non-clients
Non-Client learned routes
--can be advertised to EBGP peers and Clients (This is the
only restriction)
RR placement based upon these rules.
Key point: remember
that the RR will not advertise routes between two non-client peers.
There are cases where there are multiple RR’s inside the
same AS to avoid single points of failure.
Large Scale Route
Reflection
Larger scale BGP designs cannot be services by only a single
RR
--Single RR is a single point of failure.
RR “Clusters” allow redundancy and hierarchy
--Cluster is defined by the clients a RR servers
--RRs in the same cluster user the same cluster-ID
Inter-Cluster peering’s between RRs can be client or
non-client peering’s.
--Depends on the redundancy design
Note: RRs will generally select only ONE best path on a per
route basis.
This selection will ultimately go into the routing table and
then ultimately what routes can be advertised.
Topology RR:
First thing we need to do is to
verify we have underlying reachability. For this exercise I’ll user EIGRP AS
100
Since I will be using the
loopbacks as the update source on each router, I will advertise them into my
IGP.
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to
2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5),
round-trip min/avg/max = 20/22/32 ms
R1#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to
1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5),
round-trip min/avg/max = 1/2/4 ms
R1#
Then we need to configure R1 – who
will be the RR:
R1:
router bgp 100
no synchronization
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback1
neighbor 2.2.2.2 route-reflector-client
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback1
neighbor 3.3.3.3 route-reflector-client
no auto-summary
Then we’ll configure each other
Router as RR Clients and point them both to the RR as the neighbor.
R2:
router bgp 100
no synchronization
bgp log-neighbor-changes
network 2.2.2.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 100
neighbor 3.3.3.3 remote-as 100
no auto-summary
!
R3:
router bgp 100
no synchronization
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback1
neighbor 2.2.2.2 remote-as 100
no auto-summary
!
We should now verify the config
via #sh ip bgp
R1:
R1#sh ip bgp
BGP table version is 18, 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
*> 1.1.1.0/24 0.0.0.0 0 32768 i
r>i2.2.2.0/24 2.2.2.2 0 100
0 i
r>i3.3.3.0/24 3.3.3.3 0 100
0 i
R1#
-------------------------------------------------------------------------------------------
R2#sh ip bgp
BGP table version is 18, local
router ID is 2.2.2.2
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>i1.1.1.0/24 1.1.1.1 0 100
0 i
*> 2.2.2.0/24 0.0.0.0 0 32768 i
r>i3.3.3.0/24 3.3.3.3 0 100
0 i
R2#
-------------------------------------------------------------------------------------------
R3#sh ip bgp
BGP table version is 18, 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
r>i1.1.1.0/24 1.1.1.1 0 100
0 i
r>i2.2.2.0/24 2.2.2.2 0 100
0 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
R3#
In this case the r> next to the
prefix does not mean RIB failure, it means it was learned from the
Route-Reflector.
We can verify the RR is working correctly
– I’ll add a loopback interface to R3 and add it’s prefix into BGP-
network 6.1.1.0 mask 255.255.255.0
We should now see this route or
the RR:
R1#sh ip bgp
BGP table version is 19, 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
*> 1.1.1.0/24 0.0.0.0 0 32768 i
r>i2.2.2.0/24 2.2.2.2 0 100
0 i
r>i3.3.3.0/24 3.3.3.3 0 100
0 i
*>i6.1.1.0/24 3.3.3.3 0 100
0 i
Also on R2:
We can see the route with a next
hop of 3.3.3.3 and learned from the Loopback of R1 – the RR
R2#sh ip route 6.1.1.0
Routing entry for 6.1.1.0/24
Known via "bgp 100", distance 200, metric 0, type internal
Last update from 3.3.3.3 00:30:32 ago
Routing Descriptor Blocks:
* 3.3.3.3, from 1.1.1.1, 00:30:32 ago
Route metric is 0, traffic share count is
1
AS Hops 0
No comments:
Post a Comment