Two Links to One ISP, Primary and Backup
So the first example we will look at is
dealing with the case where one link is going to be used as the primary link and the other link is the backup link. And this will be for two links to the same
ISP and it applies when the end site has bought maybe a large primary WAN link to the upstream provider and a small secondary WAN link which the users backup. For example, the primary path might be an E1 2 megabits per second, the backup might be 64 kilobits per second or something similar. Obviously to apply to your situation scale the bandwidths appropriately. If you look at the diagram, you’ll see that AS 100 is connected by two paths to AS 65534.
The link between router A and C is the primary path and the link between router B and D is the backup path. As you can see in the diagram, we’ve used AS 65534 for the end site that is multihoming. This is a private AS. As we learned earlier, there’s no need for a public AS number for this type of multihoming. The end site has only two external connections and only connects to the same upstream provider. AS 100 will remove the private AS.
It hears from its customers and of course, it will remove any customer sub-prefixes from internet announcements. So let’s have a look and see how we configure this. Well to start, we announce the /19 aggregate on each link. The primary link will receive the /19. The backup link will receive the /19. This means the upstream provider will see the /19 on both paths and if either link fails because we’re announcing the 19 on the alternative path as well, it ensures continued connectivity for the end site.
For inbound, well, the upstream provider
simply announces a default route on both paths. So the end site will see the default route on both links and again, if either link should fail, the default being heard on other paths ensures continued connectivity. But how do we make one path the primary and the other one the backup? Well as we learned when we looked at the BGP attributes, we can use the metric and the local preference to achieve this. If we do all the traffic engineering from the insight perspective, if the insight announced the /19 on the backup path with an increased metric, then the upstream provider will see the two paths, one with metric zero -which is the default- and the other one with a larger metric -larger non zero metric- which makes this the backup path.
For the other way around, the insight will
receive the default route on both links. One path will have the default local
preference of 100 and the other path, the end site, will reduce the local preference. Say make it 80, this lower local preference means the backup path is less preferred, hence making it the backup. So with this setup, the backup link having the /19 announced with increased metric and the inbound default route being tagged with a lower local preference, will ensure that the backup link functions as designed. And of course, if either link fails, the other one becomes the primary path ensuring continued connectivity between the end site and the operator. Let’s look at the configuration for router A. We’ve included the Cisco IOS configuration showing how this might be configured. Router A is the primary path on the end site and you see router A is announcing the aggregate and is accepting the default route from the upstream provider.
The router here, of course, is also originating the /19 address space. If we look at router B, we see the same prefix list letting the aggregate out to the upstream provider and we see another prefix list, which also accepts the default route from the upstream provider. So this is the same configuration as on router A, but we now have two route maps. One route map, which I’ve called “med10-out”, is applied to the outbound announcement, and the other route map “lp-low-in”, is applied to the incoming announcements. If we look at the next slide, we’ll see what the route maps are doing.
“route-map med10-out” sets the metric on all prefixes being sent out to the upstream provider. We’re only announcing the /19, so the /19 gets a med of 10 set on it. The “route-map lp-low-in” matches all prefixes and sets local preference 90 inbound and then the end site will see the two paths, one with local preference 100, the default on router A, and this one on router B with local preference 90 and we achieve the setup that we were aiming for. If we look at the router C, configuration on the upstream provider what the upstream provider does is
originate a default route, set up a prefix list to let that default outbound to the customer, and create another prefix list to allow the customer /19 address block inbound.
It’s a very simple configuration and indeed it’s the same as for router D, again a “default-originate” allowing the customer prefix in and allowing the default route outbound. So the upstream provider has a
very simple configuration that they don’t need to adjust if the customer chooses to swap around which link becomes primary, and which link becomes backup. If we look at router E, router E was the
upstream provider’s connection to the rest of the internet. And I want to point out the “remove-private-as” command. The upstream provider there is stripping out the private AS 65534 in the announcement of the customer
prefix out to the Internet. As we saw earlier, this is best practice: private AS numbers should not be seen on the public internet. So the result of this is, that router E will announce the /19 prefix learned from the customer end site
out to the internet as though it originated from AS100.
𝗢𝗿𝗮𝗰𝗹𝗲 𝗼𝗳 𝗛𝗲𝗮𝘃𝗲𝗻𝘀 ᶦˢ ʸᵒᵘʳ ᵍᵘᵃʳᵈᶦᵃⁿ ᵃⁿᵍᵉˡ ᵗʳʸᶦⁿᵍ ᵗᵒ ˢᵉⁿᵈ ʸᵒᵘ ᵃⁿ ᵘʳᵍᵉⁿᵗ ᵐᵉˢˢᵃᵍᵉ? ɪꜰ ʏᴏᴜ ꜱᴇᴇᴋ ɢᴜɪᴅᴀɴᴄᴇ ᴀɴᴅ ɪɴꜱɪɢʜᴛꜱ ɪɴᴛᴏ ᴛʜᴇ ᴘᴀꜱᴛ, ᴘʀᴇꜱᴇɴᴛ, ᴀɴᴅ ꜰᴜᴛᴜʀᴇ ᴡɪᴛʜ qᴜᴇꜱᴛɪᴏɴꜱ ᴀʙᴏᴜᴛ ʟᴏᴠᴇ, ʀᴇʟᴀᴛɪᴏɴꜱʜɪᴘꜱ, ᴏʀ ᴍᴏɴᴇʏ – ᴄᴏɴɴᴇᴄᴛ ᴡɪᴛʜ ʏᴏᴜʀ ᴀɴɢᴇʟ ᴛᴏᴅᴀʏ https://aef5aa-t-ztics23v7-ljxbw4j.hop.clickbank.net/
