ClioSport.net

Register a free account today to become a member!
Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

  • When you purchase through links on our site, we may earn an affiliate commission. Read more here.

Redistribute Connected vs Network statements



Donny_Dog

ClioSport Club Member
  Jim's rejects
Can anyone confirm I'm talking sense here? tried google, but nothing seems to tally with the problem I've just fixed and want to make sure I aint talking poo before presenting at our technical meeting.

We have two switches connected together (they're layer 3, with routing capabilities, so just say they are routers).
RIP V2 is used.

Router 1 - has a gigabit interface in network: 192.168.246.0/24
Router 1 - has a gigabit interface in network: 192.168.240.217/30 - this is the connection to router 2

Router 2 - has a gigabit interface in network 192.168.15.0/24
Router 2 - has a gigabit interface in network 192.168.240.218/30 - connection to router 1

What I wanted to do, was advertise the network 192.168.246.0 on router 1, with a higher metric - so that it would only populate the routing table should another lower metric route get removed (we have multiple routes to the 246 subnet).

on Router 1

Router rip
Version2
redistribute connected metric 7
network 192.168.246.0
network 192.168.240.0

When I did a 'show ip route 192.168.246.0' on router 2 - I was seeing the route with a metric of 2. NOT what we want.

I have summarised that: *(this is what i need confirmation on)

By using redistribute connected, we are saying that all interfaces should be redistributed with a metric of 7.
BUT by having the network statement in there, which is telling RIP to run on interfaces that are inside the classful networks listed (246 and 240), the routes from those interfaces will actually use a default metric, ignoring the generic redistribute command.

when i removed the network 192.168.246.0 statement - the route was actually added to the routing table with the correct metric - so the network command must over-ride the redistribute command if it is explicitly specified - you cannot define a metric for the network statements, so they will always use a default metric.

is that right?
 
  BMW335M/Clio200/182
Yes that is right.

The network statement will inject a route with the "seed metric" which is a connected interface with a hop of 1. When the route is advertised to a neighbour the metric will increase to 2.

Route redistribution is an external protocol injection and will not be preferred over network statements within RIP. There are some limitations with RIP. The best solution would be to setup a policy within the redistribution (a route map) to specify prefixes that require redistribution and their associated seed metrics.
 

Donny_Dog

ClioSport Club Member
  Jim's rejects
Yes that is right.

The network statement will inject a route with the "seed metric" which is a connected interface with a hop of 1. When the route is advertised to a neighbour the metric will increase to 2.

Route redistribution is an external protocol injection and will not be preferred over network statements within RIP. There are some limitations with RIP. The best solution would be to setup a policy within the redistribution (a route map) to specify prefixes that require redistribution and their associated seed metrics.

Just seen this Pete, many thanks
 


Top