RE: Redist OSPF into EIGRP . -does connected supercede process?

From: Daniel Cisco Group Study (danielcgs@imc.net.au)
Date: Wed Apr 02 2003 - 18:00:28 GMT-3


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