From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Thu Dec 01 2005 - 01:09:13 GMT-3
Dear All:
This has been an interesting thread, however I've seen quite a few responses that I cannot replicate on routers.
For example in eigrp the distribute-list gateway configuration only affects routes received, not the forming of neighbors. Also I have just labbed up an ethernet segment with 5 routers on it, left the OSPF network type as broadcast and the interface level command ip ospf database-filter all out worked fine on the router I applied it on, all other routers formed an adjacency on it, however after this command was applied, the other routers no longer had routes in their routing table to the loopbacks the router was originally advertising.
If the original question was to exclude just one neighbor from forming adjacency on a multi access network for either OSPF or EIGRP and not using interface ACLs, the best suggestion I've seen is to use a service policy on the interface that relates to a class map identifying the neighbor and the action in the policy-map is drop.
If you want to stop routes from the specific neighbor, the distribute list option makes sense.
Chris
Paul Borghese <pborghese@groupstudy.com> wrote:
Mike,
If the requirement is to prevent the neighbor relationship, the command
"neighbor database-filter all out" does not meet that requirement. The
routers will still form a neighbor relationship. Plus it only works on ospf
network type Point-to-Multipoint.
Take care,
Paul Borghese
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Mike
Ollington
Sent: Wednesday, November 30, 2005 10:57 AM
To: Ed Lui
Cc: Paul Borghese; ccielab@groupstudy.com
Subject: RE: Preventing an EIGRP/OSPF Neighbor Forming
Ed,
That would be changing for it the whole area thus affecting all the
neighbors.
Ronald's `neighbor ip-address database-filter all out' command would
work fine for OSPF. Thanks Ronald.
Cheers,
Mike
-----Original Message-----
From: Ed Lui [mailto:edwlui@gmail.com]
Sent: 30 November 2005 15:52
To: Mike Ollington
Cc: Paul Borghese; ccielab@groupstudy.com
Subject: Re: Preventing an EIGRP/OSPF Neighbor Forming
Mike,
Are you allowed to use OSPF authentication ?
Ed Lui
On 11/30/05, Mike Ollington wrote:
> Paul,
>
> Changing those values would break all neighbours on an interface,
> anything to kill just the one?
>
> For example:
>
> 172.16.1.1
> 172.16.1.2
> 172.16.1.3 <- I temporarily want to prevent this neighbour.
> 172.16.1.4
>
> Thanks,
> Mike
>
> -----Original Message-----
> From: Paul Borghese [mailto:pborghese@groupstudy.com]
> Sent: 30 November 2005 15:10
> To: Mike Ollington
> Cc: ccielab@groupstudy.com
> Subject: Re: Preventing an EIGRP/OSPF Neighbor Forming
>
> In OSPF a neighbor relationship will not be formed if any of the
> following
> mismatch:
>
> hello/dead interval
> area id
> stub flag
> authentication
> subnet mask
> mtu
>
> So for example, if you change the hello interval on one side, the
> neighbor
> will not form. You can see this by doing a "debug ip ospf adj".
>
> For EIGRP, you can try changing the K values or Autonomous System
> number.
> EIGRP will for a relationship even if the hello values do not match.
>
> Take care,
>
> Paul Borghese
>
> > Hello,
> >
> >
> >
> > Hypothetical - you have an interface with many EIGRP/OSPF
neighbours.
> > You want to prevent one; you don't want to use an interface access
> list.
> >
> >
> >
> > In BGP there is the neighbour shutdown command, PIM has a neighbour
> > list. Any thing similar for OSPF or EIGRP?
> >
> >
> >
> > Thanks,
> >
> > Mike
> >
>
>
>
>
> **********************************************************************
> 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.
>
> Although Dimension Data has taken reasonable precautions to ensure no
viruses are present in this email, the company cannot accept
responsibility for any loss or damage arising from the use of this email
or attachments.
>
> www.uk.didata.com
> **********************************************************************
>
>
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:49 GMT-3