cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1088
Views
20
Helpful
7
Replies

OSPF "distribute-list" not working on Cisco IOS XE SDWAN

JohnG2020
Level 1
Level 1

Hello, I cannot use the distribute-list option available in the Cisco IOS XE SDWAN.

Can someone please help me with the syntax? I want to filter using a local route policy to deny OSPF external routes tagged with 999. These routes are tagged 999 from the 2nd SDWAN router when they get redistributed into OSPF from OMP. This is to ensure routes that are learned from SDWAN router 2 are not accidentally sent back out SDWAN router 1 if the WAN ever goes down and the OSPF external routes are installed in the local routing table. 

Hardware: ASR1002-HX
Version 17.3.4a
Mode: Controller 

ASR1002-HX(config-router)# distribute-list in ?
Possible completions:
<interface:string> <cr>

 

 

 

 

7 Replies 7

distribute-list [<access-list #> | <access-list name>] |
{prefix <name1> gateway <name2>} |
{prefix <name1>} | {gateway <name2>} |
{route-map name} in [<interface>]

can you check this command ref. 
I think you need to add ACL or Prefix number before IN 

Hello,

the syntax should, in theory, be like this:

route-map RM_TAG_999 deny 10
match tag 999
!
router ospf 1
distribute-list route-map RM_TAG_999 in

Even if the syntax gets worked out I do not think that the OSPF distribute list will achieve what the original poster wants. I am focusing on this part of the post: "This is to ensure routes that are learned from SDWAN router 2 are not accidentally sent back out SDWAN router 1".

The important point here is that the distribute list in OSPF only impacts what routes go into the local routing table. Any prefix/LSA received from a neighbor still goes into the link state database and will be advertised, even if the distribute list has prevented it from being in the local routing table.

The distribute list in approach does work with EIGRP or with RIP but is significantly different with OSPF.

HTH

Rick

@Richard Burts  @Georg Pauwen 
Mr.Richard mention that the OSPF not effect the OSPF DB but it effect the route it appear in RIB, 
that totally right BUT 
I test for BGP 
when we redistribute OSPF into BGP, the BGP check the RIB before advertise to other neighbor
and hence the distribute-list still effect the route redistribute from OSPF into BGP 

LAB below 
two LO and I deny 11.11.11.11/32 in distribute-list and R2 not advertise 11.11.11.11/32 to R3. 

just want to clear this point to My Friends.

gfhhghghghghghg.png

Hello
You don’t mention from what routing process the routes are getting redistributed , For example by default when BGP is redistributed into an IGP such as OSPF then by default the original BGP ASN of the route is set to a OSPF route tag. if these routes are readvertised back into bgp that tag is lost along with its origin.

To negate that you could from the sdwan rtr append automatic tag via a table-map so the original as-path number and origin of the bgp route is attached upon re-redistribution into bgp.

route-map TAG
set automatic-tag

router bgp xx
table-map TAG filter


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Thanks, everyone for the response. 

After further testing, the SDWAN IOS XE running OSPF has a built-in loop protection mechanism when redistributing OMP into it. OSPF is automatically setting the DN bit to avoid the O E2 routes from being re-advertised back out. The admin distance gets set to 252 which is higher than the OMP 251. Normal O E2 routes coming from a down-streem device are not set with the DN bit. This will continue to be advertised in OMP. 

https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/215029-cisco-ios-xe-sd-wan-installs-ospf-exter.html

With this being the default behavior, I don't need to run the distribute-list on my edge SDWAN routers for OSPF. The command is not working even trying the appropriate syntax. I suspect it's not a qualified command when it is in controller mode.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/iosxe/qualified-cli-command-reference-guide/m-ospf-commands.html

 

 

 

 

Thanks for the update. It is an interesting suggestion that being in controller mode might impact validity of the command.

HTH

Rick
Review Cisco Networking for a $25 gift card