cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1397
Views
15
Helpful
8
Replies

Static routes problem.

Carlos de Armas
Level 1
Level 1
Hello everybody,
 
 
I have the following problem.
 
 
I was asked to filter routes from getting into the rip updates.
 
The routes are static routes so its distance is 1 and its metric is 0.
 
Knowing this the router learn the static route like connected and adds it in the routing table.
 
The company also needs to have a solution that applies to upcoming routes. So a distribute list solution isn´t possible.
 
Is there any way to avoid static routes becoming connected?
 
Example:
 
 
 
R1                  R2
tunnel 0------\ tunnel
tunnel 1------/
 
static route
 
ip route 10.40.77.99 255.255.255.255 Tunnel0
 
Router output:
 
S       10.40.77.99/32 is directly connected, Tunnel0
 
show ip route 10.40.77.99
Routing entry for 10.40.77.99/32
  Known via "static", distance 1, metric 0 (connected)
  Redistributing via rip
  Advertised by rip
  Routing Descriptor Blocks:
  * directly connected, via Tunnel0
      Route metric is 0, traffic share count is 1
 
 
If i use the "redistribute static metric 16" i can filter this route in one tunnel. But the router keeps learning the route because it knows it as static,connected and tunnel 1 will be sending the updated from its interface.
 
Thanks to anyone in advanced.
 
Best regards
Carlos
1 Accepted Solution

Accepted Solutions

Okay, that make sense, thought I had forgotten how RIP worked for a minute there :-)

I suspect you are right in that regardless of how you modify the route with your redistribute static RIP will see that as a connected route and simply advertise it out.

If I get the chance I'll have a look at in a lab today but I am not too hopeful.

I appreciate you have probably considered this and it may very well not be possible but have you though about using EIGRP instead.

It's more efficient in terms of routing updates etc, is the recommended protocol for DMVPN and more importantly for you is classless so it would mean that the route did not overlap with other spoke networks.

Jon

View solution in original post

8 Replies 8

Jon Marshall
Hall of Fame
Hall of Fame

Carlos

Is there any way to avoid static routes becoming connected?

The general answer to this is yes, use a next hop IP instead of an interface.

But I'm not sure that would fix your problem.

If your RIP configuration includes network 10.0.0.0 then it is going to pick it up anyway with your redistribute static command.

You may be able to use a route map with your redistribution to filter out the routes you don't want.

Can you clarify what it is you are trying to do and why the company needs it.

Jon

Jon

Thanks for your answer

My bad. Sorry let me try to explain better.

The routing protocol we are using is rip and the main idea is to avoid that the new technicians from making the mistake of using the interface as next hop. 

The redistribute static metric 16 wouldn´t redistribute the routes because it will recognize them as unreachable but it isn´t a solution since the router learns the route as connected/static and we have 2 tunnel interfaces pointing to the same next hop/router.

With the redistribute static metric 16 i´m filtering the redistribution of static routes including the one that has the interface as next hop but the router is also learning the route as conected so is redistributing the route as connected from the other tunnel

sorry if i cant explain it so well, english is not my main lenguage

Regards and thanks for taking your time to answer!

Carlos

No problem and believe me your English is a lot better than my ability to speak any other language :-)

You seem to be saying that you can stop it being redistributed by adding a metric but that because it is connected it is still being redistributed which I'm not quite following.

Could you perhaps give me an example from your network ie. the router configs regarding the tunnel and the RIP config and explain exactly what happens.

Jon

Jon

Thanks for your patience!

Here is the exact situation:

Normal scenario:
 
R1-Spoke-1
Vlan1
ip address v.v.v.v
!
tunnel 0
ip address t.t.t.t
!
Tunnel 1
ip address t.t.t.t
!
Router rip
version 2
no auto-summary
network v.v.v.v
network t.t.t.t
 
R2-Spoke-2
Vlan1
ip address b.b.b.b
!
tunnel 0
ip address t.t.t.t
!
Tunnel 1
ip address t.t.t.t
!
Router rip
version 2
no auto-summary
network b.b.b.b
network t.t.t.t
 
R3-Hub Dmvpn.
Destination of all the tunnel interfaces. Also runs rip.
 
R1-Spoke-1
 
Tunnel 0 =================================\
sends rip updates of the connected routes                   \
                                                                                       \ 
Tunnel 1 ================================      \
sends rip updates of the connected routes                      \
                                                                                          \
R2-Spoke-2                                                                        ==== R3-Hub Dmvpn receives the desired config.
                                                                                          /
Tunnel 0 =================================    /
sends rip updates of the connected routes                   /
                                                                                     /
Tunnel 1 ================================ /
sends rip updates of the connected routes/
 
--------------------------------------------------------------------------------
 
Wrong scenario:
 
R1-Spoke-1
Vlan1
ip address v.v.v.v
!
tunnel 0
ip address t.t.t.t
!
Tunnel 1
ip address t.t.t.t
!
Router rip
version 2
no auto-summary
network v.v.v.v
network t.t.t.t
 
ip route b.b.b.b 255.255.255.255 Tunnel 0 
* this route makes the R3 to start learning that the network b.b.b.b is reachable from R1 tunn 1 and R2 tunn 0 and 1 and thats is a chaotic situation.
 
R2-Spoke-2
Vlan1
ip address b.b.b.b
!
tunnel 0
ip address t.t.t.t
!
Tunnel 1
ip address t.t.t.t
!
Router rip
version 2
no auto-summary
network b.b.b.b
network t.t.t.t
 
R3-Hub Dmvpn.
Destination of all the tunnel interfaces. Also runs rip.
 
R1-Spoke-1
 
Tunnel 0 =================================\
sends rip updates of the connected routes                   \
doesnt redistribute the statics since there                      \
isnt any redistribution                                                       \  
                                                                                          \
Tunnel 1 ================================         \
sends rip updates of the connected routes                          \
start sending the new connected network b.b.b.b                 \
learned from the static route.                                                  \
                                                                                                 \
R2-Spoke-2                                                                                 ==== R3-Hub Dmvpn receives the desired config. plus the extra from R1 tunn 1
                                                                                              /
Tunnel 0 =================================        /
sends rip updates of the connected routes                        /
                                                                                          /
Tunnel 1 ================================      /
sends rip updates of the connected routes                   /
 
The redistribute static metric 16 command was my first idea. its not part of the config. (note that it isnt a valid solution)
 
Distribute-list isnt a valid solution either because we have 600+ spoke routers and it will be a pain to configure. its possible anyways.. but is the las desirable option.
 
The wrong scenario is the one that the company wants me to prevent. I dont think its possible since the command is doing what is supouse to do.. but then, i want to discard any possiblityes here

Carlos

Thanks for the detailed explanation.

One more clarification. In the second scenario where the static route via the tunnel is added to R1 are you saying RIP automatically redistributes this ?

I ask because the RIP configuration on R1 has no network statement for that network and there is no "redistribute static" under your RIP configuration so I'm not sure why it is being passed to R3 ?

Or because RIP is classful is the b.b.b.b network part of the t.t.t.t or v.v.v.v networks ?

Jon

Jon, thats correct.

I missed that part when writing the explanation.

The b.b.b.b network is of the v.v.v.v network.

And its being redistributed because of the "interface" on the static route that learns the static route as connected

Okay, that make sense, thought I had forgotten how RIP worked for a minute there :-)

I suspect you are right in that regardless of how you modify the route with your redistribute static RIP will see that as a connected route and simply advertise it out.

If I get the chance I'll have a look at in a lab today but I am not too hopeful.

I appreciate you have probably considered this and it may very well not be possible but have you though about using EIGRP instead.

It's more efficient in terms of routing updates etc, is the recommended protocol for DMVPN and more importantly for you is classless so it would mean that the route did not overlap with other spoke networks.

Jon

Dont worry Jon, if you want to do it, it would be a fun lab to do i guess! Running Eigrp is not possible sadly because the whole network (the 600+ nodes) are low end routers that only support rip. Im stuck with rip..

Thanks again for your time!

Regards

Carlos

Review Cisco Networking for a $25 gift card