a couple of comments below. may get longish as I just put together a Q&D lab, and the outputs may bog this down.
""bergenpeak"" wrote in message news:200210121501.PAA05804@;groupstudy.com... > Hi JFD, > > Thanks for the response, but it doesn't answer the question. Is there > something > about redistributing from RIP into OSPF where it is *necessary* for one > to provide > a metric on the redistribute command? CL: not that I have ever known. under the OSPF process, the simple comand "redistribute rip" is all you need. Observe: Router_1(config-router)#redist rip ? metric Metric for redistributed routes metric-type OSPF/IS-IS exterior metric type for redistributed routes route-map Route map reference subnets Consider subnets for redistribution into OSPF tag Set tag for routes redistributed into OSPF Router_1(config-router)#redist rip % Only classful networks will be redistributed Router_1(config-router)# And in my OSPF domain: Router_6#ir Gateway of last resort is not set S 172.31.0.0/16 is directly connected, TokenRing0 O E2 192.168.55.0/24 [110/20] via 192.168.100.5, 00:00:24, TokenRing0 O E2 192.168.54.0/24 [110/20] via 192.168.100.5, 00:00:24, TokenRing0 O E2 192.168.5.0/24 [110/20] via 192.168.100.5, 00:00:24, TokenRing0 C 192.168.6.0/24 is directly connected, Loopback0 O E2 192.168.53.0/24 [110/20] via 192.168.100.5, 00:00:24, TokenRing0 O IA 192.168.7.0/24 [110/26] via 192.168.100.7, 00:00:24, TokenRing0 O E2 192.168.52.0/24 [110/20] via 192.168.100.5, 00:00:25, TokenRing0 O E2 192.168.51.0/24 [110/20] via 192.168.100.5, 00:00:25, TokenRing0 O IA 192.168.1.0/24 [110/26] via 192.168.100.1, 00:00:25, TokenRing0 C 192.168.100.0/24 is directly connected, TokenRing0 Router_6# CL: Notice all the E@ routes - those are the RIP routes that were redistributed into OSPF. When no other switch is specified, the default redistribution is metric type E2 CL: now the only caveat here is that witrhout the "subnets" switch, only classful networks will be redistributed. CL: in the course of this I saw something that I have never considered before. You mention RIP v2. On my RIP router I have the following config: router rip version 2 network 172.16.0.0 network 192.168.5.0 network 192.168.51.0 network 192.168.52.0 network 192.168.53.0 network 192.168.54.0 network 192.168.55.0 network 192.168.100.0 no auto-summary I also have subnets 182,16,1,0, 172.16.2.0, and 172.16.3.0 configured on loopbacks. Notice the "no auto-summary: in place. notice the routing table of an OSPF router: O E2 192.168.55.0/24 [110/20] via 192.168.100.5, 00:02:40, TokenRing0 O E2 192.168.54.0/24 [110/20] via 192.168.100.5, 00:02:40, TokenRing0 O E2 192.168.5.0/24 [110/20] via 192.168.100.5, 00:02:40, TokenRing0 O IA 192.168.6.0/24 [110/26] via 192.168.100.6, 00:02:40, TokenRing0 O E2 192.168.53.0/24 [110/20] via 192.168.100.5, 00:02:40, TokenRing0 C 192.168.7.0/24 is directly connected, Loopback0 O E2 192.168.52.0/24 [110/20] via 192.168.100.5, 00:02:40, TokenRing0 O E2 192.168.51.0/24 [110/20] via 192.168.100.5, 00:02:41, TokenRing0 O IA 192.168.1.0/24 [110/26] via 192.168.100.1, 00:02:42, TokenRing0 C 192.168.100.0/24 is directly connected, TokenRing0 Router_7# CL: so where is the 172.16.0.0 network? But when I remove the "no auto-summary" from the RIP process: Gateway of last resort is not set O E2 172.16.0.0/16 [110/20] via 192.168.100.5, 00:00:05, TokenRing0 O E2 192.168.55.0/24 [110/20] via 192.168.100.5, 00:03:57, TokenRing0 O E2 192.168.54.0/24 [110/20] via 192.168.100.5, 00:03:57, TokenRing0 Now the 172.16.0.0 network is there. CL: aaahhhhhh........... so there is some other kink in the wire......... CL: this brings us to the "subnets" switch. Router_1(config)#router ospf 1567 Router_1(config-router)#redist rip subnets Router_1(config-router)#^Z Router_6#ir 172.16.0.0/24 is subnetted, 3 subnets O E2 172.16.1.0 [110/20] via 192.168.100.5, 00:00:23, TokenRing0 O E2 172.16.2.0 [110/20] via 192.168.100.5, 00:00:23, TokenRing0 O E2 172.16.3.0 [110/20] via 192.168.100.5, 00:00:23, TokenRing0 O E2 192.168.55.0/24 [110/20] via 192.168.100.5, 00:01:47, TokenRing0 O E2 I agree from a BCP perspective > it is wise > to explicitly list the metric, but want to understand if there is some > low-level > protocol issue where it's not possible for the IOS to provide and use a > default metric > when one is not provided via the redist command. CL: again, so far as I know, it is unnecessary to explicitly define metrics when redistributing RIP into OSPF or visa versa. It IS necessary to provide metrics when redistributing anything into EIGRP or IGRP. The two Cisco proprietary protocols are the only ones that require a metric configuration when distributing into them, based on any practice I have done. > > This is both a theory of protocols / routing and a practical question. > > In a real live network, we had an issue where a router was configured > with a > redist of RIP routes into OSPF. The RIP routes where not being > redistributed > by OSPF. (I don't know if the routes never got advertised or if they > where being > advertised and then the advertisements stopped at some point in time.) > Cisco was > called in to look at the problem and reported the problem was because > the redist > was missing the "metric XYZ" command. CL: which means that the particular Cisco engineer was uninformed, as demonstrated above. It is best practice to provide metrics, but it is NOT required. > > I don't buy that the "metric XYZ" is in fact necessary. In the testing > I've done, > the redist works without the metric and in fact supplies a default > metric when a metric > is not provided. This would seem to indicate the metric value is in > fact not needed > in order for the redist to work correctly. > > I expect this was a bug in the IOS we were running and the response that > the "metric XYZ" > was required was provided as a work around to the bug, but cast as > necessary for the > protocols to work properly. CL: I'm just wondering about the "subnets" switch. You mentioned RIP v2, but said nothing about your subnet structure. Nor did you mention the status of auto summarization. CL: as to the speculation that the resdistribute rip metric xyz might have been a bug workaround, many things are possible. However, I'm wondering if the real fix wasn't the addition of the "subnets" switch while fooling around with the "redistribute rip metric xyz" configurations? > > But trying to unwrap this onion a bit more... > > Thanks > > > > > > > > > > > > Jean-Francois Delrieu wrote: > > > > Bergenpeak, > > > > You should always use default metrics before redistributing or specify a > > metric when reditributing specific routes. > > This is valid for any protocol redistribution in a lab or in prod. > > You will avoid a lot of problems. > > > > JFD Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=55464&t=55364 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
