From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Sat Dec 03 2005 - 12:02:42 GMT-3
Here is an excerpt from a link that Scott sent me this past week....I
think this may cover the issue....
In the following, please note the statement in the first paragraph that
I underlined. I didn't realize this is different that the behavior of
the neighbor command in RIP, where the multicast traffic is also sent
along with the unicast (one needs no turn off the v2-broadcast).
However, in EIGRP.... You only need to add the neighbor command to start
unicast traffic, and turn off the multicast flow at the same time. So,
if the lab question says to only use unicast traffic to establish
relationships, and have no multicast traffic, then you do this with
adding the neighbor command. Please let me know if I missed anything.
Thanks, Scott and Chris and everyone for the interesting discussion.
Dave
What does the neighbor statement in the EIGRP configuration section do?
A. The neighbor command is used in EIGRP to define a neighboring router
with which to exchange routing information. Due to the current behavior
of this command, EIGRP exchanges routing information with the neighbors
in the form of unicast packets whenever the neighbor command is
configured for an interface. EIGRP will stop processing all multicast
packets coming inbound on that interface. Also, EIGRP stops sending
multicast packets on that interface.
The ideal behavior of this command would be for EIGRP to start sending
EIGRP packets as unicast packets to the specified neighbor, but not stop
sending and receiving multicast packets on that interface. Since the
command does not behave as intended, the neighbor command should be used
carefully, understanding the impact of the command on the network.
Q. Why does the EIGRP passive-interface command remove all neighbors for
an interface?
A. The passive-interface command disables the transmission and receipt
of EIGRP hello packets on an interface. Unlike IGRP or RIP, EIGRP sends
hello packets in order to form and sustain neighbor adjacencies. Without
a neighbor adjacency, EIGRP cannot exchange routes with a neighbor.
Therefore, the passive-interface command prevents the exchange of routes
on the interface. Although EIGRP does not send or receive routing
updates on an interface configured with the passive-interface command,
it still includes the address of the interface in routing updates sent
out of other non-passive interfaces. For more information, refer to How
Does the Passive Interface Feature Work in EIGRP?
<http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800
93f0a.shtml>
________________________________
From: Scott Morris [mailto:swm@emanon.com]
Sent: Friday, December 02, 2005 11:07 PM
To: 'Chris Lewis'; Schulz, Dave; nobody@groupstudy.com; 'Anthony
Sequeira'; 'Eddie Parra'
Cc: 'Paul Borghese'; 'Mike Ollington'; 'Ed Lui'; ccielab@groupstudy.com
Subject: RE: Preventing an EIGRP/OSPF Neighbor Forming
Ahhhh.... Must has mis-read something earlier. I thought the gist was
that people wanted to use passive interface. But yes, neighbor part
only (as we saw in my logs too) will kill the neighbor yet re-establish
it as unicast. But passive interface destroys the whole thing.
Never mind. I'll go back to drinking now. ;)
Scott
________________________________
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Friday, December 02, 2005 5:59 PM
To: swm@emanon.com; 'Schulz, Dave'; nobody@groupstudy.com; 'Anthony
Sequeira'; 'Eddie Parra'
Cc: 'Paul Borghese'; 'Mike Ollington'; 'Ed Lui'; ccielab@groupstudy.com
Subject: RE: Preventing an EIGRP/OSPF Neighbor Forming
Scott, I think the error in what you demonstrate below is expecting a
neighbor to form when you have issued the passive interface command,
that will never happen for eigrp. I stand by waht I said :) you do not
need multicast packets for a neighbor to form with EIGRP. Where I think
several people seem to be misunderstanding this is expecting passive
interface to turn off multicast for EIGRP. passive interface does turn
off multicast packets, but it also disallows unicast packets.
This is the configuration and output I am referring to
R1-------R2 connected over a serial link
R1 is configured thus
router eigrp 1
network 172.16.31.1 0.0.0.0
neighbor 172.16.31.2 Serial3/0
auto-summary
R2 is configured thus
router eigrp 1
network 172.16.31.2 0.0.0.0
neighbor 172.16.31.1 Serial1/0
auto-summary
With this setup, no multicast packets are sent by either router, the
output of debug ip packet shows the following
22:53:36.959: IP: s=172.16.31.1 (local), d=172.16.31.2 (Serial3/0), len
60, sending
22:53:40.283: IP: s=172.16.31.2 (Serial3/0), d=172.16.31.1 (Serial3/0),
len 60, rcvd 3
22:53:41.467: IP: s=172.16.31.1 (local), d=172.16.31.2 (Serial3/0), len
60, sending
22:53:45.143: IP: s=172.16.31.2 (Serial3/0), d=172.16.31.1 (Serial3/0),
len 60, rcvd 3
22:53:46.435: IP: s=172.16.31.1 (local), d=172.16.31.2 (Serial3/0), len
60, sending
22:53:49.719: IP: s=172.16.31.2 (Serial3/0), d=172.16.31.1 (Serial3/0),
len 60, rcvd 3
22:53:51.067: IP: s=172.16.31.1 (local), d=172.16.31.2 (Serial3/0), len
60, sending
2 22:53:54.375: P: s=172.16.31.2 (Serial3/0), d=172.16.31.1 (Serial3/0),
len 60, rcvd 3
22:53:56.059: IP: s=172.16.31.1 (local), d=172.16.31.2 (Serial3/0), len
60, sending
22:53:59.355: IP: s=172.16.31.2 (Serial3/0), d=172.16.31.1 (Serial3/0),
len 60, rcvd 3
22:54:00.887: IP: s=172.16.31.1 (local), d=172.16.31.2 (Serial3/0), len
60, sending
22:54:04.303: IP: s=172.16.31.2 (Serial3/0), d=172.16.31.1 (Serial3/0),
len 60, rcvd 3
The neighbors stay stable as shown below:
Router1#sho ip eigrp nei
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q
Seq
(sec) (ms) Cnt
Num
0 172.16.31.2 Se3/0 11 00:06:57 112 672 0
1
Router1#
Scott Morris <swm@emanon.com> wrote:
I'll beg to differ on this one. There are a few Cisco docs about
it "not
working as you may think". In RIP you would be correct about
exchanging
routes ONLY as unicast. In EIGRP, the multicast hellos must be
present
though.
Lab output:
Emanon-R5(config)#router eigrp 100
Emanon-R5(config-router)#network 113.13.13.0
Emanon-R5(config-router)#network 172.17.155.0
44w6d: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
113.13.13.106
(Ethernet0/0) is up: new adjacency
Emanon-R5(config-router)#neighbor 113.13.13.106 ethernet0/0
Emanon-R5(config-router)#
44w6d: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
113.13.13.106
(Ethernet0/0) is down: Remote peer static/dynamic
Emanon-R5(config-router)#
44w6d: destroy peer: 113.13.13.106
Emanon-R5(config-router)#
44w6d: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
113.13.13.106
(Ethernet0/0) is up: new adjacency
Emanon-R5(config-router)#pass e0/0
Emanon-R5(config-router)#
44w6d: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
113.13.13.106
(Ethernet0/0) is down: interface passive
Emanon-R5(config-router)#
44w6d: destroy peer: 113.13.13.106
Emanon-R5(config-router)#
Emanon-R5(config-router)#
Emanon-R5(config-router)#(it's been 10 minutes)
Emanon-R5(config-router)#do sh ip ei n
IP-EIGRP neighbors for process 100
Emanon-R5(config-router)#(it's been 10 more minutes)
Emanon-R5(config-router)#do sh ip prot
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is in effect
Automatic address summarization:
113.0.0.0/8 for Serial0/1
Summarizing with metric 281600
Maximum path: 4
Routing for Networks:
113.0.0.0
172.17.0.0
Passive Interface(s):
Ethernet0/0
Routing Information Sources:
Gateway Distance Last Update
(this router) 90 00:20:12
113.13.13.106 90 00:19:52
Distance: internal 90 external 170
Emanon-R5(config-router)#
Emanon-R5(config-router)# (After 20 minutes and a can of
Mountain Dew, I
still have no neighbors with the multicast disabled)
We could probably do some obnoxious NAT stuff though to convert
into a full
unicast, but that would likely be evil. I believe someone else
had posted a
config down this path.
HTH,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf Of
Chris Lewis
Sent: Friday, December 02, 2005 9:37 AM
To: Schulz, Dave; nobody@groupstudy.com; Anthony Sequeira; Eddie
Parra
Cc: Paul Borghese; Mike Ollington; Ed Lui;
ccielab@groupstudy.com
Subject: RE: Preventing an EIGRP/OSPF Neighbor Forming
You do not need to have multicast hellos for an EIGRP neighbor
relationship
to form. The restriction is that if one neighbor is using
unicast, the other
must too.
Chris
"Schulz, Dave" wrote:
I thought that you needed to have multicast hellos present in
order
for the neighbor relationship to form...even if you configure
unicast via
the neighbor command. Is this not the case? Do I have this
wrong?
Dave
-----Original Message-----
From: nobody@groupstudy.com
To: Anthony Sequeira; Eddie Parra
Cc: Chris Lewis; Paul Borghese; Mike Ollington; Ed Lui;
ccielab@groupstudy.com
Sent: 12/1/2005 8:47 PM
Subject: Re: Preventing an EIGRP/OSPF Neighbor Forming
Basically if you do not use passive-interface, two routers can
form a
relationship if they are BOTH configured with neighbor
statements.
The behavior is EIGRP is different to things like RIP. EIGRP
cannot
(currently in released versions) form a neighbor relationship if
one
neighbor sends multicast and the other sends unicast.
When you configure a neighbor addresses, the interface that the
unicast
hellos go through stop sending multicast hellos.
This can be fixed in newer releases and you may see one eigrp
speaker
sending multicast neighbor up to an eigrp speaker sending
unicast in the
future.
Chris
Anthony Sequeira wrote:
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:
<<
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:
<<<<
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 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 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 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 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
> > >
**********************************************************************
> > >
> > >
> >
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3