From: Anthony Sequeira (terry.francona@gmail.com)
Date: Thu Dec 01 2005 - 14:29:21 GMT-3
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