From: Eddie Parra (eddie.parra@gmail.com)
Date: Thu Dec 01 2005 - 17:01:01 GMT-3
The neighbor command creates a neighbor using unicast hellos. Once
you enable this, this disables the egress interface from accepting
multicast hellos from other neighbors. So this is one way to
restricting neighbors, especially if you are asked to do this without
using authentication.
-Eddie
On 12/1/05, Anthony Sequeira <terry.francona@gmail.com> wrote:
> Wow - thanks for this!
>
> Here is something I can now take away from this - when it comes to EIGRP:
>
> If I want to prevent neighborship - I will use the neighbor command.
>
> If I want to prevent routing updates - I will use a distribute list.
>
>
> On 12/1/05, James Matrisciano <jmatrisciano@kenttech.com> wrote:
> > Here ya go...
> >
> > Router 1 cat 1 cat 2, all in vlan 10
> >
> > Router 1 config
> > Int e0
> > Ip add 1.1.1.1 255.255.255.0
> >
> > Router eigrp 1
> > Net 1.1.1.0 0.0.0.255
> > Passive-int defa
> > No pass e0
> >
> >
> > -------------------
> >
> > Cat 1
> >
> > Int vlan 10
> > Ip add 1.1.1.10 255.255.255.0
> >
> > Router eigrp 1
> > Net 1.1.1.0 0.0.0.255
> > Nei 1.1.1.1 vlan 10
> > Nei 1.1.1.20 vlan 10
> > Passive-int defa
> > No pass vlan 10
> >
> > --------------------------
> >
> > Cat 2
> >
> > Int vlan 10
> > Ip add 1.1.1.20 255.255.255.0
> >
> > Router eigrp 10
> > Net 1.1.1.0 0.0.0.255
> > Nei 1.1.1.10 vlan 10
> > Passive-int defa
> > No pass vlan 10
> >
> > -------------------------
> >
> > Router 1
> >
> > Sh ip eigrp nei
> >
> > 0 1.1.1.1 Et0
> >
> >
> > ----------------------
> >
> > Cat 1
> >
> > Sh ip eigrp nei
> >
> > 1 1.1.1.20 Vl10
> > 0 1.1.1.1 Vl10
> >
> > ----------------------
> >
> > Cat 2
> >
> > Sh ip eigrp nei
> >
> > 0 1.1.1.10 Vl10
> >
> >
> > Yes, this works. This is with the passive-interface command and no
> > passinve on the interface that it needs to talk to. Of course, if you
> > do not use the "no passive-interface eX" it will never talk. I also
> > tested it without the passive command and received the same results.
> > Only nei statements on the cat's, left r1 wide open to send broadcasts,
> > cat2 does not send anything back because of the neighbor statement.
> > With debug Ip packet, you will see r1 send out the broadcast to the
> > 224.0.0.5 but only receive anything from cat1 1.1.1.10, because cat1 has
> > the nei statement on it and now only uses unicast to send info for the
> > 1.1.1.0 network.
> >
> > This does not allow the neighbor relationship between r1 and cat2, which
> > is what I think was intended at the beginning of this thread. I thought
> > it was to form a neighbor relationship and not exchange routing info,
> > correct?
> >
> > So, after labbing this up, the only way to hold a neighbor relationship
> > and not receive routing updates is the following...
> >
> > On r1
> >
> > Ip cef
> >
> > Class-map eigrp
> > Match protocol eigrp
> >
> > Class-map other
> > Match any
> >
> > Policy-map
> > Class eigrp
> >
> > Class other
> > Drop
> >
> > Int e0
> > Service-policy out eigrp
> >
> > Sh ip eigrp nei
> >
> > 1 1.1.1.10 e0
> > 0 1.1.1.20 e0
> >
> > Sh ip route eigrp 10
> >
> > _nothing here, and I have a route being advertised by cat1-
> >
> > Now, the downside of this little venture....seems as I have some
> > flapping taking place on the r1 link. So every 1:18 seconds, you will
> > loose your adjecency, even with the nei statement. I suppose you could
> > expand your hold-down timer on the interface to 65535 so you will only
> > flap once every 18 hours...its back up in 2.5 seconds time.
> >
> > It's the only way I could get it to work....any others want to waste
> > some of their time on this, feel free :)
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com ] On Behalf Of
> > Anthony Sequeira
> > Sent: Thursday, December 01, 2005 10:42 AM
> > To: Eddie Parra
> > Cc: Chris Lewis; Paul Borghese; Mike Ollington; Ed Lui;
> > ccielab@groupstudy.com
> > Subject: Re: Preventing an EIGRP/OSPF Neighbor Forming
> >
> > 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
> >
> >
> _______________________________________________________________________
> > 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