BGP Confederation Configuration:

Reduces full mesh iBGP requirement by splitting AS into smaller Sub-ASes

--Inside Sub-AS full mesh or RR requirement remains

--Between Sub-AS acts like EBGP

Devices outside the confederation do not know about the internal structure

--Aub-AS numbers asre stripped from advertisements to True EBGP peers

Typically uses ASNs in private range (64512 – 65535)

------------------------

Essentially BGP Confederations are when we take the entire AS and split it into smaller more manageable ASes.

This is similar to Clusters in route reflection but based on the normal loop prevention mechanisms of EBGP –

The loop prevention is based on the AS PATH.

All configuration inside the SUB-AS will still need a full mesh of peering’s or route reflection. The change in confederation is going to be for any updates between the SUB-ASes, in what is now known as the confederation EBGP peers.

The Sub AS numbers will be stripped form advertisements for routers outside the AS or not part of the configuration.

BGP Confederation Configuration:

Enable the BGP process

# router bgp (SUB-AS)

Specify the main AS number

#bgp confederation-id (main-AS)

Specify other sub-ASes the you peer with

#bgp confederation-peers (sub-as1 sub-as-2, etc)

--not all Sub-ASes, just those directly peered with.

Note: in order to tell the difference between a true EBGP peer and a confederation EBGP peer. Any routers on the edge of the SUB-AS,

Will need to specify which of its neighbors are confederation peers and which are true EBGP peers.

For this we would use the #bgp confederation-peers (sub-as1 sub-as-2, etc)

Command – it only needs to be configured on the SUB-AS edge and only for the SUB as systems were directly peering with.

We will need to use the Private range for the Internal SUB-ASes and they cannot overlap. When Sub-ASes exchange information, they will use the SUB-AS number prepended to the end of the routes.

One thing to note about Confederation ebgp peers – Since theses technically count as EBGP peering, the TTL will be sent to 1 be default.

 Note – if you require full mesh – you can configure route reflectors inside your SUB-ASes.

Once all peering are up – we would verify peering. We should also expect to see – inside the SUB-ASes ONLY – the Sub-as. If peering with other ebgp neighbor we would not want to see the Sub-as in the path.

If we are traversing though sub-ases we would see the sub-as prepended and in parentheses ex: (65000) (65146) 100 200, etc.

Note: there are special configurations related only to the confederation designs and also to the community attributes – specific to confederations.

These are:

# bgp bestpath med confed – which means, between our confederation peers we could compare the MED to figure out which path to choose.

We could also create a route-map the set the community attribute.

For example – set community the is the local-as (also sometimes know as # no export sub-confed). This means that prefixes in the local AS will not go out of the sub-as …

We can also set the command “no-export”, this will essential send the prefix to our sub-as EBGP peers but not our true EBGP peer.

This just depends where we want the prefix to be confined to – the local-as or the entire sub-as

Large Scale BGP Route Reflection

Lesson Learned:

Larger Scale BGP desisgn cannot be serviced 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 use the same Cluster-ID

Inter-Cluster peerings between RRs can client of non-client peerings

--Depends on redundancy design.

Using multiple RR’s in cluster, for example RR1, RR2, and RR3. Each with client connected to each RR.

The ultimate design goal is when a client for RR1 sends an update within the cluster to the RR. These updates are passed down to the clients in the Cluster. The update is then passed to the other clusters then in turn sends the updates down to their clients.

Then based on the rules of RR’s, this will determine whether or not the route is updated. Example, if RR1, RR2, and RR# are all clients of each other, if they are clients, the updates will be passed along, if not then the updates will fail.

Note: there is technically nothing wrong with RR’s being clients of each other. The only issue is there will be more overhead in the Control Plane. Then even though the route is looping between the RR’s, the Cluster list is going to prevent that loop from occurring. In a large scale design you could be processing 3 or 400,000 routes.

The Case where you would want the RRs to be clients of each other, is if there was a link failure between the RR’s and if the RR’s are non-clients, it would affect the updates between all RRs.

TOPOLOGY:

From the Topology The Configs for RR1 and it’s clients will look like this:

RR Config:

R1:

Router bgp 100

neighbor R1CLIENTs peer-group

neighbor R1CLIENTs remote-as 100

neighbor R1CLIENTs route-reflector-client

neighbor R1CLIENTs update-source Loopback1

neighbor 2.2.2.2 peer-group R1CLIENTs

neighbor 3.3.3.3 peer-group R1CLIENTs

---------

CLIENT Config:

router bgp 100

neighbor 1.1.1.1 remote-as 100

neighbor 1.1.1.1 update-source loopback1

Cluster 2:

RR Config:

R4:

Router bgp 100

neighbor R4CLIENTs peer-group

neighbor R4CLIENTs remote-as 100

neighbor R4CLIENTs route-reflector-client

neighbor R4CLIENTs update-source Loopback1

neighbor 5.5.5.5 peer-group R4CLIENTs

neighbor 6.6.6.6 peer-group R4CLIENTs

CLIENT Config:

router bgp 100

neighbor 4.4.4.4 remote-as 100

neighbor 4.4.4.4 update-source loopback1

Cluster 3:

RR:

Router bgp 100

neighbor R7CLIENTs peer-group

neighbor R7CLIENTs remote-as 100

neighbor R7CLIENTs route-reflector-client

neighbor R7CLIENTs update-source Loopback1

neighbor 8.8.8.8 peer-group R7CLIENTs

neighbor 9.9.9.9 peer-group R7CLIENTs

CLIENT Config:

router bgp 100

neighbor 1.1.1.1 remote-as 100

neighbor 4.4.4.4 update-source loopback1

Once these are all up we will need to verify the peerings.

We can do a #sh ip bgp sum – we should see on all the RR – the peers for all the neighbors:

Ex:

R1#sh ip bgp summary

BGP router identifier 1.1.1.1, local AS number 100

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

2.2.2.2         4   100      37      37        1    0    0 00:34:50        0

3.3.3.3         4   100      37      37        1    0    0 00:34:53        0

4.4.4.4         4   100       6       6        1    0    0 00:02:50        0

7.7.7.7         4   100       6       6        1    0    0 00:02:52        0

R1#

Also – from RR4 –

R4#sh ip bgp

BGP table version is 20, local router ID is 4.4.4.4

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

* i1.1.1.0/24       1.1.1.1                  0    100      0 i

*> 4.4.4.0/24       0.0.0.0                  0         32768 i

r>i7.7.7.0/24       7.7.7.7                  0    100      0 i

R4#

We can see the routes and how they’re learned.

interface Loopback10

 ip address 100.100.100.9 255.255.255.0

end

So now on R9 – lets add a route and advertise it and see how BGP updates the route.

R9(config)#router bgp 100

R9(config-router)#network 100.100.100.0 mask 255.255.255.0

We can see from another RR in the topology that the route has been updated from one RR to another:

*>i100.100.100.0/24 9.9.9.9                  0    100      0 i

R7#

Note:  If there’s a case where there’s more than 1 RR per cluster, first we would need to specify the cluster ID be the same on both RRs – to keep loops form happening. Also we might want to set the local preference because the Local Preference is for the entire AS.

For example:

On R1 – I’ll set the local preference to be 100 and on R4 I’ll set the preference to be 200.

R4:

R4#sh route-map

route-map PREF_200, permit, sequence 10

  Match clauses:

  Set clauses:

    local-preference 200

  Policy routing matches: 0 packets, 0 bytes

Then under the BGP process

I’ll tell neighbor 7.7.7.7 (R7) to use this weight

R4(config-router)#neighbor 7.7.7.7 route-map PREF_200 in

Note: this change will not apply until we ask for a route refresh. For this lab I’ll just clear ip bgp.

   Network          Next Hop            Metric LocPrf Weight Path

*>i1.1.1.0/24       1.1.1.1                  0    100      0 i

*> 4.4.4.0/24       0.0.0.0                  0         32768 i

r>i7.7.7.0/24       7.7.7.7                  0    200      0 i

*>i100.100.100.0/24 9.9.9.9                  0    200      0 i

Now we can see the routes form R7 have a preference of 200.

Note: The convergence of the BGP network, is more a function if the underlying IGP that BGP itself. Because we’re always relying on the IGP route to the next hop, which means if we can get high-availability for the next hop, it doesn’t really matter what the BGP update is.

BGP Route Reflectors

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