RE: OSPF / IGRP update drop

From: David Bader (David.Bader@xxxxxxxxxx)
Date: Wed Dec 05 2001 - 05:16:19 GMT-3


   
hi parry,

this is a cool solution, very advanced, congratulation. what do you think,
would you use a solution like this on the lab? i mean if you are supposed
not to use any statics and no defaults in any way, it would be a solution.
but you would have add an additional network to the lab setup. and you have
to filter the redistributed updates coming into ospf.
i think i would't use a solution like this.

but it works (i tried it), thanks

regards dave

David Bader / Systems Engineer / NOS
-------------------------------------------------------------------
ECON!S AG / eBusiness Solutions
- Electronic Business Solutions
- Network and Office Solutions
- Consulting and Projectmanagement
Neumattstrasse 7 / CH 8953 Dietikon / Switzerland
Phone ++41 (0) 1 744 73 73
Direct ++41 (0) 1 744 73 25
Fax ++ 41 (0) 1 744 73 99
<mailto:david.bader@econis.com>
<http://www.econis.com/>
-------------------------------------------------------------------

-----Original Message-----
From: Chua, Parry [mailto:Parry.Chua@compaq.com]
Sent: Mittwoch, 5. Dezember 2001 08:48
To: David Bader; John Elias; CCIE Lab (E-mail)
Subject: RE: OSPF / IGRP update drop

I guess the problem is due to discontinue subnet for IGRP (R1 and R3),
since R2 and R3 run
ospf, try configure a secondary address between R1 and R2 say using
140.200.3.0/24.

Regards
Parry

-----Original Message-----
From: David Bader [mailto:David.Bader@econis.com]
Sent: Wednesday, December 05, 2001 3:03 PM
To: 'John Elias'; CCIE Lab (E-mail)
Subject: RE: OSPF / IGRP update drop

Dave,
   When you are mutually redistibuting, are you including the metrics
for
IGRP and OSPF? and the keyword 'subnets' for OSPF?
...
yes i did
...
 The fact that all of
the networks are /24, there should be no problem with IGRP to accecpt
the
network 140.200.2.0/24 into its routing table.
..
the problem is it is a supernet update of a connected network, so igrp
will
drop the update by definition.

..
Are you summarizing by any
chance?
..
i am not, but igrp does at the class border
..

  Could you post the configs.

John E.
CCIE #8150

>From: David Bader <David.Bader@econis.com>
>Reply-To: David Bader <David.Bader@econis.com>
>To: "CCIE Lab (E-mail)" <ccielab@groupstudy.com>
>Subject: OSPF / IGRP update drop
>Date: Tue, 4 Dec 2001 19:43:16 +0100
>
>Hi group
>Big problem !!!
>
>
>
>
>140.200.1.0/24 |---R1
> |
> 130.1.1.0/24 |
> |
> R2----R3---| 140.200.2.0/24
>
> 130.1.2.0/24
>
>
>This problem is a little bit tricky to understand. R2 and R3 are
running
>OSPF between them and on R3's Lan. R1 and R2 are running IGRP between
each
>other and on R1's Lan. R2 is mutually redistributing between OSPF and
IGRP.
>Now to the Problem: the 140.200.2.0/24 gets redistributed as
140.200.0.0/16
>on R2. The route comes to R1 but is rejected because it has already a
route
>from the same major net in its routing table
>(http://www.cisco.com/warp/public/105/54.html). The other way
>140.200.1.0/24
>gets advertised as 140.200.0.0/16 to R2 and is installed in R2's
routing
>table and in R3's routing table too because of redistribution. So, R3
has a
>route to R1 (140.200.0.0/16), but R1 has no route back.
>
>How can i solve this problem without using static routes?
>
>any ideas?
>
>regards dave
>
>
>David Bader / Systems Engineer / NOS
>-------------------------------------------------------------------
>ECON!S AG / eBusiness Solutions
>- Electronic Business Solutions
>- Network and Office Solutions
>- Consulting and Projectmanagement
>Neumattstrasse 7 / CH 8953 Dietikon / Switzerland
>Phone ++41 (0) 1 744 73 73
>Direct ++41 (0) 1 744 73 25
>Fax ++ 41 (0) 1 744 73 99
><mailto:david.bader@econis.com>
><http://www.econis.com/>
>-------------------------------------------------------------------



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:38 GMT-3