From: Jason Cash (cash2001@swbell.net)
Date: Wed Apr 02 2003 - 18:04:35 GMT-3
Well that makes sense, but the route is appearing in the EIGRP topo
table. When I would thing makes it part of the process. The question
here is at what point does OSPF redist. Eigrp.
Connected > EIGRP > EIGRP TOP > OSPF
If it follows the above logic, then the routes should appear in the OSPF
database, which they are not. Can anyone enlighten us on this?
-----Original Message-----
From: Daniel Cisco Group Study [mailto:danielcgs@imc.net.au]
Sent: Wednesday, April 02, 2003 3:00 PM
To: Jeongwoo Park; Jason Cash; ccielab@groupstudy.com
Subject: RE: Redist OSPF into EIGRP . -does connected supercede process?
Here's 1 cent...
From what I can see, you are trying to redistribute connected into
EIGRP, and then redistribute EIGRP into OSPF, all on the same router,
expecting OSPF to see the original connected route....
CONNECTED --> EIGRP --> OSPF
I don't believe that this is possible, but I've not come across any
"official rules".
To provoke some thought amongst the audience, consider the following:
Redistribute OSPF into EIGRP: You'll get external routes in EIGRP. Now,
redistribute EIGRP back into OSPF on the same router..... I'd be really
surprised if you now saw type 5 LSAs in the OSPF database for the same
original OSPF routes that were redistributed into EIGRP....
Although my thoughts are not completely nailed down on this, I think
this behaviour would be related to preventing route feedback within the
same router....
Anyone have the other 1 cent ?
Daniel
-----Original Message-----
From: Jeongwoo Park [mailto:jpark@wams.com]
Sent: Wednesday, 2 April 2003 8:20 PM
To: 'Jason Cash'; 'ccielab@groupstudy.com'
Subject: RE: Redist OSPF into EIGRP . -does connected supercede process?
I don't see why R3 don't see the R2's connected interface (e0)
Does anyone want to throw your 2cents?
JP
-----Original Message-----
From: Jason Cash [mailto:cash2001@swbell.net]
Sent: Tuesday, April 01, 2003 4:43 PM
To: ccielab@groupstudy.com
Subject: Redist OSPF into EIGRP . -does connected supercede process?
Here's the topo: The problem is when I do a 'sh ip ospf data' on r2
(running eigrp and ospf - mutual redist), the e0 interface is not
listing. OSPF ixnays the E0 interface via connected redist (via the
route-map), but should redist it from the EIGRP process. For some
reason this isn't happening. R1 sees everything fine (ospf routes into
eigrp) and r3 see everything BUT the E0 interface on R2!
Is my thinking correct in this regard for ospf:
1. Redistribute connected interfaces via route-map ospf-conn.
(everything but Ethernet0)
2. redistribute the EIGRP 102 process (which then would throw the E0
interface into OSPF)
3. distribute these routes to OSPF neigbors
R3(s1)
/ \
/ \
R1(s0)---(s1)R2(s0)/ \R5 (s1)
Ethernet0 130.1.20.1 EIGRP
Loopback0 140.4.2.1 OSPF
Loopback1 140.4.20.1 OSPF
Serial0 140.4.1.2 OSPF
Serial1 172.16.0.2 OSPF
hostname r2
!
interface Loopback0
ip address 140.4.2.1 255.255.255.0
!
interface Loopback1
description Token Ring 0
ip address 140.4.20.1 255.255.255.128
ip ospf network point-to-point
!
interface Ethernet0
ip address 130.1.20.1 255.255.255.0
!
interface Serial0
ip address 140.4.1.2 255.255.255.240
encapsulation frame-relay
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco
ip ospf hello-interval 10
no fair-queue
frame-relay map ip 140.4.1.3 203 broadcast
frame-relay map ip 140.4.1.5 203 broadcast
no frame-relay inverse-arp
!
interface Serial1
ip address 172.16.0.2 255.255.255.0
!
router eigrp 102
redistribute connected metric 10 1 255 1 1500 route-map connei
redistribute ospf 1 metric 10 1 255 1 1500
network 172.16.0.0
auto-summary
no eigrp log-neighbor-changes
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 500
area 1 authentication message-digest
area 1 virtual-link 140.4.30.1
redistribute connected subnets route-map ospf-conn
redistribute eigrp 102 metric 20 subnets
network 140.4.1.0 0.0.0.15 area 1
network 140.4.2.0 0.0.0.255 area 1
network 140.4.20.0 0.0.0.127 area 20
!
ip classless
no ip http server
!
access-list 5 permit 130.1.0.0 0.0.255.255
access-list 6 permit any
route-map connei permit 10
match ip address 5
!
route-map connei deny 20
match ip address 6
!
route-map ospf-conn deny 10
match ip address 5
!
route-map ospf-conn permit 20
match ip address 6
Here is R3 route table, it sees all the EIGRP route EXCEPT for the E0
interface:
r3#si
140.4.0.0/16 is variably subnetted, 10 subnets, 5 masks
O 140.4.13.1/32 [110/51] via 140.4.4.13, 21:05:16, Ethernet0
C 140.4.1.0/28 is directly connected, Serial1
O 140.4.2.1/32 [110/324] via 140.4.1.2, 20:25:55, Serial1
C 140.4.3.0/24 is directly connected, Loopback0
O 140.4.5.1/32 [110/324] via 140.4.1.5, 20:25:55, Serial1
C 140.4.4.0/25 is directly connected, Ethernet0
O 140.4.6.1/32 [110/51] via 140.4.4.6, 21:05:17, Ethernet0
C 140.4.30.0/25 is directly connected, Loopback1
O IA 140.4.56.0/30 [110/7862] via 140.4.4.6, 20:25:57, Ethernet0
O IA 140.4.50.0/24 [110/333] via 140.4.1.5, 20:25:57, Serial1
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
O E2 172.16.0.0/24 [110/20] via 140.4.1.2, 00:25:08, Serial1
O E2 172.16.0.0/21 [110/20] via 140.4.1.2, 20:25:43, Serial1
It's like R2 irunning the 'redist ei 102' process first then running the
'redist connected'. In what order does this occur?
130.1.20.1 is not listed in the ip ospf database but is in the eigrp
topo!
r2# sh ip ei top
IP-EIGRP Topology Table for AS(102)/ID(140.4.20.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 130.1.20.0/24, 1 successors, FD is 281600
via Rconnected (256000256/0)
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:35:45 GMT-3