cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1026
Views
0
Helpful
5
Replies

How does CEF and its load sharing algorithms work with a pair of default routes?

ashish-nagpal
Level 1
Level 1

Hi,

I have a router(router-A) which is running iBGP with my other 2 Internet G/W routers(router-B & C) which have multiple uplinks to different/same Internet providers. Below is a design of my n/w.

          \\/\///          \\/\///  <--- uplinks to ISPs

            @---(ibgp)--@    <---- Internet G/Ws (B & C)

               \            /

                \ (ibgp) /

                 \        /

                    @            <---- router A

As of now I am taking full internet routing tables from my uplink providers to router B & C and advertising the same table to my downstream iBGP peer (router A). My router "A" has less b/w capacity and memory than my G/Ws "B" & "C", so during some uplink flap or any such mishap my downstream iBGP peering with router "A" goes down and take long time to come back and install back full internet routing table. To avoid such situation with router "A", I am thinking to send just default routes from my G/Ws to routers "A" and configure ibgp multipath-2 on router "A" itself so that there should not have any impact of uplinks mishap on router "A" at least. At the same time I don't want that there should be per-packet load balancing because that is not good for any delay sensitive traffic and moreover it is CPU intensive. I am using CEF and load balancing used here is default "per-destination". With CEF, it is understanable that CEF uses per-pair or per-session (source & destination) based load balancing when have source and destination in routing as well as in CEF table but how can I achieve per-session load balancing with default-routes from my both IGWs? I don't want that my only one link to IGWs from router "A" is kept utilze and another left unused which doesn't solve the purpose of load sharing. I am also thinking to use "CEF universal load sharing" algorithm to bring more granularity. I also hope that with default routes, per-packet load sharing won't get activated automaticaly because in CEF table there won't any specific route for destination and request for path goes to CPU then.

I will be very thankful, if experts of this forum throw some light on this issue and if possible, please provide better solution.

3 Accepted Solutions

Accepted Solutions

Jon Marshall
Hall of Fame
Hall of Fame

CEF load balances based on source/destination IP addresses and by default it uses per-destination load sharing. So with 2 default routes as long as the source/destination pairs differ both uplinks from router A will be used.

Jon

View solution in original post

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Ashish,

if you have added the ibgp multipath commands and you have two default routes you are fine if there are direct links between RB and RC.

Actually CEF load balancing consider the two possible next-hops and performs load balancing per session as you have correctly described even if using two default routes.

For CEF actually what counts is to identify the next-hops to be able to prepare CEF entries to be used for efficient packet rewrite. CEF uses topology information to build CEF table entries and a default route 0.0.0.0/0 is a legitimate entry as the other ones, just it is the less specific entry in the table.

To be noted that in case of failure of direct link between RB and RC you can be at a risk of routing loop if the iBGP session between RB and RC is going via RA.

You can solve this in the following ways:

adding another direct link between RA and RB

OR

enabling MPLS on all links between RA, RB and RC in this latter case when direct link fails RA becomes a P node on the LSPs between RB and RC and this solves the possible routing loops issues

Hope to help

Giuseppe

View solution in original post

Hello Ashish,

Site of Origin applies to VPNv4 routes being a special type of route-target extended community. So this may apply to your scenario if most routes are VPNv4 routes and you are providing MPLS L3 VPN services.

About dividing the cluster in two parts changing the cluster-id on the two RB and RC that act as route reflector servers, this can be of help in case you want to ensure IP or VPN connectivity when two events happen: client Rj losts iBGP session with RB and client Rk losts iBGP session with RC.

in this case if cluster-id is different RB and RC are allowed to exchange routes and Rj will see Rk's routes with a cluster-list or [RC RB] and originator-id of Rk.

We have tested this some years ago with positive results in a lab contexts.

To be noted that BGP attributes cluster-list and originator-ids allow safe tracing of iBGP advertisements even in classic IPv4 general routing table family without requiring SOO.

Even if somewhere it is stated that these two attributes ( cluster-list and originator-id) are not used to make the best path choice in iBGP, our tests showed they are and a shorter cluster-list is preferred meaning the advertisement has had less reflections. This is reasonable.

Hope to help

Giuseppe

View solution in original post

5 Replies 5

Jon Marshall
Hall of Fame
Hall of Fame

CEF load balances based on source/destination IP addresses and by default it uses per-destination load sharing. So with 2 default routes as long as the source/destination pairs differ both uplinks from router A will be used.

Jon

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Ashish,

if you have added the ibgp multipath commands and you have two default routes you are fine if there are direct links between RB and RC.

Actually CEF load balancing consider the two possible next-hops and performs load balancing per session as you have correctly described even if using two default routes.

For CEF actually what counts is to identify the next-hops to be able to prepare CEF entries to be used for efficient packet rewrite. CEF uses topology information to build CEF table entries and a default route 0.0.0.0/0 is a legitimate entry as the other ones, just it is the less specific entry in the table.

To be noted that in case of failure of direct link between RB and RC you can be at a risk of routing loop if the iBGP session between RB and RC is going via RA.

You can solve this in the following ways:

adding another direct link between RA and RB

OR

enabling MPLS on all links between RA, RB and RC in this latter case when direct link fails RA becomes a P node on the LSPs between RB and RC and this solves the possible routing loops issues

Hope to help

Giuseppe

I would like to add here something, that RB & RC are also route-reflectors with same cluster ID in this network. All of the devices in this network are conected via couple of switches. So, nothing is directly connected but they have seperate multiple(for redundancy) etherchannels to connect them. So, ibgp between RB & RC is kind of usless as long as they are in same cluster. I would like a suggestion here. It is that, should I change the cluster id on both IGWs. It will increase the routing table on both IGWs but it will add a redundant path. I know, breaking cluster can lead to updates/traffic looping problem but that can also be controled with SOO, right?

Hello Ashish,

Site of Origin applies to VPNv4 routes being a special type of route-target extended community. So this may apply to your scenario if most routes are VPNv4 routes and you are providing MPLS L3 VPN services.

About dividing the cluster in two parts changing the cluster-id on the two RB and RC that act as route reflector servers, this can be of help in case you want to ensure IP or VPN connectivity when two events happen: client Rj losts iBGP session with RB and client Rk losts iBGP session with RC.

in this case if cluster-id is different RB and RC are allowed to exchange routes and Rj will see Rk's routes with a cluster-list or [RC RB] and originator-id of Rk.

We have tested this some years ago with positive results in a lab contexts.

To be noted that BGP attributes cluster-list and originator-ids allow safe tracing of iBGP advertisements even in classic IPv4 general routing table family without requiring SOO.

Even if somewhere it is stated that these two attributes ( cluster-list and originator-id) are not used to make the best path choice in iBGP, our tests showed they are and a shorter cluster-list is preferred meaning the advertisement has had less reflections. This is reasonable.

Hope to help

Giuseppe

Hi giuslar,

This is quite helpful and it is right that SOO is extended community of VPNv4 routes. It just slipped from my mind.

My last question is that will there be any looping problem with different cluster ids on both RR?

I feel there should not be because originator id will play a role to avoid loop, right?

Thanks

Ashish

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco