cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
462
Views
5
Helpful
6
Replies

BGP Route Selection Question

alistair777
Level 1
Level 1

Hi,

My BGP scenario  is using one line as primary and one as backup. I cannot take full tables due to memory requirements.


My ideal scenario would be R1 taking local routes & default from ISP1 and R2 taking just a default route for ISP2.

 

Is it correct that ISP1 will be automatically preferred?


Also how do I prefer one default route over another which was learnt by both ISPs? (inbound and outbound)

6 Replies 6

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

While you haven't indicated that explicitly, I assume that you are running BGP over your two links and want to make one of the links preferred.

The easiest solution would simply be for both your ISPs to send you just a default route, and you can use BGP attributes to define which one of them is going to be preferred.

One of the simplest configurations would be:

router bgp 65000
 neighbor 1.1.1.1 remote-as 1 !!! ISP1
 neighbor 2.2.2.2 remote-as 2 !!! ISP2
 neighbor 1.1.1.1 weight 200
 neighbor 2.2.2.2 weight 100

This way, you will make all routes learned from ISP1 marked with higher weight than the routes learned from ISP2, and whenever your router learns about the same network from both ISPs, it will prefer the one with the higher weight. It would now be completely sufficient for both ISPs to send you just the default route. Of course, you can take more specific routes from ISP1 as well.

Best regards,
Peter

Hi Peter,

Thanks for the detailed response.

At a later date I would like some basic form of load sharing - my understanding is that I would require more prefixes as I can then create policies based on destinations?

My routers have capacity for local routes + default from both providers, would this provide any benefit with a view to load sharing at a later date?

Regards,

Hi,

You are welcome.

Can you explain in more detail what you understand under "local" routes? The word "local" has too many different meanings in the networking context.

At a later date I would like some basic form of load sharing - my understanding is that I would require more prefixes as I can then create policies based on destinations?

Yes, that is correct. However, seeing more specific routes toward particular destinations is just one half of the story. You will also need to make sure that when those destinations respond back to you, packets will flow the same path back, otherwise you'll end up with asymmetric routing. If you have any firewalls or NAT boxes along the path, they will get confused. (If asymmetric routing is okay by you then you can skip the following text.)

Doing this is rather difficult. It would be easier if both your uplinks went to the same ISP. But if each of your uplinks goes to a different ISP, you can not really influence a specific particular remote autonomous system as to how it is going to route packets back to you. When you advertise a network to ISP1 with a certain set of BGP attributes, this is how it's going to be learned by the rest of the world, not just by selected autonomous systems. In other words, there is no easy way of saying: "Remote ASNs X and Y, we will communicate over ISP1, and remote ASN Z, we will communicate over ISP2." because if you do not have a peering with X, Y and Z directly, you have no influence on how they will learn about your networks. You can influence how you reach them, but you cannot influence how they reach you. What you can do is indicate how you want the entire world reach you - whether ISP1 or ISP2 is preferred. More fine-grained choices, however, are not easily accomplished.

Best regards,
Peter

 

Hi Peter,

Yes indeed I meant directly-connected routes to the ISP or partial routes might be a more appropriate term.

So are you saying that less prefixes result in a reduced ability to manipulate paths globally inbound and outbound? Partial routes may increase this but never as much as a full routing table could. In other words the less you know about your routes the less you can manipulate them?

How about taking partial + default from both ISPs, then using Local Preference for outbound routing and AS-Path for inbound to achieve redundancy and give scope for some basic load sharing in the future?

Thanks again
 

 

 

Hi,

So are you saying that less prefixes result in a reduced ability to manipulate paths globally inbound and outbound?

In simple terms, yes. You can manipulate only what you have in your routing table. If you are not getting a particular route from your ISP via BGP, you can not influence the way you are going to send packets toward that network - apart from, of course, setting routes statically.

But please understand that receiving a full BGP table does not make sense, either. Even with all 500,000+ routes in your routing table, you can only choose between two exit points. It does not make much sense to set 250,000 routes to point to ISP1 and the rest to ISP2 - you can achieve a similar result by receiving very crude aggregates from your ISPs with their prefix lengths no more than, say, /4 (/1 would split the internet into halves, /2 would split it into quarters, /3 would split into eighths, and /4 would split it into sixteenths). Then you'll simply manipulate these gross agregates and their next hops.

In other words the less you know about your routes the less you can manipulate them?

Yes, that is the basic idea. But the true granularity you're getting with more prefixes and losing with less prefixes is concerned with the destinations you're talking to. If you manipulate, say, a single 128.0.0.0/1 prefix, you influence how you reach the entire half of the routable internet, while manipulating 128.0.0.0/4 would only influence your routing toward 1/16 of the whole internet.

How about taking partial + default from both ISPs, then using Local Preference for outbound routing and AS-Path for inbound to achieve redundancy and give scope for some basic load sharing in the future?

That certainly sounds like a plan, and it would work, even though - to keep absolute consistency and symmetric routing - you would still need to make sure that one link (one ISP) is preferred for all oubound and inbound traffic, and the second ISP is just a backup. You may configure your router to prefer some paths through ISP1, some others through ISP2, but the return traffic to your own AS will most probably follow only one of these ISPs no matter what is the source autonomous system, so if you do load sharing, for some traffic, you will get asymmetric routing.

Does this make any sense? This topic is one of the more difficult ones.

Best regards,
Peter

Hi Peter,

 

Thank you for explaining that in such a concise format.

 

So granularity is concerned with how specific or less specific your prefixes received from providers - not just how many prefixes you have etc. As you said load sharing can be achieved in a rudimentary manner by splitting the IPv4 range into half, quarters etc.

 

With regards to the setup I understand your statement as:

 

Asymmetrical routing will occur as a result of load sharing as one path will always be preferred inbound due to AS-Path Prepending.

 

In short, it's a bit of a balancing act which depends on the quality of information you have: the routes received, knowledge of your traffic destinations and last be not least: experience with BGP!

 

Thanks again

 

 

 

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:

Review Cisco Networking products for a $25 gift card