From: Josef A (josefnet@gmail.com)
Date: Thu Dec 01 2005 - 01:42:22 GMT-3
Chris - How would the neighbor be specifically classified using a class-map?
Thanks
Josef.
On 11/30/05, Chris Lewis <chrlewiscsco@yahoo.com> wrote:
>
> 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
> > **********************************************************************
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
> ---------------------------------
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:49 GMT-3