cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
512
Views
25
Helpful
7
Replies
npt
Beginner
Beginner

OSPF Routes don't take priority over Static Null Routes ASR1006

On an ASR1006 router we have an upstream ISP connected to a 10 Gbit Port using eBGP.  On other ports we connect to other routers running OSPF.  All routing is IPv4.  

 

The problem I am running into is that because most of our network space is divided on the OSPF network we have to use Null routes.  I.E. "ip route 1.1.1.0 255.255.255.0 null0" in order to make sure the broken up /24 is advertised to our upstream ISP via eBGP.  The problem is that one of our /24 networks is not broken up in OSPF and appears in OSPF as a /24 and this is identical to the null0 static route.  It seems that the null route is taking priority, if I leave a null route on the router for the /24 that is in the OSPF routing table across my network as a /24 the route only shows up in a show ip route as a null route and all traffic is discarded to that /24 and does not show up with the real route obtained via OSPF.  If I remove the null route the OSPF route will take over and be advertised to my upstream ISP.  What do you think.  Is this expected behavior?  Should I increase the metric for my null routes?  Would that help.  Here is an example of a route with or without OSPF (IP's changes for security)

 

Without null route (OSPF)

ASR-1006#show ip route 1.1.1.0 Routing entry for 1.1.1.0/26 Known via "ospf 1", distance 110, metric 42, type inter area Last update from *.*.*.* on TenGigabitEthernet0/3/0, 1d01h ago Routing Descriptor Blocks: *.*.*.*, from *.*.*.*, 1d01h ago, via TenGigabitEthernet0/3/0 Route metric is 42, traffic share count is 1

 

With null route

ASR-1006-1#show ip route 1.1.1.0 Routing entry for 1.1.1.0/24 Known via "static", distance 1, metric 0 (connected) Advertised by bgp ***** Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1

 

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Meheretab Mengistu
Rising star

It looks like the two routes are a little bit different: 1.1.1.0/26 via OSPF and 1.1.1.0/24 via Static; in that case, it should not impact routing. However, if both are 1.1.1.0/24 (the same route), you will need to change the AD (Administrative Distance) of the static route. 

Eg. ip route 1.1.1.0 255.255.255.0 null0 254

 

HTH,
Meheretab

View solution in original post

7 REPLIES 7
Meheretab Mengistu
Rising star

It looks like the two routes are a little bit different: 1.1.1.0/26 via OSPF and 1.1.1.0/24 via Static; in that case, it should not impact routing. However, if both are 1.1.1.0/24 (the same route), you will need to change the AD (Administrative Distance) of the static route. 

Eg. ip route 1.1.1.0 255.255.255.0 null0 254

 

HTH,
Meheretab

View solution in original post

Yes they are both the same route.  The strange thing is that this seems to only be affecting one /24 and not the dozen+ other /24's we have, my thought is that it is likely that is because all the other /24's are broken into smaller /30's, /27's, /29's etc. and they have a better route.  

 

For best practice would it be good to set all our /24's we are advertising via BGP to a null0 static route with an AD of 254?  

 

The main purpose of adding the /24 routes here is for summary advertisement through BGP. I would configure all those /24 routes to null0 with higher distance (I personally prefer 254 - the lowest possible distance) so that, in case, the same exact route learned through another protocol, that will be used for routing purpose, instead of discarding the traffic.

HTH,
Meheretab
MHM Cisco World
Rising star

R1-R2

1-many route in R1 we will summary it to specific route for example 192.168.1.x,y,z,n,m will be summary into 192.168.1.0. we will advertise this into R2.
2-Now if any packet destination to the 192.168.1x,y,z,n,m R2 will forward to R1 
Issue Here 
if there is default route in R1 toward R2
if the packet forward from R2 to R1 with 192.168.1.Q, R1 don't have any idea about this Q and because there is default it will return into R2 and R2 will do this again and reforward into R1.

how we can solve this by config static null in R1 for 192.168.1.0/24 this what happened 
R1 if receive the Q packet it check route table and not match it will use static no null instead of default.
this broke the loop.
so my friend I think we don't need to advertise this route (static to null) to other router since it only work in this router and it make issue if advertise to other router.

This router (and other ASR's) are our edge routers and route between BGP (The Internet) and OSPF (Backbone network).  The only reason for the Null Routes for us are to make sure we advertise a /24 or larger to the internet because OSPF is advertising smaller blocks that can't be advertised via BGP to the Internet.  It just seems like the issue with the null routes affects the /24 routes that match exactly in OSPF and Null.  Summary routes are an interesting idea but I'm not sure that's the best idea in this particular case.  The "ip route x.x.x.x 255.255.255.0 254 seems to be working ok for the /24 OSPF route now and I'm considering putting those in for my other networks for additional safety.  I don't see myself redistributing Null Routes beyond the local BGP router (never redistribute into OSPF) so I think we're ok.  

...

Giuseppe Larosa
Hall of Fame Master

Hello @npt ,

the only alternative to static route to null0 is to use bgp aggregate-address command

to be able to advertise the corresponding summary route in eBGP at least one component most specific route must be in the BGP table either via a network command or via redistribute ospf into BGP.

The static route to null0 as suggested should use an high AD at least 210 to be sure that in case of parity of prefix length the dynamic route is used first.

The only difference is that using static to null0 + AD + network in BGP provides an always on prefix in eBGP.

The aggregate-address will disappear if none of its component routes is present in the BGP table.

 

First the most specific route is used then in case of a tie the AD is compared. This is the reason why you had impact only on one prefix all other /24 have OSPF routes that are more specific so they are not black holed .

 

Hope to help

Giuseppe