From: Andy Mrozek (AndyMrozek@yahoo.com)
Date: Sun Aug 22 2004 - 20:15:58 GMT-3
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