From: Oliver Grenham (ogrenham@optusnet.com.au)
Date: Tue Sep 28 2004 - 08:46:58 GMT-3
RE : RE : admin distance issueI see now what you are saying. I missed this
earlier. I will try this but i dont just have access to the equipment right
now. As far as Im aware OSPF does have a preference for internal routes over
external type 5 routes. I will test this when I go back online and let you
know the result.
Ollie.
----- Original Message -----
From: Richard Dumoulin
To: Oliver Grenham ; jean.paul.baaklini@accenture.com ;
ccielab@groupstudy.com
Sent: Tuesday, September 28, 2004 7:22 PM
Subject: RE : RE : admin distance issue
Oliver, I am not sure your test is valid. You need to have the route
advertised by another router. Try putting your admin 80 route in area 5 for
instance and also advertise the same route from an area 0 router. And please
tell us the result. I bet the area 0 route will be preferred even though its
admin distance is still 110,
--Richard
-----Message d'origine-----
De : Oliver Grenham [mailto:ogrenham@optusnet.com.au]
Envoyi : Tuesday, September 28, 2004 12:45 PM
@ : jean.paul.baaklini@accenture.com; Richard Dumoulin;
ccielab@groupstudy.com
Objet : Re: RE : admin distance issue
Its possible to set admin distance on a specifically learned route from a
specific OSPF neighbor. The admin distance of the route is taken into
account before being injected into the route table. I just tested a similar
scenario to the one you just described and it (the distance command) worked
fine. You must specify the OSPF neighbor by router ID.
router ospf 1
log-adjacency-changes
network 10.1.1.0 0.0.0.255 area 0
distance 80 172.16.1.1 0.0.0.0 9
!
ip classless
ip http server
!
access-list 9 permit 172.16.1.0 0.0.0.255
result!!!!
r2#sh ip ro ospf
172.16.0.0/24 is subnetted, 1 subnets
O 172.16.1.0 [80/11] via 10.1.1.4, 00:07:11, Ethernet0/0
Regards,
Ollie.
----- Original Message -----
From: <jean.paul.baaklini@accenture.com>
To: <Richard.Dumoulin@vanco.fr>; <ccielab@groupstudy.com>
Sent: Tuesday, September 28, 2004 6:06 PM
Subject: RE: RE : admin distance issue
> That's exactly what happens. It looks like it's not possible.
>
>
>
> I think this is just a small mistake in the lab task.
>
> I just want to confirm that with the group, as I really don't to push my
luck
> on the D-day.
>
>
>
> Cheers,
>
> JP
>
> -----Original Message-----
> From: Richard Dumoulin [mailto:Richard.Dumoulin@vanco.fr]
> Sent: 28 September 2004 10:54
> To: Baaklini, Jean paul; ccielab@groupstudy.com
> Subject: RE : admin distance issue
>
>
>
> Did it work ? I think you are right and the router won't take into
account
> the admin distance when comparing routes in the same OSPF realm. Only the
type
> of OSPF route and the cost will matter here,
>
> --Richard
>
> -----Message d'origine-----
> De : jean.paul.baaklini@accenture.com
> [mailto:jean.paul.baaklini@accenture.com]
> Envoyi : Tuesday, September 28, 2004 11:43 AM
> @ : ccielab@groupstudy.com
> Objet : admin distance issue
>
> Hi Group,
>
> I'm working on lab where a router R4 is directly connected to R3 (via
> Frame-Relay) and R5 (via ISDN). All three routers are in the same OSPF
> process.
>
> One requirement is to make the route via the frame relay preferred as
> opposed to the route via ISDN. The proposed solution makes the admin
> distance of the isdn link higher.
>
> I don't see how distance... under R4 is making R4 prefer R3. I thought
> that AD was only compared between different routing protocols. Here (on
> R4), we have only OSPF.
>
>
>
> Beyond this case, is it possible to use AD to influence routing within a
> routing domain (as opposed to between routing domains)?
>
>
>
> Thanks for your comments.
>
> Cheers,
> JP
>
>
>
> This message is for the designated recipient only and may contain
privileged,
> proprietary, or otherwise private information. If you have received it in
> error, please notify the sender immediately and delete the original. Any
> other use of the email by you is prohibited.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> **********************************************************************
> Any opinions expressed in the email are those of the individual and not
> necessarily the company. This email and any files transmitted with it are
> confidential and solely for the use of the intended recipient. If you are
not
> the intended recipient or the person responsible for delivering it to the
> intended recipient, be advised that you have received this email in error
and
> that any dissemination, distribution, copying or use is strictly
prohibited.
>
> If you have received this email in error, or if you are concerned with the
> content of this email please e-mail to: e-security.support@vanco.info
>
> The contents of an attachment to this e-mail may contain software viruses
> which could damage your own computer system. While the sender has taken
every
> reasonable precaution to minimise this risk, we cannot accept liability
for
> any damage which you sustain as a result of software viruses. You should
carry
> out your own virus checks before opening any attachments to this e-mail.
> **********************************************************************
>
>
>
> This message is for the designated recipient only and may contain
privileged,
> proprietary, or otherwise private information. If you have received it in
> error, please notify the sender immediately and delete the original. Any
> other use of the email by you is prohibited.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:50 GMT-3