Table of Contents
- Purpose
- Import/Export policy vs Redistribution policy in FlexVNF
- Redistribution scenarios on FlexVNF
- Case1: Redistribution of Static/OSPF/BGP routes into SDWAN.
- Case2: Redistribution of Direct/Static/BGP(SDWAN) routes into LAN-side BGP
2.1: Rejecting Redistributed Routes Through Export Policy - Case3: Redistribution of Direct/Static/BGP(SDWAN) routes into LAN-side OSPF
3.1: Significance of DN-bit while re-distributing BGP into OSPF
Purpose
The purpose of this document is to illustrate the use of route-redistribution via example scenarios and also demonstrate some aspect of troubleshooting in this regard.
Import/Export policy vs Redistribution policy in FlexVNF
Route redistribution is defined by the action of infiltrating routes from one protocol into another protocol and thus export the same forward. In certain vendors, the import/export policies, defined at group/neighbor level, also include redistribution contexts, however in FlexVNF there is demarcation between the import/export policies and redistribution policies.
In FlexVNF, a redistribution policy has to be defined in order to inject routes from a protocol into another protocol – it cannot be achieved via import/export policy, since there is no provision to define a protocol therein. Here, import/export policy is restricted to routes of the same protocol, whereas re-distribution policy allows you to inject routes from a different protocol.
Redistribution scenarios on FlexVNF
The route types, of concern, while working with redistribution are as below
- Direct (directly connected interfaces, virtual/physical)
- Static
- OSPF
- BGP
Essentially there are 3 redistribution scenarios that may be encountered on FlexVNF in any Tenant LAN VR, in some cases a combination of the three may be involved
Case1: Redistribution of Static/OSPF/BGP routes into SDWAN.
Case2: Redistribution of Direct/Static/BGP(SDWAN) routes into LAN-side BGP
Case3: Redistribution of Direct/Static/BGP(SDWAN) routes into LAN-side OSPF
Along with the above, there is the aspect of re-distributing the Direct/Static, BGP or OSPF routes, that are available in a Tenant LAN VR, into the IBGP towards the controllers as vpn4 routes, which allows them to be learnt by the other branches.
The policy to perform the above redistribution is present by default in the LAN VR as explained below
Case1: Redistribution of Static/OSPF/BGP routes into SDWAN.
There is a default redistribution policy on FlexVNF under every Tenant’s LAN VR for the purpose of advertising the “Direct” routes (the LAN interface and any virtual-interface defined in the VR), and BGP routes learnt from any LAN-side BGP session, into the IBGP towards the controllers (in the respective Tenant Control VR) which are further advertised as vpn4-inet routes.
Below a screen-shot of the Director’s GUI showing the default re-distribution policy present in the Tenant LAN VR. There are three terms defined in the policy of a brach of type "full mesh" (Note - There are just two terms T1-xx and T2-xx by default on a hub-spoke setup, you would have to add a term to re-distribute BGP routes, learnt from sd-wan, into LAN-side or DIA BGP sessions in LAN-VR )
For example:
Consider the below output from the LAN-VR, which shows 20.1.1.0/24 as a directly connected subnet
The above route gets advertised on the IBGP session towards the controllers owing to the default redistribution policy shown below
As seen below, the directly connected subnet is advertised as a vpn-v4 route with appropriate extended community (Route Target)
If you want to advertise a "static route", in your LAN VR, as a sd-wan route (as a vpn-v4 route towards the controllers so that it's received by the other branches), you can add a new term as below.
Note: the same redistribution rule is applicable to the LAN-side BGP, and any other BGP session, in the LAN VR. So, please ensure that you make use of export policies to reject this route, in the respective BGP configuration, if you don't want this route advertised towards a certain peer (check out the section on "rejecting redistributed routes through export policy" further down in this document)
Set the action as allow for this term, as shown below
Case2: Redistribution of Direct/Static/BGP(SDWAN) routes into LAN-side BGP
The examples illustrated below are equally applicable to WAN-side BGP (in case of a WAN breakout)
The presence of the default bgp redistribution policy, explained in the section above, ensures that all the directly connected subnets, will be advertised towards the LAN-side BGP. Also, the BGP learnt routes (the vpn-v4 routes learnt via IBGP towards the controllers as well as the ipv4 routes learnt from other BGP sessions configured in the LAN-VR), will be advertised towards the LAN-side BGP owing to the default protocol behaviour of BGP.
Consider the below LAN-side BGP configuration in the Tenant LAN VR
Below are the routes present in the LAN-VR
You can see a default route (0.0.0.0/0) learnt from an IBGP session towards a paired TVI (another VR) and a couple of directly connected subnets. These routes get advertised to the LAN-side BGP session owing to the redistribution policy (along with the default behaviour of BGP protocol) – however the static route 39.10.1.0/24 is not advertised
In order to re-distribute static routes into BGP, a new term will need to be appended in the default re-distribution policy as seen below
Post the addition of the above term to the redistribution policy, you can see that the static route is now being advertised
2.1: Rejecting Redistributed Routes Through Export Policy
Considering that the redistribution policy, for BGP, applies to all the BGP sessions (like the wan-side BGP, lan-side BGP and pairer-tvi/split-tunnel BGP), there may be a need to reject/filter-out certain routes on certain sessions.
You can accomplish the above using export policies.
For example,
Case 1:
If you want to reject the static route 39.10.1.0/24 (which was re-distributed) while advertising towards the LAN-side BGP, you can define an export policy and reject the specific prefix as below
Firstly, you need to create a prefix-list with an entry for prefix 39.10.1.0/24 (action as permit here)
Secondly, create an export policy with a term (Term-1) matching the above prefix list with “action” as Reject. Also, add another term (Allow-All) without any match criteria and action as allow
The above policy should then be enforced as the export policy for the respective LAN side BGP session
With the application of the above export policy the static route stops being advertised as seen below
Case3: Redistribution of Direct/Static/BGP(SDWAN) routes into LAN-side OSPF
For the purpose of illustration, consider the below ospf session under the LAN VR. Similar configuration is also valid on re-distribution towards WAN-side OSPF.
The routes present in this LAN-VR are as below
You can see a route learnt from BGP the subnet 27.1.1.0/24. The OSPF external database is as below, you can see that the bgp route is not present in the ospf database, because there is no such redistribution policy by default
Create a redistribution policy to allow BGP routes and apply this policy in the OSPF context as below. You can replace the protocol field with “Static” or “Direct”, depending on the protocol you wish to re-distribute into OSPF.
Post the application of this redistribution policy, the bgp routes is injected into the ospf database as an external route
Also, by default the external route type is E2, which can be changed as below. There can also be a need to change the metric of the route so that the an already existing route learnt from the LAN-side OSPF is preferred - for Example, here we are change the metric to 10000, so if there is an existing external route (for the same prefix), learnt from LAN-side OSPF, with a metric <10000, it would be preferred instead of the re-distributed route.
3.1: Significance of DN-bit while re-distributing BGP into OSPF
While redistributing BGP routes into OSPF, make sure you have a domain-tag configured in the ospf context especially in a design scenario involving HA (active-active) setup with another branch (which may end up re-advertising these external ospf back to bgp).
Note: we need to explicitly add a "domain-tag" in 16.1R2 in order enable the setting of DN bit while redistributing from BGP to lan-side OSPF (and configure the same domain-tag on the other end branch). In 16.1R1, the DN-bit was set by default, during redistribution from BGP to lan-side OSPF, without the need for domain-tag configuration.
When a domain-tag is configured, the DN-bit is set when BGP is re-distributed into OSPF, as seen below (DN is set, under Options). OSPF routes with DN-bit set will not be installed in VR of the branch at the other end (the same domain tag should be configured on the other branch also)
