[nsp] ip verify unicast not logging in ACL

[Kinczli Zoltán]

hello,

  not sure as with bgp session should or should not drop, but the supressed drops are
because you have 'reachable-via any' configured -- sorry, in my prev mail i was not accurate enough...

  the logic is -- according to a white paper on uRPF:

lookup src ip addr
if entry found
 if ignore-def (==allow-default) specified and entry is default
  do drop-login & return
 if src of pack is different from FIB
  if exist-only (==reachable-via any) specified
    count supressed drop
  else
   do drop-logic & return
 pass packet & return
else
do drop-logic & return

and the srop-logic is:

if spec addr
  pass pack
else if ACL permits
  count supressed drop
  pass packet
else
  count drop
  drop packet

 

  asic based platform's behaviour might look stange in therms of RPF, i seem to recall, that loggin is not available for packs forwarded by the hw/asic/pfc. Perhaps that's the reason you only see logging for pack, being received by the msfc itself.

On the BGP session close: Check the bgp session src in the FIB and check the I/F (for RPF) you receive packets carryig the BGP session.

  
regards
 -zoltan

-----Original Message-----
From: Sam Stickland [mailto:sam_ml at spacething.org]
Sent: Wednesday, November 12, 2003 2:56 PM
To: Kinczli Zoltán; Cisco Nsp
Cc: dr at cluenet.de
Subject: Re: [nsp] ip verify unicast not logging in ACL


Hmm... But if that's the case how come configuring:

access-list 199 ip any any deny log
!
int vlan x
  ip verify unicast source reachable-via any allow-default 199

Still only shows suppressed drops?

Trying it without any access-list at all still only shows supressed drops,
but appears to cause the BGP session to close. I was running with "debug ip
cef drops rpf" at the time, and it's only recorded entries like:

CEF-Drop-Suppress: Packet from a.b.c.d via VlanX -- ip verify check
(reachable via FastEthernet4/2)

So it says it's a supressed drop, but also that it's reachable via Fa4/2?
That doesn't seem to imply it's a packet that the FIB drop would check?

David, I don't currently have a TAC login to hand (not at the office). Could
you send me some details on cscdz05443 if you get a spare moment.

I'm definately getting a bit jumpy about using loose uRPF for this sort of
checking at all :/

Thanks for both the replies,

Sam

> hello,
>
>   drop: as its name suggests, packet was dropped
>
>   suppressed drop: the FIB check would drop, but the ACL (not available on
asic based platforms)
> supressed the drop, so the packet was passed finally
>
> rgds
>  z.
>
> -----Original Message-----
> From: Sam Stickland [mailto:sam_ml at spacething.org]
> Sent: Wednesday, November 12, 2003 1:58 PM
> To: Cisco Nsp
> Subject: Re: [nsp] ip verify unicast not logging in ACL
>
>
> Oh forgot to ask, what's the difference between a drop and suppressed
drop?
> I can make a couple of educated guesses, but it's not actually mentioned
in
> the documentation.
>
> Sam
>
> > Hi,
> >
> > I'm configuring some routers to drop packets sourced from IP addresses
> given
> > by the bogon servers, using loose uRPF. (Dropping packets with
> destinations
> > from the bogon servers is working fine.)
> >
> > I've tried the following (using a permit initially, just while I'm
> testing -
> > I don't want to actually drop the traffic).
> >
> > access-list 99 permit any log
> >
> > int vlan x
> >   ip verify unicast source reachable-via any allow-default 99
> >
> > If I do 'sh ip int vlan x' I can see
> >
> >   IP verify source reachable-via ANY, allow default, ACL 99
> >    0 verification drops
> >    80948 suppressed verification drops
> >
> > and the suppressed verification drops is rising pretty rapidly (which is
> > suprising since this interface carries less than a meg of traffic). But
> 'sh
> > access-list 99' only shows this (note the lack of a match counter):
> >
> > Standard IP access list 99 (Compiled)
> >     10 permit any log
> >
> > And there's nothing in the logs either. If I take away the ACL from the
> > statement, or change it to a deny I still get get no logs, but this time
> the
> > BGP session on that interface will drop, which it shouldn't do, so I'm
> > assuming the uRPF isn't functioning correctly :/
> >
> > Is there anything wrong with my config? Perhaps I'm hitting a IOS bug?
> This
> > on a Cat6500 running IOS 12.2(14)SY1
> >
> > Sam
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>