From: marc van hoof (mvh@marcvanhoof.com)
Date: Sun Aug 22 2004 - 20:22:36 GMT-3
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
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:47 GMT-3