Should OSPF not deny connected network when redistributing?

Hi,

I thought that OSPF wouldnt not redistributed connected subnets (without redistribute connected), but for some reason thats what im seeing:

R1 <-- 192.168.12.0/24 --> R2 <-- 192.168.24.0/24 --> R4

For some reason, R4 still sees 192.168.12.0/24 as a redistributed RIP network (E2):

O E2 192.168.12.0/24 [110/20] via 192.168.24.2, 00:05:44, Serial0/0

According to the Self-study, it shouldnt, was just wondering if im missing something.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

GT-Rob

what is your ospf config on R2

kpjungle

GT-Rob wrote:

what is your ospf config on R2

router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute rip subnets
network 192.168.24.2 0.0.0.0 area 0

It would seem that if RIP is running on the interface (connected network), it gets redistributed even though its directly connected, contrary to the study guide (Note on Page 404).

tech-airman

kpjungle wrote:

Hi,

I thought that OSPF wouldnt not redistributed connected subnets (without redistribute connected), but for some reason thats what im seeing:

R1 <-- 192.168.12.0/24 --> R2 <-- 192.168.24.0/24 --> R4

For some reason, R4 still sees 192.168.12.0/24 as a redistributed RIP network (E2):

O E2 192.168.12.0/24 [110/20] via 192.168.24.2, 00:05:44, Serial0/0

According to the Self-study, it shouldnt, was just wondering if im missing something.

kpjungle,

Questions:

What is the subnet and subnet mask used in the RIP section of the internetwork?
Which interfaces type and number (e.g. fastethernet 0/0) are connected in the RIP section of the internetwork?
What is the IP address and subnet mask for each of the abovementioned interfaces in the RIP section of the internetwork?

kpjungle

tech-airman wrote:

kpjungle wrote:

Hi,

I thought that OSPF wouldnt not redistributed connected subnets (without redistribute connected), but for some reason thats what im seeing:

R1 <-- 192.168.12.0/24 --> R2 <-- 192.168.24.0/24 --> R4

For some reason, R4 still sees 192.168.12.0/24 as a redistributed RIP network (E2):

O E2 192.168.12.0/24 [110/20] via 192.168.24.2, 00:05:44, Serial0/0

According to the Self-study, it shouldnt, was just wondering if im missing something.

kpjungle,

Questions:
What is the subnet and subnet mask used in the RIP section of the internetwork?

Which interfaces type and number (e.g. fastethernet 0/0) are connected in the RIP section of the internetwork?

What is the IP address and subnet mask for each of the abovementioned interfaces in the RIP section of the internetwork?

On R1, RIP is enabled on Serial0/0 (192.168.12.1), with network of 192.168.12.0, on R2, RIP is enabled on serial 0/0 ((192.168.12.2) connected to R1 ofcourse), with network 192.168.12.0.

All subnets are /24.

On R3, a route of 192.168.12.0 appears as 0 E2, even though its a directly connected network to R2 and should, according to the guide, not be redistributed.

tech-airman

kpjungle wrote:

tech-airman wrote:

kpjungle wrote:

Hi,

I thought that OSPF wouldnt not redistributed connected subnets (without redistribute connected), but for some reason thats what im seeing:

R1 <-- 192.168.12.0/24 --> R2 <-- 192.168.24.0/24 --> R4

For some reason, R4 still sees 192.168.12.0/24 as a redistributed RIP network (E2):

O E2 192.168.12.0/24 [110/20] via 192.168.24.2, 00:05:44, Serial0/0

According to the Self-study, it shouldnt, was just wondering if im missing something.

kpjungle,

Questions:
What is the subnet and subnet mask used in the RIP section of the internetwork?

Which interfaces type and number (e.g. fastethernet 0/0) are connected in the RIP section of the internetwork?

What is the IP address and subnet mask for each of the abovementioned interfaces in the RIP section of the internetwork?

On R1, RIP is enabled on Serial0/0 (192.168.12.1), with network of 192.168.12.0, on R2, RIP is enabled on serial 0/0 ((192.168.12.2) connected to R1 ofcourse), with network 192.168.12.0.

All subnets are /24.

On R3, a route of 192.168.12.0 appears as 0 E2, even though its a directly connected network to R2 and should, according to the guide, not be redistributed.

kpjungle,

On R1, under the router RIP routing protocol, what network statement did you configure?

kpjungle

tech-airman wrote:

kpjungle wrote:

tech-airman wrote:

kpjungle wrote:

Hi,

I thought that OSPF wouldnt not redistributed connected subnets (without redistribute connected), but for some reason thats what im seeing:

R1 <-- 192.168.12.0/24 --> R2 <-- 192.168.24.0/24 --> R4

For some reason, R4 still sees 192.168.12.0/24 as a redistributed RIP network (E2):

O E2 192.168.12.0/24 [110/20] via 192.168.24.2, 00:05:44, Serial0/0

According to the Self-study, it shouldnt, was just wondering if im missing something.

kpjungle,

Questions:
What is the subnet and subnet mask used in the RIP section of the internetwork?

Which interfaces type and number (e.g. fastethernet 0/0) are connected in the RIP section of the internetwork?

What is the IP address and subnet mask for each of the abovementioned interfaces in the RIP section of the internetwork?

On R1, RIP is enabled on Serial0/0 (192.168.12.1), with network of 192.168.12.0, on R2, RIP is enabled on serial 0/0 ((192.168.12.2) connected to R1 ofcourse), with network 192.168.12.0.

All subnets are /24.

On R3, a route of 192.168.12.0 appears as 0 E2, even though its a directly connected network to R2 and should, according to the guide, not be redistributed.

kpjungle,

On R1, under the router RIP routing protocol, what network statement did you configure?

network 192.168.12.0

tech-airman

kpjungle wrote:

tech-airman wrote:

kpjungle wrote:

tech-airman wrote:

kpjungle wrote:

Hi,

I thought that OSPF wouldnt not redistributed connected subnets (without redistribute connected), but for some reason thats what im seeing:

R1 <-- 192.168.12.0/24 --> R2 <-- 192.168.24.0/24 --> R4

For some reason, R4 still sees 192.168.12.0/24 as a redistributed RIP network (E2):

O E2 192.168.12.0/24 [110/20] via 192.168.24.2, 00:05:44, Serial0/0

According to the Self-study, it shouldnt, was just wondering if im missing something.

kpjungle,

Questions:
What is the subnet and subnet mask used in the RIP section of the internetwork?

Which interfaces type and number (e.g. fastethernet 0/0) are connected in the RIP section of the internetwork?

What is the IP address and subnet mask for each of the abovementioned interfaces in the RIP section of the internetwork?

On R1, RIP is enabled on Serial0/0 (192.168.12.1), with network of 192.168.12.0, on R2, RIP is enabled on serial 0/0 ((192.168.12.2) connected to R1 ofcourse), with network 192.168.12.0.

All subnets are /24.

On R3, a route of 192.168.12.0 appears as 0 E2, even though its a directly connected network to R2 and should, according to the guide, not be redistributed.

kpjungle,

On R1, under the router RIP routing protocol, what network statement did you configure?

network 192.168.12.0

kpjungle,

Ok, here's what I think happened. On R1, when you configured the Serial 0/0 interface with the IP address of 192.168.12.1 255.255.255.0, what you also did was to configure the connected route out of the Serial 0/0 interface. You would have known that if you typed R1#show ip route right after you configured the Serial 0/0 interface. Then, when you configured RIP on R1, with the network 192.168.12.0 statement, the connected route for 192.168.12.0 out of the serial 0/0 interface was promoted to a RIP route for 192.168.12.0 which also happens to have Serial 0/0 as the exit interface. I'm going to firmly assume that there is an R2 with a serial port that is physically connected to the Serial 0/0 port on R1. I'm also going to firmly assume that this R2 also has RIP configured on it with a network 192.168.12.0 statement. So from the perspective of R1 and R2, network 192.168.12.0 is a RIP subnetwork. Then when you configured the following....

kpjungle wrote:

router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute rip subnets
network 192.168.24.2 0.0.0.0 area 0

That's when the OSPF side of the R2 learned of the RIP route to 192.168.12.0. Then, within OSPF, R2 sent that RIP route to 192.168.12.0 to R4 which then installed that route into it's routing table as an external (E2) route.

So in summary (a little BSCI humor attempt there), as soon as you configured R1 with RIP using network 192.168.12.0, the connected route became upgraded to a RIP route. Then when you configured "redistribute rip subnets" then all RIP routes without restriction was redistributed into OSPF. That's why R4 has an external route for the RIP network of 192.168.12.0.

kpjungle

tech-airman wrote:

So in summary (a little BSCI humor attempt there), as soon as you configured R1 with RIP using network 192.168.12.0, the connected route became upgraded to a RIP route. Then when you configured "redistribute rip subnets" then all RIP routes without restriction was redistributed into OSPF. That's why R4 has an external route for the RIP network of 192.168.12.0.

But still, it is a connected route as far as R2 is concerned, it hasnt learned this route from RIP, it knows it by itself, and following the exact example as in the study guide, it should ONLY redistribute routes that it itself sees as RIP routes (ie. not connected routes), there is no way for the serial link between R1 and R2 not to be a "rip route", if R2 is to learn about any other networks which R1 has.

tech-airman

kpjungle wrote:

tech-airman wrote:

So in summary (a little BSCI humor attempt there), as soon as you configured R1 with RIP using network 192.168.12.0, the connected route became upgraded to a RIP route. Then when you configured "redistribute rip subnets" then all RIP routes without restriction was redistributed into OSPF. That's why R4 has an external route for the RIP network of 192.168.12.0.

But still, it is a connected route as far as R2 is concerned, it hasnt learned this route from RIP, it knows it by itself, and following the exact example as in the study guide, it should ONLY redistribute routes that it itself sees as RIP routes (ie. not connected routes), there is no way for the serial link between R1 and R2 not to be a "rip route", if R2 is to learn about any other networks which R1 has.

kpjungle,

So what you're saying is that on R2, RIP is NOT configured?

kpjungle

tech-airman wrote:

kpjungle wrote:

tech-airman wrote:

So in summary (a little BSCI humor attempt there), as soon as you configured R1 with RIP using network 192.168.12.0, the connected route became upgraded to a RIP route. Then when you configured "redistribute rip subnets" then all RIP routes without restriction was redistributed into OSPF. That's why R4 has an external route for the RIP network of 192.168.12.0.

But still, it is a connected route as far as R2 is concerned, it hasnt learned this route from RIP, it knows it by itself, and following the exact example as in the study guide, it should ONLY redistribute routes that it itself sees as RIP routes (ie. not connected routes), there is no way for the serial link between R1 and R2 not to be a "rip route", if R2 is to learn about any other networks which R1 has.

kpjungle,

So what you're saying is that on R2, RIP is NOT configured?

No, on R2 RIP is configured, but R2's routing table shows the 192.168.12.0 link as connected, not a link learned from RIP.

tech-airman

kpjungle wrote:

tech-airman wrote:

kpjungle wrote:

tech-airman wrote:

So in summary (a little BSCI humor attempt there), as soon as you configured R1 with RIP using network 192.168.12.0, the connected route became upgraded to a RIP route. Then when you configured "redistribute rip subnets" then all RIP routes without restriction was redistributed into OSPF. That's why R4 has an external route for the RIP network of 192.168.12.0.

But still, it is a connected route as far as R2 is concerned, it hasnt learned this route from RIP, it knows it by itself, and following the exact example as in the study guide, it should ONLY redistribute routes that it itself sees as RIP routes (ie. not connected routes), there is no way for the serial link between R1 and R2 not to be a "rip route", if R2 is to learn about any other networks which R1 has.

kpjungle,

So what you're saying is that on R2, RIP is NOT configured?

No, on R2 RIP is configured, but R2's routing table shows the 192.168.12.0 link as connected, not a link learned from RIP.

kpjungle,

On R2, type "R2#show ip rip database".

kpjungle

tech-airman wrote:

kpjungle wrote:

tech-airman wrote:

kpjungle wrote:

tech-airman wrote:

So in summary (a little BSCI humor attempt there), as soon as you configured R1 with RIP using network 192.168.12.0, the connected route became upgraded to a RIP route. Then when you configured "redistribute rip subnets" then all RIP routes without restriction was redistributed into OSPF. That's why R4 has an external route for the RIP network of 192.168.12.0.

But still, it is a connected route as far as R2 is concerned, it hasnt learned this route from RIP, it knows it by itself, and following the exact example as in the study guide, it should ONLY redistribute routes that it itself sees as RIP routes (ie. not connected routes), there is no way for the serial link between R1 and R2 not to be a "rip route", if R2 is to learn about any other networks which R1 has.

kpjungle,

So what you're saying is that on R2, RIP is NOT configured?

No, on R2 RIP is configured, but R2's routing table shows the 192.168.12.0 link as connected, not a link learned from RIP.

kpjungle,

On R2, type "R2#show ip rip database".

It is listed as:
192.168.12.0/24 directly connected, Serial0/0, so again, if there is no rip route in the routing table (again, according to documentation it should only redistribute rip routes in the routing table), then its still contrary to the guide saying: ".. will not redistribute directly connected routes".

kpjungle

Does anyone know if this behavior is a "feature" or what not? Im still really unsure about why it redistribute a connected network when you only tell the IOS to redistribute another routing protocol? All the material ive read so far, states that only the routes from protocol A thats in the routing table will be redistributed into protocol B.

tech-airman

kpjungle wrote:

Does anyone know if this behavior is a "feature" or what not? Im still really unsure about why it redistribute a connected network when you only tell the IOS to redistribute another routing protocol? All the material ive read so far, states that only the routes from protocol A thats in the routing table will be redistributed into protocol B.

kpjungle,

You are not understanding redistribution correctly. You said...

kpjungle wrote:

No, on R2 RIP is configured, but R2's routing table shows the 192.168.12.0 link as connected, not a link learned from RIP.

I asked and you said....

kpjungle wrote:

tech-airman wrote:

kpjungle,

On R1, under the router RIP routing protocol, what network statement did you configure?

network 192.168.12.0

As soon as you configured RIP on R2, 192.168.12.0/24 became a RIP route. This is confirmed by typing "Router#show ip rip database." You said...

kpjungle wrote:

tech-airman wrote:

kpjungle,

On R2, type "R2#show ip rip database"

It is listed as:
192.168.12.0/24 directly connected, Serial0/0,...

That means 192.168.12.0/24 IS a RIP route. The "directly connected" part of the abovementioned RIP database record refers to the network 192.168.12.0/24 is directly connected to THIS router (R2) instead of R2 receiving a RIP update about the 192.168.12.0/24 network that's located on a remote RIP router. You said...

kpjungle wrote:

GT-Rob wrote:

what is your ospf config on R2

router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute rip subnets
network 192.168.24.2 0.0.0.0 area 0

So we've confirmed from "R2#show ip rip database" that 192.168.12.0/24 IS a RIP route and as soon as you configured the "redistribute rip subnets" command under the OSPF 1 process, RIP "taught" the 192.168.12.0/24 network from FROM RIP TO OSPF. At this point, OSPF now knows everything that RIP knows, in this case the 192.168.12.0/24 network. This is why on R2 and R3 you are seeing the external route to 192.168.12.0/24.

I think you're confused between the difference of: 1) What network(s)/routes that RIP knows 2) What network(s)/routes that OSPF knows 3) The routing table for R2 with respect to Administrative Distance.

To find out what network(s)/routes that RIP knows type the following...

R2#show ip rip database

To find out what network(s)/routes that OSPF knows type the following....

R2#show ip ospf database

To find out the routing table for R2 type the following....

R2#show ip route

What you see in "R2#show ip route" is the results of the Administrative Distance comparisons between the various routing protocols. For R2, these are: 1) Connected 2) OSPF 3) RIP. For the specific case of the network 192.168.12.0/24, there are two routing protcols that know that route: 1) Connected and 2) RIP. Remember that "#ip routing" is enabled by default. What that means is that as soon as you typed "R2(config-if)#ip address 192.168.12.2 255.255.255.0" on the Serial 0/0 interface of R2, that created the Connected route. A Connected route has an Administrative Distance of 0 by default. Then when you typed "R2(config-router)#network 192.168.12.0" statement under the RIP routing protocol configuration, 192.168.12.0/24 became a RIP route. A RIP route has an Adminstrative Distance of 120 by default. Soo, when the Connected routing protocol offered the 192.168.12.0/24 network to R2's routing process and RIP routing protocol offered the 192.168.12.0/24 network to R2's routing process, R2's routing process had to make a decision. Since the Administrative Distance for Connected is lower than RIP, the routing process chose the Connected route to install into the routing table. That's probably why when you type "R2#show ip route" you see 192.168.12.0/24 as a "Connected" route and NOT a RIP route. However, this does NOT mean that RIP does NOT know or has "forgotten" about 192.168.12.0/24 which is taught to OSPF as soon as you typed "R2(config-router)#redistribute rip subnets" under the OSPF process number 2.

So in summary, from the perspective of R2, network 192.168.12.0/24 is BOTH a Connected route AND a RIP route. It is the RIP route that was learned by OSPF and NOT the Connected route. I hope this finally helps.

Source:

What Is Adminstrative Distance? - Cisco Systems - http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml
Route Selection in Cisco Routers - Cisco Systems - http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094823.shtml

kpjungle

tech-airman,

If i dont understand redistribution correctly, how come you have still not answered my question regarding the before mentioned material. Why does the study-guide state, with examples that a connected network (which is also part of RIP (or any other routing protocol for that matter)) shouldnt be redistributed, when in fact it does?

Maybe you are right (your guess is the best i know so far), im just questioning the material.

Concerning administrative distance, i do understand that a connected route has a lower administrative distance, but if a router knows a route through both RIP and OSPF, do you still maintain that it will redistribute everything from that both protocols, or just the things thats in the routing table for each?

Thanks for the links.

gojericho0

kpjungle,

Does the same thing happen when you try to redistribute two other protocols say ISIS into EIGRP?
I wouldn't think that network would redistribute to R4 as well just because R2 is learns that network from being statically configured. I don't have time to try it out now with something else, but I think what the book references is true.

Are you doing this with real IOS or simulation?

kpjungle

gojericho0 wrote:

kpjungle,

Does the same thing happen when you try to redistribute two other protocols say ISIS into EIGRP?
I wouldn't think that network would redistribute to R4 as well just because R2 is learns that network from being statically configured. I don't have time to try it out now with something else, but I think what the book references is true.

Are you doing this with real IOS or simulation?

First i thought it might only be RIP, then i tried with EIGRP and OSPF as well, but i will try with multiple combinations. Its with dynamips, so not really simulation.

gojericho0

If thats the case the book is referring to directly connected networks where the remote end does not have a routing protocol running on its interface. For example a ethernet LAN

kpjungle

gojericho0 wrote:

If thats the case the book is referring to directly connected networks where the remote end does not have a routing protocol running on its interface. For example a ethernet LAN

I could understand that, but as the example(s) are laid out, it would be between R1 and R2 (where R2 is the distributing router), so if RIP was not running on that interface, R2 would never learn the routes from R1.

I will try multiple combination and report my findings, maybe that will shed some light on the specifics that im missing out on.

mikearama

I think tech hit the nail on the head, kp...

R2 is NOT redistributing a connected route, it's redistribuing a RIP subnet. The fact that it's directly connected to the OSPF int is immaterial... you told OSPF to redistribute RIP subnets, and that's what it's doing.

kpjungle

mikearama wrote:

I think tech hit the nail on the head, kp...

R2 is NOT redistributing a connected route, it's redistribuing a RIP subnet. The fact that it's directly connected to the OSPF int is immaterial... you told OSPF to redistribute RIP subnets, and that's what it's doing.

Thats true, i can understand that. I understand that the link between R1 and R2 is a "rip subnet", I have two issues concerning that though:

1) The study material/example clearly states that connected networks should not be redistributed, and the study-materials output of the routing table also shows that it shouldnt be redistributed.
2) Again, the material states that only routes in the routing table should be redistributed, not all the routes that the individual protocols know about.

So all im in doubt about, is if theres any reasoning the material says the opposite of all the good advice/help you all are giving me, and what my labs are telling me.

Heres my findings so far:

Topology:
R1 <-- --> R2 <-- --> R3

ISIS and OSPF:
OSPF does NOT import the ISIS link between R2 and R3 into the OSPF domain.
ISIS does import the OSPF link between R1 and R2 into the ISIS domain.

RIP and OSPF:
OSPF does import the RIP link between R1 and R2 into the OSPF domain.
RIP does import the OSPF link between R2 and R3 into the RIP domain.

RIP and EIGRP:
RIP does import the EIGRP link between R2 and R3 into the RIP domain.
EIGRP does import the RIP link between R1 and R2 into the EIGRP domain.

EIGRP and ISIS:
EIGRP does NOT import the ISIS link between R2 and R3 into the EIGRP domain.
ISIS does import the EIGRP link between R1 and R2 into the ISIS domain.

EIGRP and OSPF:
OSPF does import the EIGRP route between R1 and R2 into the OSPF domain.
EIGRP does import the OSPF route between R2 and R3 into the EIGRP domain.

gojericho0

kpjungle wrote:

mikearama wrote:

I think tech hit the nail on the head, kp...

R2 is NOT redistributing a connected route, it's redistribuing a RIP subnet. The fact that it's directly connected to the OSPF int is immaterial... you told OSPF to redistribute RIP subnets, and that's what it's doing.

Thats true, i can understand that. I understand that the link between R1 and R2 is a "rip subnet", I have two issues concerning that though:

1) The study material/example clearly states that connected networks should not be redistributed, and the study-materials output of the routing table also shows that it shouldnt be redistributed.
2) Again, the material states that only routes in the routing table should be redistributed, not all the routes that the individual protocols know about.

So all im in doubt about, is if theres any reasoning the material says the opposite of all the good advice/help you all are giving me, and what my labs are telling me.

Heres my findings so far:

Topology:
R1 <-- --> R2 <-- --> R3

ISIS and OSPF:
OSPF does NOT import the ISIS link between R2 and R3 into the OSPF domain.
ISIS does import the OSPF link between R1 and R2 into the ISIS domain.

RIP and OSPF:
OSPF does import the RIP link between R1 and R2 into the OSPF domain.
RIP does import the OSPF link between R2 and R3 into the RIP domain.

RIP and EIGRP:
RIP does import the EIGRP link between R2 and R3 into the RIP domain.
EIGRP does import the RIP link between R1 and R2 into the EIGRP domain.

EIGRP and ISIS:
EIGRP does NOT import the ISIS link between R2 and R3 into the EIGRP domain.
ISIS does import the EIGRP link between R1 and R2 into the ISIS domain.

EIGRP and OSPF:
OSPF does import the EIGRP route between R1 and R2 into the OSPF domain.
EIGRP does import the OSPF route between R2 and R3 into the EIGRP domain.

kpjungle,

This is what I wanted you to get at. When I was studying for BSCI, I discovered the same thing with ISIS not redistributing a directly connected link.

Have you figured out why this is occurring?

If not...here is a link I found when I was studying for this exam

http://www.groupstudy.com/archives/ccielab/200508/msg00726.html

kpjungle

gojericho0 wrote:

kpjungle,

This is what I wanted you to get at. When I was studying for BSCI, I discovered the same thing with ISIS not redistributing a directly connected link.

Have you figured out why this is occurring?

No, im afraid not, my best guess would be that the link is treated as a CLNS link and not an inherent IP based link. I dont know if thats a correct assumption though?

kryolla

By defualt when you redistribute it takes all the routes in the table that pertain to that protocol and all the interfaces that the protocol is configured and redistributes it. Now when you put a route-map in you change this default behavior and only redistribute what is in the route-map. Hope this helps