From: Radoslav Vasilev (deckland@gmail.com)
Date: Mon Oct 09 2006 - 11:23:53 ART
Hi Group,
I have some issues with the following setup.
R1 <-------> R2 <-------> R3 <----- OSPF area 0 > ....
RIPv2 is enabled between R1 and R2; OSPF (Area 51) is enabled between
R2 and R3. As seen above, the core ospf network continues to the right
with more routers.
The requirement initially is ot make sure that R3 summarizes the link
and loopback pools from the core in two /16 summaries. That's because
there's a broadband router on the segment between R2 and R3.
so, my R3 configuration becomes:
router ospf 100
router-id 150.1.3.3
area 0 range 161.1.0.0 255.255.0.0
summary-address 150.1.0.0 255.255.0.0
[...]
As soon as this commands are entered, R2 starts getting those
summaries correctly:
Rack1R2#sh ip route ospf
O IA 161.1.0.0/16 [110/782] via 161.1.23.3, 00:17:55, FastEthernet0/0
O E2 150.1.0.0/16 [110/20] via 161.1.23.3, 00:18:42, FastEthernet0/0
[...]
As I need to provider connectivity end-to-end, i redistribute the OSPF
routes in RIPv2 on R2:
router rip
version 2
redistribute ospf 100 metric 2
[...]
My problem is with the picture at R1 after the redistribution is in
place - R1 doesn't see the two summaries.
Are the same restrictions of what RIP can advertise /accept (depending
on the network mask) still in place with RIPv2?
Debuging shows that R2 actually sends the summaries:
00:47:40: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (161.1.12.2)
00:47:40: RIP: build update entries
00:47:40: 54.0.0.0/8 via 0.0.0.0, metric 2, tag 0
00:47:40: 54.1.1.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 150.1.0.0/16 via 0.0.0.0, metric 2, tag 0
00:47:40: 150.1.1.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 150.1.2.0/24 via 0.0.0.0, metric 1, tag 0
00:47:40: 150.1.4.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 150.1.5.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 150.1.6.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 150.1.7.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 150.1.8.0/24 via 0.0.0.0, metric 2, tag 0
Rack1R2#
00:47:40: 161.1.0.0/16 via 0.0.0.0, metric 2, tag 0
00:47:40: 161.1.5.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 161.1.10.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 161.1.12.0/24 via 0.0.0.0, metric 1, tag 0
00:47:40: 161.1.23.0/24 via 0.0.0.0, metric 1, tag 0
00:47:40: 161.1.58.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 161.1.67.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 161.1.78.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 192.10.1.0/24 via 0.0.0.0, metric 2, tag 0
00:47:40: 204.12.1.0/24 via 0.0.0.0, metric 2, tag 0
Debuging on R1 shows that R1 receives them:
00:49:36: RIP: received v2 update from 161.1.12.2 on Serial0/0
00:49:36: 54.0.0.0/8 via 0.0.0.0 in 2 hops
00:49:36: 54.1.1.0/24 via 0.0.0.0 in 2 hops
00:49:36: 150.1.0.0/16 via 0.0.0.0 in 2 hops
00:49:36: 150.1.1.0/24 via 0.0.0.0 in 2 hops
00:49:36: 150.1.2.0/24 via 0.0.0.0 in 1 hops
00:49:36: 150.1.4.0/24 via 0.0.0.0 in 2 hops
00:49:36: 150.1.5.0/24 via 0.0.0.0 in 2 hops
00:49:36: 150.1.6.0/24 via 0.0.0.0 in 2 hops
00:49:36: 150.1.7.0/24 via 0.0.0.0 in 2 hops
00:49:36: 150.1.8.0/24 via 0.0.0.0 in 2 hops
00:49:36: 161.1.0.0/16 via 0.0.0.0 in 2 hops
00:49:36: 161.1.5.0/24 via 0.0.0.0 in 2 hops
00:49:36: 161.1.10.0/24 via 0.0.0.0 in 2 hops
00:49:36: 161.1.12.0/24 via 0.0.0.0 in 1 hops
00:49:36: 161.1.23.0/24 via 0.0.0.0 in 1 hops
00:49:36: 161.1.58.0/24 via 0.0.0.0 in 2 hops
00:49:36: 161.1.67.0/24 via 0.0.0.0 in 2 hops
00:49:36: 161.1.78.0/24 via 0.0.0.0 in 2 hops
00:49:36: 192.10.1.0/24 via 0.0.0.0 in 2 hops
00:49:36: 204.12.1.0/24 via 0.0.0.0 in 2 hops
but they are not in the routing table....
Any opinion appreciated!
Rado
This archive was generated by hypermail 2.1.4 : Wed Nov 01 2006 - 07:29:04 ART