From: James Matrisciano (jmatrisciano@kenttech.com)
Date: Thu Dec 01 2005 - 13:29:44 GMT-3
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
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3