From: Anthony Sequeira (terry.francona@gmail.com)
Date: Thu Dec 01 2005 - 12:42:12 GMT-3
Apparently at one point in IOS with EIGRP - you could use passive-interface
in conjunction with the neighbor command in order to only establish
adjacencies with a certain system. Here is the documentation excerpt from
12.0 on the subject:
<<<This command permits the point-to-point (nonbroadcast) exchange of
routing information. When used in combination with the
*passive-interface *router
configuration command, routing information can be exchanged between a subset
of routers and access servers on a LAN.
router eigrp 109
network 192.168.0.0
passive-interface ethernet 1
neighbor 192.168.20.4 >>>>>
As of 12.2.16 IOS this changed dramatically! Here is the new documentation (
12.3) and configuration example:
<<<<<Multiple *neighbor* commands can be used to specify additional
neighbors or peers. With most routing protocols, the
*passive-interface*command restricts outgoing advertisements only.
However, when used with the
Enhanced Interior Gateway Routing Protocol (EIGRP), the use of the *
passive-interface* command suppresses the exchange of hello messages between
two routers, which results in the loss of their neighbor relationship. This
behavior stops not only routing updates from being advertised, but it also
suppresses incoming routing updates.
In the following example, EIGRP permits the sending of routing updates to
specific neighbors. One copy of the routing update is generated per
neighbor.
router eigrp 109
network 192.168.0.0
neighbor 192.168.20.4>>>>>>>
So Eddie - looks like you have a great point - we can still use the neighbor
command - it just cannot be combined with passive-interface any more. Can
someone lab this up and ensure it works? I do not have access to a broadcast
topology right now where I could try the neighbor command alone without
passive-interface.
I am assumming this feature causes EIGRP to unicast hellos only to a certain
neighbor and RESTRICTS the neighboring with anyone else.....I would sure
love to try it.......
On 12/1/05, Eddie Parra <eddie.parra@gmail.com> wrote:
>
> Anthony,
>
> Is the neighbor command useless in this scenario? If you have 4
> routers on an Ethernet segment and you only want to form a neighbor
> relationship with one, unicast neighbors is a viable option since
> multicast hellos will then be ignored from other neighbors. Depending
> on how the objective in the lab is worded, this might be a viable
> option.
>
> -Eddie
>
>
> On 11/30/05, Anthony Sequeira <terry.francona@gmail.com> wrote:
> > Chris - you are correct - I was sloppy in my post - SO SORRY - the
> > distribute-list with the gateway option would prevent the reception of
> > routes and does not effect the adjacency.
> >
> > BUT - I want to reiterate that as of 12.2.16 - the NEIGHBOR command
> appears
> > totally useless with EIGRP, I have confirmed this on equipment.
> >
> >
> > 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
> >
> > _______________________________________________________________________
> > 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:50 GMT-3