From: marc van hoof (mvh@marcvanhoof.com)
Date: Sun Aug 22 2004 - 20:09:29 GMT-3
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