From: Igor Manassypov (imanassypov@rogers.com)
Date: Tue Jul 15 2008 - 16:35:31 ART
they usually say something like 'passively watch traffic'
Cisco Addicted <cisco.addicted@gmail.com> wrote: Dears,
I have some confusion about the TCP intercept mode, I understand the
difference between the two modes, but don't know one to use this in the lab.
I mean what will be the keywords to use specific mode (intercept | watch)???
Thanks gangs.
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: Tuesday, July 15, 2008 9:54 PM
To: Jonathan Greenwood II
Cc: Cisco Addicted; Peter Stephan; Nate Cielieska; Igor Manassypov; GS
CCIE-Lab
Subject: Re: rip passive int with neighbor command
Actually there is another important point to be added onto this. EIGRP only
uses multicast to discover neighbors and for periodic keepalives. The
actual exchange of the topology table is done through unicast. This means
that by default EIGRP actually uses multicast AND unicast, but if you use
the neighbor statement it uses JUST unicast. The fact that the neighbor
statement suppresses the multicast hello/keepalive implies that any other
neighbors on the segment also need to unicast their hellos/keepalives,
otherwise they will never discover each other. You can see this operation
in action if you "debug ip packet detail". Take the following case with R1
having the address 10.0.0.1 and forming adjacency with the neighbor
10.0.0.2.
R1 initializes its EIGRP process.
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 0.0.0.0
R1(config-router)#end
R1#
Hellos are multicast out all links running EIGRP.
Jul 15 11:39:54.695: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
len 60, sending broad/multicast, proto=88
Jul 15 11:39:54.699: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), len
60, sending broad/multicast, proto=88
Jul 15 11:39:54.699: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, rcvd
2, proto=88
A hello packet comes in from 10.0.0.2 via multicast and neighbor adjacency
occurs.
Jul 15 11:39:54.707: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60,
rcvd 2, proto=88
Jul 15 11:39:54.711: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.2
(FastEthernet0/0) is up: new adjacency
The topology is exchanged via unicast.
Jul 15 11:39:54.711: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), routed via RIB
Jul 15 11:39:54.711: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), len 40, rcvd 3, proto=88
Jul 15 11:39:54.715: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
len 60, sending broad/multicast, proto=88
Jul 15 11:39:54.719: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0),
len 40, sending, proto=88
Jul 15 11:39:54.719: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 77,
rcvd 2, proto=88
Jul 15 11:39:54.723: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 69,
rcvd 2, proto=88
Jul 15 11:39:54.727: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
len 77, sending broad/multicast, proto=88
Jul 15 11:39:54.727: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
len 69, sending broad/multicast, proto=88
Jul 15 11:39:54.731: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), routed via RIB
Jul 15 11:39:54.731: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), len 69, rcvd 3, proto=88
Jul 15 11:39:54.735: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), routed via RIB
Jul 15 11:39:54.735: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), len 40, rcvd 3, proto=88
Jul 15 11:39:54.739: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0),
len 69, sending, proto=88
Jul 15 11:39:54.747: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), routed via RIB
Jul 15 11:39:54.747: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), len 69, rcvd 3, proto=88
Jul 15 11:39:54.751: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), routed via RIB
Jul 15 11:39:54.755: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), len 40, rcvd 3, proto=88
Jul 15 11:39:54.755: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0),
len 40, sending, proto=88
Jul 15 11:39:54.963: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0),
len 69, sending, proto=88
Jul 15 11:39:54.971: IP: tableid=0, s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), routed via RIB
Jul 15 11:39:54.971: IP: s=10.0.0.2 (FastEthernet0/0), d=10.0.0.1
(FastEthernet0/0), len 40, rcvd 3, proto=88
Jul 15 11:39:55.139: %SYS-5-CONFIG_I: Configured from console by console
R1#
Once converged only periodic multicast hellos are exchanged until something
changes in the topology.
Jul 15 11:39:59.551: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60,
rcvd 2, proto=88
Jul 15 11:39:59.579: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), len
60, sending broad/multicast, proto=88
Jul 15 11:39:59.579: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, rcvd
2, proto=88
Jul 15 11:39:59.687: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
len 60, sending broad/multicast, proto=88
Jul 15 11:40:04.202: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
len 60, sending broad/multicast, proto=88
Jul 15 11:40:04.495: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), len
60, sending broad/multicast, proto=88
Jul 15 11:40:04.495: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, rcvd
2, proto=88
Jul 15 11:40:04.539: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60,
rcvd 2, proto=88
Jul 15 11:40:08.838: IP: s=10.0.0.1 (local), d=224.0.0.10 (FastEthernet0/0),
len 60, sending broad/multicast, proto=88
Jul 15 11:40:09.190: IP: s=10.0.0.2 (FastEthernet0/0), d=224.0.0.10, len 60,
rcvd 2, proto=88
Jul 15 11:40:09.270: IP: s=1.1.1.1 (local), d=224.0.0.10 (Loopback0), len
60, sending broad/multicast, proto=88
Jul 15 11:40:09.270: IP: s=1.1.1.1 (Loopback0), d=224.0.0.10, len 60, rcvd
2, proto=88
HTH,
Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
Online Community: http://www.IEOC.com
CCIE Blog: http://blog.internetworkexpert.com
Jonathan Greenwood II wrote:
Peter well said you hit it right on the nail.
On Tue, Jul 15, 2008 at 12:38 PM, Cisco Addicted
wrote:
Peter,
Thank you very much for the sharp and bright clarification. Really you
shot
the head of this issue.
Regards.
Moe
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Peter Stephan
Sent: Tuesday, July 15, 2008 7:42 PM
To: 'Nate Cielieska'; 'Igor Manassypov'
Cc: 'Jonathan Greenwood II'; 'GS CCIE-Lab'
Subject: RE: rip passive int with neighbor command
Just to remember:
In EIGRP:
If you enable unicast updates on an interface, you DISABLE multicasting
updates to 224.0.0.10 through that particular interface.
In RIP v2:
If you enable unicast updates on an interface (through neighbor cmd), you
'DO NOT STOP' multicasting updates.
You use then passive-interface to stop multicasting updates if it was
required.
Don't confuse yourself... just remember in EIGRP you either have unicast or
multicast, in RIP you can have both (unless you use passive-int).
Cheers,
Peter.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nate
Cielieska
Sent: Tuesday, July 15, 2008 8:24 PM
To: Igor Manassypov
Cc: Jonathan Greenwood II; GS CCIE-Lab
Subject: Re: rip passive int with neighbor command
Igor,
When you turn on unicast updates with the "neighbor x.x.x.x" command, this
does not disable the multicast updates out of that interface. It merely
sends that particular neighbor a unicast update and sends out a
224.0.0.9multicast update as well.. to stop the multicast updates you used
the passive-interface command. The passive-interface command has no bearing
on your unicast updates so your updates will be seen on your router..
meeting your requirements.
Regards,
Nate
On Tue, Jul 15, 2008 at 10:58 AM, Igor Manassypov
wrote:
if I configure that interface on which my neighbor sits as passive,
and I also configure a neighbor command explicitly, are routes going
to be exchanged?
Jonathan Greenwood II wrote:
Igor when you use the
neighbor command you are sending RIP updates via unicast by
specifiying the IP Address of the neighboring router as opposed to the
multicast address 224.0.0.9 which all rip enabled interfaces listen
on. Passive interface with RIP doesn't allow updates to be sent out
the interface but an interface can still receive updates from my
understanding.
To actually form the neighbor relationship the interface should not be
configured for passive interface. You could also peform RIP
authentication on both sides depending on the requirements/restrictions
of
the question.
HTH
Jonathan
On Tue, Jul 15, 2008 at 9:44 AM, Igor Manassypov
wrote:
Could someone please clarify rip's neighbor command mixed with a
passive-interface? For example, if you are asked to make sure that
routing
updates are only sent to a particular router, I will configure a
corresponding 'neighbor' entry under my rip process, but to satisfy
the requirement that only that particular router gets updates I
would also
need
to enable the passive interface. As soon as I do that, there are no
more routing updates coming from that interface even though I have
an explicit neighbor configured... If I do not use the passive
interface, then other routers will get updates breaking the
requirement...
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART