From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Tue Oct 28 2008 - 01:05:43 ARST
Hi Huan,
First question I want to ask you is whether or not you are running Dynamips
or physical devices? I'm not asking this because I think Dynamips is the
"problem," but because I want to know if you can run the capture function of
Dynagen. I had a lab up on my Windows box this evening. It was a fairly
old lab that predates my switch to the 3700s. It runs the following code:
Cisco IOS Software, 3600 Software (C3640-JS-M), Version 12.4(17), RELEASE
SOFTWARE
When I set up a small topology similar to yours (running RIPv2 on just one
of two devices), I could see the ACL hits and I was seeing the traffic being
dropped as "unroutable" in my 'debug ip packet det' logging messages.
I then kicked off a different lab on a different machine running the
following code:
Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version
12.4(17), RELEASE SOFTWARE (fc1)
With an identical topology, I could neither see ACL hits nor was I getting
anything returned from 'debug ip packet det'. Hmmm.
So I kicked off the capture function on the non-RIP speaking devices in both
labs and I could clearly see that the inbound 224.0.0.9 traffic was hitting
*both* interfaces. It was simply the case that the 3640 was "loudly"
dropping the traffic, whereas the 3725 was "silently" dropping it.
Lastly, I converted my RIP-speaker to V1 in the 3725 lab (didn't seem
necessary to try that with the 3640 since that platform was logging the
traffic as it was). I was able to observe both ACL hits and debug. This
isn't really surprising to me, given that the all-ones broadcast traffic
needs to be locally processed prior to being dropped.
So if you're running Dynamips, you may want to do a capture and have a look.
Otherwise, you'll need to get a bit more elaborate in order to grab that
traffic for analysis (although I doubt you'd so much as break a sweat in the
face of that small task!).
Let us know what, if anything, you find, but it appears to simply be a
"cosmetic" difference between platforms/IOS from what I can see...
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Huan
Pham
Sent: Monday, October 27, 2008 4:38 PM
To: Cisco certification
Subject: ACL does not match multicast traffic (RIP updates)
Hi GS,
I am doing a simple lab in IEWB1 v5, trying to match all RIP traffic
coming to an interface, but I saw a weird problem. If the router does
not run RIP, and the RIP traffic coming to the interface are multicast,
then my ACL does not match any packets at all. Is there any special
thing I need to do to be able to catch those traffic? Any suggestion
pls, Thanks.
I've tried a couple of tricks but none can explain what I described
above.
Here's what I tried.
Topology:
155.1.146.0/24
R4 ----------------------- R6
Fa0/1 Fa0/0.146
ACL uses UDP 520 to match RIP
RIP traffic is coming from R6 (running RIP ver2). I have ACL on R4.
If R4 does not run RIP ver2, then ACL does not match any RIP traffic.
If R4 run RIP ver 2, then ACL does catch RIP traffic from R6.
If R4 does not run RIP, but R6 run RIPv1, then ACL also match RIP
traffic.
Rack1R4#
ip access-list extended LOGGING
permit udp any any eq rip log-input
permit ip any any
int fa0/1
ip access-group LOGGING in
R4 does not have RIP running yet.
Rack1R4#sh access-list
Extended IP access list LOGGING
10 permit udp any any eq rip log-input <<<<<<<<< NO MATCHES
20 permit ip any any (189 matches)
Rack1R4#c
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R4(config)#router rip
Rack1R4(config-router)#net 155.1.0.0
Rack1R4(config-router)#
Rack1R4#
Rack1R4#
*Apr 7 12:35:07.011: %SEC-6-IPACCESSLOGP: list LOGGING permitted udp
155.1.146.6(520) (Ethernet1/0 00d0.58f7.a961) -> 224.0.0.9(520), 1
packet
Rack1R4#sh access-list
Extended IP access list LOGGING
10 permit udp any any eq rip log-input (5 matches) <<<<<< MACTCHES
20 permit ip any any (240 matches)
CHANGE R6 from running RIP ver2 to Ver1, and Remove RIP from R4
Rack1R4(config)#no router rip
Rack1R6(config-router)#router rip
Rack1R6(config-router)#ver 1
Rack1R6(config-router)#
Rack1R4#
*Apr 7 12:37:26.211: %SEC-6-IPACCESSLOGP: list LOGGING permitted udp
155.1.146.6(520) (Ethernet1/0 00d0.58f7.a961) -> 255.255.255.255(520), 1
packet
Rack1R4#sh access-list
Extended IP access list LOGGING
10 permit udp any any eq rip log-input (5 matches) <<<<<<< MATCHES
20 permit ip any any (18 matches)
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:23 ARST