OSPF Outbound routes filtering

[adel.dardari]

Hi All,

i was looking for a scipt to filter OSPF Outbound routes between two different area's.

I have a L3 switch connected to 2 x SDWAN devices. OSPF is running between an SDWAN Device and L3 Switch. The SDWAN Devices got IBGP and they are in HA mode. The SDWAN learns routes from the uplinks/WAN and reditribute learned routes into OSPF. Each SDWAN got an OSPF Session with the L3 switch with different area ( area 0 for primary SDWAN and area 1 for secondary SDWAN)

All i need is to get the L3 switch to keep on learning routes via OSPF, but not to re-advertise them into the 2nd device to avoid loops. can you please 

[Giuseppe Larosa]

Hello @adel.dardari ,

OSPF external routes cannot be filtered at area boundary. Internal OSPF routes can using the area filter-list command that uses a prefix-list.

>> and reditribute learned routes into OSPF.

So the routes are external and you cannot filter them.

However, you can use two NSSA areas to make the joke working: NSSA area 1 for primary SDWAN and NSSA area 2 for the secondary SDWAN. Please note that the L3 switch still need to have a connection to area 0 to work correctly as ABR.

Hope to help

Giuseppe

[adel.dardari]

Hi Giuseppe,

can you elaborate further ? I have attached a diagram. Also, can i use area 0 for the primary connection (first NSSA) ? 

if you have time, can you share the commands i should use please

[Giuseppe Larosa]

Hello @adel.dardari ,

area 0 cannot be made NSSA, area 0 is the backbone area in OSPF.

to create an NSSA area all you need in all routers belonging to the area is to use

router ospf 10

area 1 nssa

In this way all devices will set the NSSA flag in router hellos and in router LSA.

In addition the SDMWAN device primary will generate an O N2 route using an LSA type 7 instead of an LSA type 5.

The L3 switch acting as ABR is in charge to translate the LSA type 7 to LSA type5 to area 0.

What is really important is that external routes coming from area 0 are not permitted to enter a NSSA area and this performs the filtering you would like to achieve.

In order to make the SDWAN primary preferred this device has to redistribute using a lower seed metric when compared to the seed metric used by SDWAN secondary in NSSA area 2.

By using two NSSA areas you are sure that each SDWAN device does not receive the LSA generated by the other device and this should satisfy your requirement.

Hope to help

Giuseppe

[adel.dardari]

Hi @Giuseppe Larosa 

let's say that i will configure

: primary SW-SD1 OSPF as Area 1 

: Secondary SW-SD2 OSPF as Area 2

L3 Switch will be ASBR with Area 0

my questions:

* when configuring Area 1 as NSSA, do i only have to do the command on the switch side ? I am not sure that i can do any OSPF specific config from the SDWAN side. How can i determin that the SDWAN is going to use LSA7 instead of LSA5 

* next, on the switch ( area 0) , i don't have to do any configs right ? i mean the switch should be able to translate LSA7 to LSA5 correct ? and block any LSA5 from being redistributed to NSSA. 

side question: can this be done by tagging routes ? i was looking if it is possible to tag the received routes from SD1 and deny them from being redistributed into the SD2. I am not solid with OSPF so i am not sure if this solution is an option (tagging OSPF between different area's )

sorry again, appreciate your help

[Giuseppe Larosa]

Hello @adel.dardari ,

about your questions:

a) also SDWAN1 and SDWAN2 must be configured for being in area 1 nssa and in area 2 nssa respectively. If you simply configure the devices to be in area 1 and in area 2 no OSPF adjacencies can be built for the mismatch on the N NSSA flag with the L3 switch.

b) on the switch you need to configure both area 1 nssa and area 2 nssa but the translation of LSA type 7 to LSA type 5 is performed automatically.

So at the end you need to verify what can be configured on the SDWAN devices at OSPF level before attempting to use this approach.

Hope to help

Giuseppe

[adel.dardari]

Hi Giuseppe,

i have checked, it seems i cannot configure NSSA on the SDWAN however, i can tag the routes when i reditribute them into OSPF. 

i was reading and trying to come up with a something but i need some expert to help me complete the command;

Assuming the switch local subnet is 172.20.20.0/24 and the redistributed routes from SDWAN to OSPF wil be tagged with 22 

ip prefix-list AREA_1_OUT seq 10 permit 172.20.20.0/24 ==>to allow advertising the local subnet out to area 1 ( SDWAN1)
ip prefix-list AREA_2_OUT seq 10 permit 172.20.20.0/24 ==>to allow advertising the local subnet out to area 2 ( SDWAN2)

Router(config)# router ospf 1
log-adjacency-changes
area 1 filter-list prefix AREA_1_OUT out ==> advertise LSA3 for specific prefix out to Area 1
area 2 filter-list prefix AREA_2_OUT out ==> advertise LSA3 for specific prefix out at Area 2

network 10.0.0.0 0.255.255.255 area 2
network 172.16.1.0 0.0.0.255 area 0
network 192.168.0.0 0.255.255.255 area 1

!
Route-map denytaggedroutes deny 10
match tag 22

i am only missing one command which in theory should reditribute learned routes from area 1 to area 2 and deny the routes tagged 22 from being redistributed , so deny all tagged routes 

[paul driver]

Hello
You could just advertise default routes into the ospf domain from both of your sdwan rtrs, The l3 switch will prefer the area0  default route and advertise just locally originated routes from the L3 switch

[adel.dardari]

The problem is that i don't want the switch to use the learned routes (learned from SDWAN1) and re-distribute them to the 2nd SDWAN device because it will cause a loop

[paul driver]

Hello

---

@adel.dardari wrote:
The problem is that i don't want the switch to use the learned routes (learned from SDWAN1) and re-distribute them to the 2nd SDWAN device because it will cause a loop

---

You shouldn’t have to, the idea would be to advertise two tagged conditional default-routes to your Lan core from either SDWAN rtr with the condition based on a prefix advertised from either ISP as such if that prefix fails to be advertised then the condition would fail and the preferred ospf default (metric-type 1) would be removed and the less preferred ospf default (metric-type 2) would be injected into Lan core

As for you’re lan subnets these will be only the prefixes advertised into ospf from the lan core  towards the SDWAN rtrs which will inturn redistribute ospf into  bgp.

Doing something like this would mean you wouldn’t incur any route-feedback and you woulnt need to change any opsf areas.

Example:

SDWAN rtr1
ip prefix-list bgp-route permit y.y.y.x/24 <--- bgp route from bgp SDWAN 1
route-map default
match ip address prefix-list bgp-route
match source-protocol bgp xx
set tag xx

router ospf x
default-information originate metric-type 1 route-map default

SDWAN rtr2
ip prefix-list bgp-route permit x.x.x.y/24 <-- bgp route from bgp SDWAN 2

route-map default
match ip address prefix-list bgp-route
match source-protocol bgp xx
set tag xx

router ospf x
default-information originate route-map default

[Richard Burts]

There are many things we don't know about this environment and that impacts our ability to provide good suggestions. What we do know is that 2 SDWAN devices connect to a L3 switch. Each SDWAN device learns external routes and advertises those routes to the switch. You want to prevent the switch advertising external routes from one SDWAN to the other SDWAN. 

If the routing protocol is OSPF the options are limited. It seems to me that the optimum solution is each SDWAN in its own NSSA area. That automatically achieves your objective. I acknowledge your comment that this is problematic. I don't have experience with SDWAN devices and so can't be authoritative. But I am surprised that a device that supports OSPF doesn't support NSSA. 

[adel.dardari]

---

@Richard Burts wrote:

There are many things we don't know about this environment and that impacts our ability to provide good suggestions. What we do know is that 2 SDWAN devices connect to a L3 switch. Each SDWAN device learns external routes and advertises those routes to the switch. You want to prevent the switch advertising external routes from one SDWAN to the other SDWAN. 

If the routing protocol is OSPF the options are limited. It seems to me that the optimum solution is each SDWAN in its own NSSA area. That automatically achieves your objective. I acknowledge your comment that this is problematic. I don't have experience with SDWAN devices and so can't be authoritative. But I am surprised that a device that supports OSPF doesn't support NSSA. 

---

a collegue told me the following worked for him although they are not LSA3 

switch configuration:

Router ospf 1

Log-adjacency-changes

Area 1 filter-list prefix PermitLocalSubnets out

Area 2 filter-list prefix PermitLocalSubnets out

Network x.x.x.x 0.0.0.x area 1

Network x.x.x.x 0.0.0.x area 2

Just create an ACL/prefix list for your LAN resources. we will test it by the weekend and see if it works. 

If it doesn't work, i will get the SDWAN devices to tag redistributed routes and filter them out. So all routes that gets redistributed from BGP/overlay..etc to OSPF will get a tag 11

on the switch, i will run something like this:

Route-map denytaggedroutes deny 10

Match tag 11

router ospf 1

Area 10 filter-list route-map denytaggedroutes out

Area 11 filter-list route-map denytaggedroutes out

Network x.x.x.x 0.0.0.x area 10

Network x.x.x.x 0.0.0.x area 11

Network x.x.x.x 0.0.0.x area 0

do you think it will work?

[Giuseppe Larosa]

Hello @adel.dardari ,

you cannot use the area filter-list command to filter external routes in OSPF at least in Cisco implementation. But I think in OSPF in general. This is because OSPF route filtering cannot operate on OSPF LSA flooding directly but only on points of generation of the different types of LSA ( ABR for filtering internal routes, ASBR for filtering external routes).

In MPLS L3 VPN the PE nodes can send O IA routes instead of O Ex  when performing the emulation of a superbackbone area, but you have SDWAN.

If NSSA areas are not supported on the SDWAN devices you should use two different OSPF processes on the L3 switch and you would not redistribute between the two processes.

In this way you can achieve the isolation even if NSSA area not supported.

You need a trick however to be able to advertise internal subnets (the LAN) in both processes to make this work you need to use two different area-ids in order to be able to run two OSPF processes on the same interface.

You cannot use the same area or you can end up with breaking the connectivity. The reason is that in OSPFv2 the OSPF process-id is not sent in OSPF hellos so it would not be possible for the device to correctly process received Hellos.

I am doing this suggestion for a scenario where there are no downstream OSPF neighbors connected to the L3 switch as in your network diagram.

If there are devices downstream the L3 switch in the local site things became much more complex and the trick of using two different OSPF processes with different areas might not work (the same trick would need to be extended to those downstream devices).

I would verify if the NSSA area are supported on the SDWAN devices with their vendor as NSSA area is part of OSPFv2 specification.

Hope to help

Giuseppe

[adel.dardari]

Hi Paul,
by doing this, we are only changing the OSPF route table ( prefferred route) , but the LADP on the switch level will still learn about these routes and inform the other SDWAN device about them , correct ?

[paul driver]

Hello

---

@adel.dardari wrote:
Hi Paul,
by doing this, we are only changing the OSPF route table ( prefferred route) ,

---

Yes you are, via metric-type of the advertised defaults.

---

@adel.dardari wrote:
, but the LADP on the switch level will still learn about these routes and inform the other SDWAN device about them , correct ?

---

If you mean your local subnets being advertised towards the SDWAN rtrs then yes they will however this is all based on that diagram you previously posted so I wouldn’t like you to just go away and implement what I or others on this post have suggested, I would say a more indepth topology review of your current network would be required before any implementation change.