From: Henk de Tombe (henk.de.Tombe@qi.nl)
Date: Fri Jan 05 2007 - 05:52:43 ART
All,
I've labbed this one up and have found the following:
R2#sh ip ospf int brief
Interface PID Area IP Address/Mask Cost State Nbrs
F/C
Lo0 1 2 172.16.2.2/24 1 P2P 0/0
R2#
>> Interface Loopback0 is member of OSPF area 2.
R2#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
level-2
ia - IS-IS inter area, * - candidate default, U - per-user static
route
o - ODR
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.2.0 is directly connected, Loopback0
C 192.168.23.0/24 is directly connected, Serial1/1
150.1.0.0/24 is subnetted, 2 subnets
D 150.1.3.0 [90/1889792] via 192.168.23.3, 00:06:21, Serial1/1
C 150.1.2.0 is directly connected, Loopback1
R2#
>> Loopback0 on R2 is a directly connected network according the
>> routingtable.
>>
>> route-map o2e matches internal routes and sets a metric for EIGRP.
This >> route-map is applied to the redistribution process of EIGRP.
R2#sh route-map o2e
route-map o2e, permit, sequence 10
Match clauses:
route-type internal
Set clauses:
metric 10000 10 255 1 1500
Policy routing matches: 0 packets, 0 bytes
R2#
R2#sh run | b router eigrp 1
router eigrp 1
redistribute ospf 1 route-map o2e
network 192.168.23.2 0.0.0.0
no auto-summary
>> The show ip EIGRP topology on R2 shows that subnet 172.16.2.0/24 is
learned via redistribution.
R2#sh ip eigrp top
IP-EIGRP Topology Table for AS(1)/ID(172.16.2.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 192.168.23.0/24, 1 successors, FD is 1761792
via Connected, Serial1/1
P 150.1.3.0/24, 1 successors, FD is 1889792
via 192.168.23.3 (1889792/128256), Serial1/1
P 172.16.2.0/24, 1 successors, FD is 258560
via Redistributed (258560/0) <<-------------------------
On R3 the subnet is learned as an EIGRP external route:
R3#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
level-2
ia - IS-IS inter area, * - candidate default, U - per-user static
route
o - ODR
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 2 subnets
D EX 172.16.2.0 [170/1764352] via 192.168.23.2, 00:26:50, Serial1/1
C 172.16.3.0 is directly connected, Loopback0
C 192.168.23.0/24 is directly connected, Serial1/1
150.1.0.0/24 is subnetted, 1 subnets
C 150.1.3.0 is directly connected, Loopback1
>> I've performed some debugs to check what the EIGRP process is doing
with >> subnet 172.16.2.0/24
R2(config-router)#redistribute ospf 1 route-map o2e
R2(config-router)#
R2(config-router)#
R2(config-router)#
R2(config-router)#do clear ip ro *
R2(config-router)#
01:03:25: RT: add 192.168.23.0/24 via 0.0.0.0, connected metric [0/0]
01:03:25: RT: interface Serial1/1 added to routing table
01:03:25: RT: add 172.16.2.0/24 via 0.0.0.0, connected metric [0/0]
01:03:25: RT: interface Loopback0 added to routing table
01:03:25: RT: add 150.1.2.0/24 via 0.0.0.0, connected metric [0/0]
01:03:25: RT: interface Loopback1 added to routing table
01:03:25: RT: add 150.1.3.0/24 via 192.168.23.3, eigrp metric
[90/1889792]
01:03:25: IP-EIGRP(Default-IP-Routing-Table:1): route installed for
150.1.3.0 ()
01:03:25: IP-EIGRP(Default-IP-Routing-Table:1): 172.16.2.0/24 - do
advertise out Serial1/1
01:03:25: IP-EIGRP(Default-IP-Routing-Table:1): Ext 172.16.2.0/24 metric
258560 - 256000 2560
01:03:25: IP-EIGRP(Default-IP-Routing-Table:1): Processing incoming
UPDATE packet
01:03:25: IP-EIGRP(Default-IP-Routing-Table:1): ExtS 172.16.2.0/24 M
4294967295 - 1249792 4294967295 S
M 4294967295 - 1249792 4294967295
In this setup redistribution of a "directly connected" subnet works, due
to the fact that this interface is a member of the OSPF process. Can you
send us the configurations that you are using. I would like to see what
configuration you've used.
Regards,
Henk
-----Oorspronkelijk bericht-----
Van: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Namens Thiago
Vazquez
Verzonden: donderdag 4 januari 2007 21:28
Aan: ccielab@groupstudy.com
Onderwerp: Problems while redistributing OSPF with route-map
All,
When a router has an interface running OSPF and then you redistribute
OSPF into another routing protocol, EIGRP for instance, when I'm
redistributing into EIGRP I'm using a route map with the following
config:
route-map exe5do permit 35
match route-type internal
set metric 10000 10 255 1 1500
router eigrp 1
redistribute ospf 1 route-map exe5do
network 192.168.100.0
no auto-summary
!
What happens is that with the config above all OSPF internal routes are
redistributed into the EIGRP domain as expected but the network directly
connected to the router performing the redistribution which is running
OSPF is not getting into the EIGRP domain so my 1st thought was that
redistribution will only consider routes in the route table so this
connected network won't be redistributed as per route table it's
connected and not OSPF internal but what is weird and I can't understand
is that when I set the route map with the following config this directly
connected network is advertised:
route-map ex5 permit 35
set metric 10000 10 255 1 1500
Summarizing:
If route map is to match OSPF internal then directly connected network
doesn't get redistributed but if route map is to redistribute all OSPF
the directly connected network gets advertised.
Please can any one help me clarifying?
** If you need, I've got all outputs.
Thanks, Thiago
----------------------------------------------------------------------
Network Operations Center
Easynet
email: thiago.vazquez@uk.easynet.net
team email: networks.support@uk.easynet.net
tel.: +44 (0) 207 032 8006
----------------------------------------------------------------------
This archive was generated by hypermail 2.1.4 : Thu Feb 08 2007 - 23:46:55 ART