From: Andy Mrozek (AndyMrozek@yahoo.com)
Date: Sun Aug 22 2004 - 21:00:51 GMT-3
root@toucan:~# tcpdump -i eth0
tcpdump: listening on eth0
04:54:52.790039 802.1d config
04:54:57.041663 172.16.0.2.router > RIP2-ROUTERS.MCAST.NET.router:
RIPv2-resp [items 1]:
04:55:06.437639 172.16.0.1.router >RIP2-ROUTERS.MCAST.NET.router:
RIPv2-resp [items 11]:
04:55:22.729192 172.16.0.2.router >RIP2-ROUTERS.MCAST.NET.router:
RIPv2-resp [items 1]:
{60-60-60-0.rev.home.ne.jp/255.255.255.0}(15) [tos
0xc0]
04:55:22.790524 802.1d config
8001.00:0b:5f:90:6e:80.8013 root
8001.00:0b:5f:90:6e:80 pathcost 0 age 0 max 20 hello 2
fdelay 15
04:55:24.533250 0:b:5f:90:6e:93 0:b:5f:90:6e:93
loopback 60:
0000 0100 0000 0000 0000 0000
0000 0000
0000 0000 0000 0000 0000 0000
0000 0000
0000 0000 0000 0000 0000 0000
0000
04:55:24.790473 802.1d config
8001.00:0b:5f:90:6e:80.8013 root
8001.00:0b:5f:90:6e:80 pathcost 0 age 0 max 20 hello 2
fdelay 15
04:55:25.360763 0:b:5f:90:6e:93 > 1:0:c:cc:cc:cc snap
ui/C len=35
04:55:25.360886 0:b:5f:90:6e:93 > 1:0:c:0:0:0 snap
ui/C len=65
29 packets received by filter
0 packets dropped by kernel
root@toucan:~#
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
john matijevic
Sent: Sunday, August 22, 2004 4:41 PM
To: 'marc van hoof'; AndyMrozek@yahoo.com; ccielab@groupstudy.com
Subject: RE: CiscoPress CCIE RS lab book - Lab 1 Rip unicast without
neighbors question ?????
Hi Andy,
What is happening is when you put a neighbor statement rip will unicast
the updates to that neighbor. This is why you see the unicast in the
debug ip rip command. Because we don't have the neighbor statement, rip
is still going to multicast. Thus, that is why you seen the multicast in
the debug ip rip process. However, once the packet leaves the router,
the nat process separate from the rip process, will translate the
multicast to unicast via the NAT statement. That is why we have to
observe the behavior via deb ip nat det and deb ip packet detail. As far
as attaching a sniffer, are you seeing the multicast come specifically
from R3, Can you provide sniffer output?
Sincerely,
John Matijevic, CCIE #13254, MCSE, CNE, CCEA
CEO
IgorTek Inc.
151 Crandon Blvd. #402
Key Biscayne, FL 33149
Hablo Espanol
305-321-6232
http://home.bellsouth.net/p/PWP-CCIE
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
marc van hoof
Sent: Sunday, August 22, 2004 7:23 PM
To: AndyMrozek@yahoo.com; 'john matijevic'; ccielab@groupstudy.com
Subject: RE: CiscoPress CCIE RS lab book - Lab 1 Rip unicast without
neighbors question ?????
Are you sure that it's R3 that's throwing the packets out there as
unicast
and not R2 with a forgotten passive-interface statement ?
> -----Original Message-----
> From: Andy Mrozek [mailto:AndyMrozek@yahoo.com]
> Sent: Monday, 23 August 2004 9:16 AM
> To: 'marc van hoof'; 'john matijevic'; ccielab@groupstudy.com
> Subject: RE: CiscoPress CCIE RS lab book - Lab 1 Rip unicast without
> neighbors question ?????
>
> The other RIP speakers are seeing unicast.... So on that given
broadcast
> domain we have 2 RIP speakers R3 / R2 ... So in the book they show a
debug
> ip packet detail on R2 and sure enough he sees a unicast from
R3....... So
> I
> guess that meets the problem statements requirements of " r3 must
unicast
> rip updates to r2 dont use neighbor/passive interface" solution......
What
> I
> am observing.... is when you typically need to have rip unicast you
use
> neighbor x.x.x.x / passive-interface eth0 ...... When this config is
> applied and you debug ip rip from that same router you no longer see "
> sending rip v2 updates to 224.0.0.9" you now see "sending rip v2
updates
> to
> x.x.x.x" And if you sniff that connection sure enough you will not
even
> know rip would be running unless of coure you are arpspoofing / or
> mirroring
> switch port.... but lets say were not..... So with lab 1 solution
there
> saying nat will force r3 to send unicast updates to r2... Which if you
> look
> at the debug ip nat detail and debug ip packet detail ... from both
the
> source r3 router and destination r2 router you would say .... hey that
is
> cool it is now unicast..... But if you put a sniffer on that segment
or if
> you use " debug ip rip " you see no evidence of unicast I still see
rip
> updates to 224.0.0.9 destination....... So yes the nat seems to send a
> unicast to r2 now .. .but also sends the multicast 224.0.0.9 ......
>
> -----Original Message-----
> From: marc van hoof [mailto:mvh@marcvanhoof.com]
> Sent: Sunday, August 22, 2004 4:09 PM
> To: 'Andy Mrozek'; 'john matijevic'; ccielab@groupstudy.com
> Subject: RE: CiscoPress CCIE RS lab book - Lab 1 Rip unicast without
> neighbors question ?????
>
>
> So you're trying to use NAT to turn a multicast address into a unicast
> address...
>
> Do you see ANY packets working as unicasts ? I would get on the other
> router, set up an access list to match rip, and debug ip packets based
on
> the access list.
>
> Is it seeing unicast, multicast, or both ?
>
> -marc.
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> > Andy Mrozek
> > Sent: Monday, 23 August 2004 9:02 AM
> > To: 'john matijevic'; ccielab@groupstudy.com
> > Subject: RE: CiscoPress CCIE RS lab book - Lab 1 Rip unicast without
> > neighbors question ?????
> >
> > Thanks John,
> >
> > I see what Maurillio was debugging there and totally get that this
> proves
> > it
> > is unicast from the output of the debug .... But if you debug ip rip
> ....
> > it
> > is showing that it is still multicasting... I thought maybe the rip
> debug
> > was seeing it before the nat process , so I through a sniffer on
that
> > broadcast domain ... and sure enough with the solution that is shown
> there
> > ..... You still see the 224.0.0.9 traffic indicating that r3 is
still
> > sending a loud annoying message to all devices on that broadcast
domain
> > ...
> > I also rebooted routers ... The switch is 3550 emi and only 2
devices on
> > it
> > are as depiced in lab r3 and r2... I just want to be sure that that
> method
> > is actually taking broadcast and turing to unicast... As sniffer is
> saying
> > it is not....
> >
> > -----Original Message-----
> > From: john matijevic [mailto:matijevi@bellsouth.net]
> > Sent: Sunday, August 22, 2004 3:59 PM
> > To: 'Andy Mrozek'; ccielab@groupstudy.com
> > Subject: RE: CiscoPress CCIE RS lab book - Lab 1 Rip unicast without
> > neighbors question ?????
> >
> >
> > Hello Andy,
> > This is a great book I completely agree 100% with you, as I am
working
> > on Lab 4 myself and supporting these labs. AS far as not being able
to
> > see the unicast updates on R3. Did you try using debug ip nat detail
> > command. You should be able to see the coversion with that debug.
Just
> > don't forget to clear the route cache after running the debug. You
can
> > also run the deb ip packet detail on R2. This is listed on page 35
of
> > the book. I also have a forum on my website where you can discuss
these
> > labs.
> >
> > Sincerely,
> >
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> > CEO
> > IgorTek Inc.
> > 151 Crandon Blvd. #402
> > Key Biscayne, FL 33149
> > Hablo Espanol
> > 305-321-6232
> > http://home.bellsouth.net/p/PWP-CCIE
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> > Andy Mrozek
> > Sent: Sunday, August 22, 2004 6:43 PM
> > To: ccielab@groupstudy.com
> > Subject: CiscoPress CCIE RS lab book - Lab 1 Rip unicast without
> > neighbors question ?????
> >
> > When going through this great book , I thought the Rip with neighbor
/
> > passive interface was cool solution ...... So I tried it and was
> > debugging ,
> > and when setting up what they had for a solution ... and doing a
debug
> > ip
> > rip ....... r3 will still show sending update to 224.0.0.9 ??? I
also
> > put
> > a sniffer on this same vlan/broadcast domain and sure enough I still
see
> > broadcasts to the 224.0.0.9 group .... Has anyone else seen this ??
Here
> > is
> > output from both config methods ... Both neighbor/passive interface
and
> > nat
> > method....... I hope I did something wrong and nat is actually
> > unicasting ,
> > as that is cool way to take loud traffic and tune it down.......
> >
> >
> >
> >
> > ROUTER 3 SHOWING CISCO PRESS CCIE RS LAB PRACTICE LAB 1 PROBLEM
> > STATEMENT
> > STATING NOT TO USE NEIGHBOR METHOD TO UNICAST TO A GIVEN NEIGHBOR
BUT TO
> > USE
> > NAT.
> >
> > * This configuration is from the solution of lab 1 ... I still see
r3
> > sending
> > rip updates to a multicast address ?? And a sniffer on this
broadcast
> > domain
> > also see's this ? Both examples are running ios 12.2(15)T code ?? Is
> > there
> > an
> > order of operations issue here and debugging is seening it
afterwords ??
> > If
> > so
> > why would a sniffer see multicast traffic , after this nat solution
is
> > configured ???...
> >
> >
> >
> > interface Loopback0
> > ip address 60.60.60.1 255.255.255.0
> > !
> > interface Ethernet0
> > ip address 172.16.0.2 255.255.0.0
> > ip nat outside
> > !
> > interface Ethernet1
> > no ip address
> > shutdown
> > !
> > interface Serial0
> > no ip address
> > shutdown
> > no fair-queue
> > !
> > interface Serial1
> > no ip address
> > shutdown
> > !
> > router rip
> > version 2
> > passive-interface default
> > no passive-interface Ethernet0
> > offset-list 1 out 14 Ethernet0
> > network 60.0.0.0
> > network 172.16.0.0
> > no auto-summary
> > !
> > ip nat outside source static udp 172.16.0.1 520 224.0.0.9 520
extendable
> > ip http server
> > ip classless
> > !
> > !
> > access-list 1 permit 60.60.60.0 0.0.0.255 log
> > !
> >
> >
> >
> >
> >
> > r3#debug ip rip
> >
> > *Mar 1 03:15:01.279: RIP: sending request on Ethernet0 to 224.0.0.9
> > *Mar 1 03:15:03.227: RIP: sending v2 flash update to 224.0.0.9 via
> > Ethernet0
> > (172.16.0.2)*Mar 1 03:15:03.231: RIP: build flash update entries
> > *Mar 1 03:15:03.231: 60.60.60.0/24 via 0.0.0.0, metric 15, tag 0
> > *Mar 1 03:15:23.623: RIP: received v2 update from 172.16.0.1 on
> > Ethernet0
> > *Mar 1 03:15:23.627: 10.1.1.0/28 via 0.0.0.0 in 2 hops
> > *Mar 1 03:15:23.635: 10.4.4.0/29 via 0.0.0.0 in 3 hops
> > *Mar 1 03:15:23.639: 10.40.40.0/28 via 0.0.0.0 in 3 hops
> > *Mar 1 03:15:23.647: 10.80.80.0/24 via 0.0.0.0 in 2 hops
> > *Mar 1 03:15:23.651: 10.90.90.0/28 via 0.0.0.0 in 1 hops
> > *Mar 1 03:15:23.655: 10.100.100.0/28 via 0.0.0.0 in 2 hops
> > *Mar 1 03:15:25.635: RIP: sending v2 flash update to 224.0.0.9 via
> > Ethernet0
> > (172.16.0.2)*Mar 1 03:15:25.639: RIP: build flash update entries -
> > suppressing
> > null update*Mar 1 03:15:28.555: RIP: sending v2 update to 224.0.0.9
via
> > Ethernet0 (172.16.0.2)*Mar 1 03:15:28.559: RIP: build update
entries
> > *Mar 1 03:15:28.563: 60.60.60.0/24 via 0.0.0.0, metric 15, tag 0
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ROUTER 3 SHOWING TYPICAL WAY TO UNICAST RIP UPDATES TO A NEIGHBOR:
> >
> > *debug output changes and shows when a neighbor is defined that
instead
> > of
> > sending to 224.0.0.9 it sends to 172.16.0.1 the ip in the neighbor
> > statement.
> >
> > * We know typically when not using passive interface / neighbor
> > statement a
> > rip
> > enabled router will send to 224.0.0.9 , and you can see this with a
> > debug ip
> > rip
> >
> > * If you want to unicast to a neighbor for security reasons or what
not
> > rip
> > allows you to passive-interface / neighbor statement to change the
> > sending
> > rip
> > updates to 224.0.0.9 to the neighbor you specify and this can be
seen
> > with a
> > debug ip rip as seen below...
> >
> > * So this common config below gives proof that rip is sending direct
> > unicast
> > to
> > 172.16.0.1 , I also had a sniffer on this broadcast domain , and did
not
> > see
> > the
> > rip broadcast come over which on a switch normally you do
> >
> >
> >
> >
> >
> > r3#
> > hostname r3
> > !
> > boot-start-marker
> > boot-end-marker
> > !
> > !
> > username cisco privilege 15 password 0 cisco
> > no aaa new-model
> > ip subnet-zero
> > !
> > !
> > !
> > !
> > interface Loopback0
> > ip address 60.60.60.1 255.255.255.0
> > !
> > interface Ethernet0
> > ip address 172.16.0.2 255.255.0.0
> > !
> > interface Ethernet1
> > no ip address
> > shutdown
> > !
> > interface Serial0
> > no ip address
> > shutdown
> > no fair-queue
> > !
> > interface Serial1
> > no ip address
> > shutdown
> > !
> > router rip
> > version 2
> > passive-interface default
> > offset-list 1 out 14 Ethernet0
> > network 60.0.0.0
> > network 172.16.0.0
> > neighbor 172.16.0.1
> > no auto-summary
> > !
> > ip http server
> > ip classless
> > !
> > !
> > access-list 1 permit 60.60.60.0 0.0.0.255 log
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > r3#debug ip rip
> >
> > RIP protocol debugging is on
> > r3#
> > *Mar 1 03:01:49.035: RIP: sending v2 update to 172.16.0.1 via
Ethernet0
> > (172.16.0.2)*Mar 1 03:01:49.039: RIP: build update entries
> > *Mar 1 03:01:49.043: 60.60.60.0/24 via 0.0.0.0, metric 15, tag 0
> > *Mar 1 03:02:12.147: RIP: received v2 update from 172.16.0.1 on
> > Ethernet0
> > *Mar 1 03:02:12.147: 10.1.1.0/28 via 0.0.0.0 in 2 hops
> > *Mar 1 03:02:12.151: 10.4.4.0/29 via 0.0.0.0 in 3 hops
> > *Mar 1 03:02:12.155: 10.40.40.0/28 via 0.0.0.0 in 3 hops
> > *Mar 1 03:02:12.159: 10.80.80.0/24 via 0.0.0.0 in 2 hops
> > *Mar 1 03:02:12.163: 10.90.90.0/28 via 0.0.0.0 in 1 hops
> > *Mar 1 03:02:12.167: 10.100.100.0/28 via 0.0.0.0 in 2 hops
> > *Mar 1 03:02:18.691: RIP: sending v2 update to 172.16.0.1 via
Ethernet0
> > (172.16.0.2)*Mar 1 03:02:18.695: RIP: build update entries
> > *Mar 1 03:02:18.699: 60.60.60.0/24 via 0.0.0.0, metric 15, tag 0
> >
> >
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:47 GMT-3