From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Tue Oct 28 2008 - 02:12:43 ARST
Hey Huan,
Sure, glad to help - I had a few theories I wanted to explore but none
ultimately panned out. But how odd that I was able to duplicate your
observed behavior on a 3725 but not a 3640?! Either way, it does seem that
the traffic is hitting the interface. One plausible moral of this story
might be that debug (or for that matter ACL counters) cannot entirely be
trusted to tell us the full story -- at least not always the exact debug (or
counters) we _expect_ to tell us the full story...
Cheers,
Scott
-----Original Message-----
From: Huan Pham [mailto:Huan.Pham@peopletelecom.com.au]
Sent: Monday, October 27, 2008 9:58 PM
To: Scott M Vermillion; Cisco certification
Subject: RE: ACL does not match multicast traffic (RIP updates)
Hi Scott,
Thanks for looking into this issue. I am running physical routers,
version is as below.
Rack1R4#sh ver | in IOS
Cisco IOS Software, 3600 Software (C3640-JK9O3S-M), Version 12.4(5a),
RELEASE SOFTWARE (fc3)
Cheers,
Huan
-----Original Message-----
From: Scott M Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Tuesday, 28 October 2008 2:06 PM
To: Huan Pham; 'Cisco certification'
Subject: RE: ACL does not match multicast traffic (RIP updates)
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