We’re now going to explore BGP Route Redistribution. BGP Route Distribution is where you can redistribute routes that the router has learnt via some other protocol, e.g. static, OSPF, EIGRP, RIP etc. into BGP, so in effect it becomes a BGP Route.
A common example for this might be the redistributing a default static route into your network (perhaps for access to the Internet). Another common example would be redistributing a route (or routes) to a network (or networks) that have been learnt via another protocol (e.g. OSPF) on a border router, where the network from which it learnt the routes doesn’t support BGP, therefore doesn’t have the capability to learn it.
Its worth noting that when you enable BGP Redistribution for a particular protocol, it enables it for that protocol completely (global), If this would mean that you’d suddenly start advertising routes into BGP via redistribution that you don’t want to, you would need to use Policy to filter would actually get redistributed into BGP (from the source protocol) and what does not.
Topology
For this article, we’re going to be adding a new router/switch to the topology, which we can use to show how you can redistribute a static route; so we’ll need a static route we can redistribute, and therefore somewhere for it to go!
We’re going to add Switch A into AS Blue, now it won’t run BGP, it will just act as a “Router on a Stick”, but it will be within the AS in terms of it’s routing (and what it connects to), but won’t be running BGP. It will have two local LAN networks on it, we can use to explore redistribution of static routes.
Without redistributing static routes being configured on Router G, only the networks directly connected to Router G (i.e. 10.1.2.0/24) would be able to reach the networks hosted on Switch A (10.1.4.0/24 and 10.1.5.0/24).
We’ll also add a Default Static route on Switch A to point all traffic for all networks at Router G, so it has a route to everything, but Switch A won’t be participating in BGP, nor will it be participating into OSPF, although it’s point to point network 192.168.100.48/30 will need to be added into OSPF for it to become a “feasible” route for the BGP routing.
Preparation
We need to get Switch A and Router G configured with the networks and point to point link, so we have something we can use to experiment with the static route redistribution.
Switch A
We add a point to point network, along with two VLANs which will behave as our test LAN networks on the Switch/Router. We then add a static default route to point all networks at the point to point IP of Router G.
Note we are not configuring BGP or any other routing protocol for that matter; this Switch will just act as a simple router using only static routing.
create vlan "SWA-RG"
configure vlan "SWA-RG" ipaddress 192.168.100.49/30
enable ipforwarding vlan "SWA-RG"
configure vlan "SWA-RG" add port 49 untagged
create vlan "SwitchA-LAN1" tag 1008
configure vlan "SwitchA-LAN1" ipaddress 10.1.4.1/24
enable ipforwarding "SwitchA-LAN1"
enable loopback-mode vlan "SwitchA-LAN1"
create vlan "SwitchA-LAN2" tag 1009
configure vlan "SwitchA-LAN2" ipaddress 10.1.5.1/24
enable ipforwarding "SwitchA-LAN2"
enable loopback-mode vlan "SwitchA-LAN2"
configure iproute add default 192.168.100.50 vr "VR-Default"If we were to examine the route table on Router G, we’d see that it does not yet have any knowledge of these two networks, or any routes to it. Let’s fix that.
Router G
We add the VLAN for the point to point link to Switch A, we then need to ensure that this point to point network is added to OSPF (as a passive network – i.e. there is nothing at the other end which will be making join requests), so that when we use this network within BGP the point to point network is seen as feasible (and thus installed), because it is routable.
create vlan "RG-SWA"
configure vlan "RG-SWA" ipaddress 192.168.100.50/30
enable ipforwarding vlan "RG-SWA"
configure vlan "RG-SWA" add port 48 untagged
configure ospf add vlan "RG-SWA" area 0.0.0.0 passiveWe then need to add some static routes so that Router G knows how to route to the networks 10.1.4.0/24 and 10.1.5.0/24.
configure iproute add 10.1.4.0/24 192.168.100.49 vr "VR-Default"
configure iproute add 10.1.5.0/24 192.168.100.49 vr "VR-Default"If we examine the route table on Router G (not the BGP Routes), the whole route table, we can see the following, left, before – adding the static routes, then after on the right with the static routes added.
Verify
If we try to ping from the LAN1 network interface (10.1.4.1) on Switch A to Router H’s LAN network interface (10.2.2.1), we can see that it is not working.
Why? Because although Switch A has a route to any network (via it’s default static route pointing at Router G), and Router G knows a route back to Switch A’s LAN networks (10.1.4.0/24 and 10.1.5.0/24), no other part of the network knows these routes or how to reach these two networks.
Redistribute Static Routes
So what do we do? That’s where we can use redistribution to inject these routes into BGP, so they can be learnt by AS Blue, AS Green and AS Red, and all the routers within.
Extreme Networks (EXOS) calls redistribution in this case “Export”, so we’ll be exporting static route(s) into BGP.
Remember earlier that BGP export rules will export all static routes into BGP, it’s all or nothing on or off. In this particular example we don’t care, but in the next example we’ll want to be selective about the static routes we do and don’t want to export (redistribute) to BGP, so we’ll show how that can be achieved with…..you guessed it Policy.
Router G
Add the BGP export command to export (redistribute) all the static routes (known by Router G) to BGP. If you so wished you could specify which IPv4, IPv6 (and multicast addresses) routes you’d want, but in our case we’re just going to export static routes of all types.
enable bgp export staticVerify
If we now check the BGP Route Table, normal Route Table and the BGP Transmitted Routes (to one of the neighbours) we can see that the routes to Switch A’s LAN networks 10.1.4.0/24 and 10.1.5.0/24 are present.
Ignore the route for 10.1.0.0/16 this was left in the switch configuration from some previous testing. It’s only the two routes 10.1.4.0/24 and 10.1.5.0/24 which we are interested in this particular example.
I removed the old static route that was configured on Router G, which covered the supernet for 10.1.0.0/16 pointing at Switch A.
But it is a good learning point. So why did this route that included all the networks within AS Blue not cause us problems? Why did all traffic for the 10.1.0.0/16 supernet and all the networks within for Router A’s LAN network, Router B’s LAN network, Router E’s LAN network all just get not funnelled into Switch A?
Well, It’s because there were more specific routes available. For example if traffic was destined for a network that existed e.g. 10.1.1.0/24 which is hosted on Router A, then there would be a route that matches this, thus that would be used. But if the traffic was destined for a network that does not exist e.g. 10.1.10.0/24, then there is no more specific route available and therefore this traffic would just be funnelled at Switch A, as being the only match for the 10.1.10.0/24 network, matching the supernet 10.1.0.0/16.
If you look at the BGP routes you’ll notice the column with “i” and “?”, this is the origin code.
IGP (i) – Most Preferred: Indicates the route was generated by an Interior Gateway Protocol (IGP) and injected into BGP using the network statement. It signifies that the originating Autonomous System (AS) has full knowledge of the IP prefix.
Incomplete (?) – Least Preferred: Indicates that the origin of the route is unknown or was introduced into BGP via redistribution from another source (such as static, OSPF, or EIGRP routes).
So in this case these new routes we added via export (redistribution) are marked as “incomplete” with a “?” because they have been introducted/learned via a static route imported into BGP.
Test
If we now do a test to verify the configuration works as expected. So we’ll ping from Switch A to Router H (in AS Green).
As we can see we now have connectivity, because Router H (and all the rest of the Routers within our networks) now has learned the route back to 10.1.4.0/24 which was exported (redistributed) from the static route into BGP.
Redistribute Static Route – Restrict with Policy
So we’ve configured to export (redistribute) static routes, but it is a bit of a blunt instrument, its now advertising all static routes on the Router G to BGP, what if we don’t want this? Policy can be used to limit what is and what is not exported (redistributed) into BGP. So let’s experiment with this, we are going to make it so only the 10.1.5.0/24 is exported (redistributed) to BGP, we want the 10.1.4.0/24 network not to be advertised into
Router G
We first create a policy document with:
vi STATIC-EXPORT.polAnd enter the following, and remember to check it with “check policy STATIC-EXPORT” after you’ve created it.
STATIC-EXPORT.pol
entry STATIC-EXPORT-PERMIT {
if match any {
nlri 10.1.5.0/24 ;
}
then {
permit ;
}
}
entry STATIC-EXPORT-DENY {
if match any {
nlri 10.1.4.0/24 ;
}
then {
deny ;
}
}Then we apply it to our export (redistribute) static command for BGP. Note that we need to disable the export before adding the policy, then re-enable.
enable bgp export static address-family ipv4-unicast export-policy STATIC-EXPORTBefore
After
And now we can see we only have the 10.1.5.0/24 network being exported (redistributed) into BGP, the policy is doing its thing by ensuring that 10.1.4.0/24 is not exported. If we have other networks (from other protocols) we wish to permit or deny export, we have fine-grained control, so although it is an all or nothing export (redistirbution) it can be configured to be more specific.
Conclusion
We have seen how we can use exports (redistribution) to bring routes for networks that a router has learned via either direct connection, static configuration, or from other dynamic protocols like EIGRP, OSPF etc. Exporting (redistribution) is likely something you’ll need to do at some point because networks tend to be a mixture of different protocols due to business need, mergers and acquisitions, system administrator design and knowledge or just plain old organic growth.