[nsp] Filter-Id for AS5300
Srdjan Simic
srdjan at sezampro.yu
Fri Aug 1 15:46:30 EDT 2003
Unfortunately all my traffic from vaccess is process, and I do have ip cef and I do NOT have any log lines in access list. Do you have an idea why?
Virtual-Access11
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 627 58441 8 160
Route cache 0 0 595 246113
Total 627 58441 603 246273
I will try to find 12.3(1.5) and report whether it is ok or not.
Srdjan
-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
Sent: Friday, August 01, 2003 2:33 PM
To: Srdjan Simic; mtinka at africaonline.co.ug
Cc: cisco-nsp at puck.nether.net
Subject: RE: [nsp] Filter-Id for AS5300
Hi,
> No I am talking about vaccess on LNS.
Ah, ok, sorry.. the thread was about AS5300, so I jumped to a conclusion
too soon :)
> We are terminating L2TP
> users on 3640. When I do "sho ip int" there is access list, but I
> tried myself to connect and stuff that are supposed to be forbidden
> are not.
were you trying to reach sites while you were logged in at the LNS? You
are aware that outgoing ACLs are not checked for locally generated
traffic (i.e. from the router)? This has been day-one behaviour in IOS.
> Further more counters on incoming access lists are not
> incrementing and on outgoing are. It looks that something turned off
> in access list :) because there are some hits, but the numbers are
> way to low.
Ok. You are probably hitting CSCea19800. This affects process-switched
traffic only, so after enabling "ip cef" and making sure that there is
no "log" anywhere in the ACL which would punt the transit pkts to
process-path, you should be fine for transit traffic through the LNS.
Traffic directed to your router might still be permitted, so you want to
grab an IOS which has the fix (currently only a 12.3(1.5) or later
interim, but 12.3(3) will be out later this month).
oli
> -----Original Message-----
> From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
> Sent: Friday, August 01, 2003 12:23 PM
> To: Srdjan Simic; mtinka at africaonline.co.ug
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [nsp] Filter-Id for AS5300
>
>
> Hi,
>
> > After comparing this, I found out that access list are NOT
> > applied to virtual-access interfaces, even though it says in the
> > "sh ip int" output (on 12.3(1a)):
> >
> > Outgoing access list is f20po, default is not set
> > Inbound access list is f20pi, default is not set
> >
> > I switched back to 12.2(8)T and filters work. We are using Radius
> > code 11 (Filter-ID). We are using this for VPDN (L2TP).
>
> Hmm, you are not trying to filter VPDN/L2TP users on the LAC, aren't
> you? There is no vaccess interface on the LAC for the user as we don't
> terminate the PPP connection, so you're probably talkin about a
> locally terminated ppp user?!
>
> Just checked with 12.3(1a) on an AS5300: per-user ACLs are correctly
> applied and enforced on a vaccess. What makes you think they are not
> applied/enforced?
>
> See below..
>
> oli
>
>
> dialin1 Password = "test"
> Service-Type=Framed-User
> Framed-Protocol = PPP,
> Framed-IP-Address="5.5.5.5",
> Filter-Id="aclin.in",
> Filter-Id="aclout.out",
> Cisco-avpair="lcp:timeout=60"
>
> AS5300B#sh ver | i IOS
> IOS (tm) 5300 Software (C5300-IS-M), Version 12.3(1a), RELEASE
> SOFTWARE (fc1)
> AS5300B#sh ip int vi2 | i access list
> Outgoing access list is aclout, default is not set
> Inbound access list is aclin, default is not set
> AS5300B#sh access-l
> Extended IP access list aclin
> 10 deny ip any any (4 matches)
> Extended IP access list aclout
> 10 deny ip any any
> AS5300B#
> *Feb 5 23:02:31.611: ICMP: dst (20.20.20.20) administratively
> prohibited unreachable sent to 5.5.5.5
> *Feb 5 23:02:32.123: ICMP: dst (20.20.20.20) administratively
> prohibited unreachable sent to 5.5.5.5
> *Feb 5 23:02:34.619: ICMP: dst (20.20.20.20) administratively
> prohibited unreachable sent to 5.5.5.5
> AS5300B#sh access-l
> Extended IP access list aclin
> 10 deny ip any any (15 matches)
> Extended IP access list aclout
> 10 deny ip any any
> AS5300B#
> *Feb 5 23:02:50.019: ICMP: dst (5.5.5.5) administratively prohibited
> unreachable sent to 10.0.0.8
> *Feb 5 23:02:51.011: ICMP: dst (5.5.5.5) administratively prohibited
> unreachable sent to 10.0.0.8
> *Feb 5 23:02:52.011: ICMP: dst (5.5.5.5) administratively prohibited
> unreachable sent to 10.0.0.8
> *Feb 5 23:02:53.011: ICMP: dst (5.5.5.5) administratively prohibited
> unreachable sent to 10.0.0.8
> *Feb 5 23:02:54.011: ICMP: dst (5.5.5.5) administratively prohibited
> unreachable sent to 10.0.0.8
> *Feb 5 23:02:55.011: ICMP: dst (5.5.5.5) administratively prohibited
> unreachable sent to 10.0.0.8
> *Feb 5 23:02:56.011: ICMP: dst (5.5.5.5) administratively prohibited
> unreachable sent to 10.0.0.8
> AS5300B#sh access-l
> Extended IP access list aclin
> 10 deny ip any any (15 matches)
> Extended IP access list aclout
> 10 deny ip any any (14 matches)
> AS5300B#
>
>
>
> >
> > -----Original Message-----
> > From: Mark Tinka [mailto:mtinka at africaonline.co.ug]
> > Sent: Friday, August 01, 2003 8:48 AM
> > To: 'Oliver Boehmer (oboehmer)'; Srdjan Simic
> > Cc: cisco-nsp at puck.nether.net
> > Subject: RE: [nsp] Filter-Id for AS5300
> >
> >
> > Oliver Boehmer (oboehmer) wrote:
> > > Hi,
> > >
> > > I think we are talking about two different problems, even though
> > > they look similar:
> > >
> > > > Srdjan Simic wrote:
> > > > > We had the same problem. sh run did not show acl, but sh
> > > > > access-list did, and besides the name there was "(per-user)".
> > > > > This was with IOS 12.2(8)T and C3640. We were in big trouble,
> > > > > because we could not save the config. After first lookups, it
> > > > > seems that, when the router boots, everything is ok. When the
> > > > > first user comes and requests a filter set, that filter set is
> > > > > removed from running config. We switched to other IOS and that
> > > > > solved the problem. Currently we are on 12.3(1a) but we also
> > > > > tried 12.2(17a) and
> > > > > 12.2(7a) .and
> > >
> > > This problem has been described in CSCdx52334 (and has been fixed
> > > in
> > > 12.2(13)T/12.2(13) and other releases). Every per-user ACL
> > > effectivly turned on the "per-user" flag on existing ACLs
> > > configured on the box and thus prevented them from being saved
> > > (per-user ACLs are dynamic and are never saved).
> > >
> > >
> > > > So you say that after a reboot [I haven't yet tried], the
> > > > configuration remains intact [albeit invisible], and that the
> > > > named access list will work even when it doesn't show up in the
> > > > running configuration.
> > >
> > > No, I doubt this, unless the ACL is present in the startup-config
> > > (which it isn't if you did a "write" after the box booted).
> > >
> > > > Well, I am running 12.3(1a) too, but I am exhibiting this
> > > > problem. I never tried using this named access list on my
> > > > previous IOS, so I can't really say whether the problem is with
> > > > 12.3.
> > >
> > > The behaviour you're seeing with 12.3(1a) is definitly a bug and
> > > needs to be fixed. It could be a race condition, maybe some user's
> > > profile referenced the ACL before or while (?) it was being
> > > defined. I also saw this problem with 12.2(2)XB11, but only on
> > > one of 100+ routers using the same config.
> > >
> > > Can you please try the following: Use "copy tftp startup-config"
> > > to write a complete config (including the ACL) directly into the
> > > NVRAM and do a reload. The system will then come up with the ACL,
> > > and the problem should be solved. If not, it would be very
> > > interesting to see what triggered the problem, but might be
> > > difficult to find out. I'll try to repro this internally..
> > >
> > > Tx,
> > > oli
> >
> > Hi Oli. Thanks for your response.
> >
> > I did as you suggested, and copied the configuration from my TFTP
> > server straight into NVRAM. I reloaded, and it works fine. The
> > configuration is present in the running-config file, and the
> > (per-user) flag is no longer present on the show access-list
> > command:
> >
> > AS5300#sh access-lists emailonly
> > Extended IP access list emailonly
> > 10 permit tcp any any eq smtp (14 matches)
> > 20 permit tcp any any eq pop3 (1207 matches)
> > 30 permit tcp any any eq domain
> > 40 permit udp any any eq domain (54 matches)
> > 50 permit tcp any host x.x.x.x eq www
> > 60 permit tcp any host x.x.x.x eq www
> > 70 permit tcp any host x.x.x.x eq www
> > 80 permit tcp any host x.x.x.x eq 443
> > 90 permit icmp any any echo (2 matches)
> > 100 permit icmp any any echo-reply
> > 110 permit tcp any eq smtp any
> > 120 permit tcp any eq pop3 any
> > 130 permit tcp host x.x.x.x eq www any
> > 140 permit tcp host x.x.x.x eq www any
> > 150 permit tcp host x.x.x.x eq www any
> > 160 permit tcp host x.x.x.x eq 443 any
> > 170 permit tcp any eq domain any
> > 180 permit udp any eq domain any
> > 190 deny ip any any (429 matches)
> > AS5300#
> >
> > Many thanks for this workaround.
> >
> > Regards,
> >
> > Mark Tinka - CCNA
> > Network Engineer, Africa Online Uganda
More information about the cisco-nsp
mailing list