[nsp] Strange routing and ACL problem

Sat Nov 22 12:26:51 EST 2003

How can I check the current usage and maximum size of the FIB under native
IOS?

----- Original Message -----
From: "Sam Stickland" <sam_ml at spacething.org>
To: "Stephen J. Wilcox" <steve at telecomplete.co.uk>
Cc: "Cisco Nsp" <cisco-nsp at puck.nether.net>
Sent: Saturday, November 22, 2003 4:37 PM
Subject: Re: [nsp] Strange routing and ACL problem

> Hmmm.... after a 'clear cef linecard x' everything started working
> correctly. Odd. I'd checked the CEF table and everything had looked fine.
A
> CEF problem would fit in with what I'd discovered in the previous post
> though, wouldn't it? (that the ACL had to had have the log keyword with it
> for the traffic to be routed correctly).
>
> Sam
>
> ----- Original Message -----
> From: "Stephen J. Wilcox" <steve at telecomplete.co.uk>
> To: "Sam Stickland" <sam_ml at spacething.org>
> Cc: "Cisco Nsp" <cisco-nsp at puck.nether.net>
> Sent: Saturday, November 22, 2003 4:19 PM
> Subject: Re: [nsp] Strange routing and ACL problem
>
>
> > certainly odd! how can you get the behaviour to change and allow access
to
> work
> > to b rather than a for example.. does it vary after a clear cef or
reboot?
> or if
> > you use different ip addresses, different vlan numbers? - just trying to
> figure
> > what makes one vlan special like that?
> >
> > Steve
> >
> > On Sat, 22 Nov 2003, Sam Stickland wrote:
> >
> > > Hmm.. Did some further digging and found that the ACLs only make it
work
> if
> > > the log statement is next to the networks I'm specifying.
> > >
> > > And, IIRC, the log statement will force the packets to be software
> switched,
> > > rather than hardware?
> > >
> > > An IOS bug then?
> > >
> > > Sam
> > >
> > > ----- Original Message -----
> > > From: "Sam Stickland" <sam_ml at spacething.org>
> > > To: "Cisco Nsp" <cisco-nsp at puck.nether.net>
> > > Sent: Saturday, November 22, 2003 3:48 PM
> > > Subject: [nsp] Strange routing and ACL problem
> > >
> > >
> > > > Hi,
> > > >
> > > > I've got a 6509 connected to a 7206 using a /30 and OSPF. The 7206
> > > > advertises about 5 networks (each in their own VLAN) via OSPF to the
> 6509.
> > > > The 6509 can reach all of the networks fine.
> > > >
> > > > The 6509 is connected via a different port and VLAN (call it VLAN x)
> to a
> > > > bunch of other equipement. Everything in VLAN x can only access one
of
> the
> > > > networks from the 7206. Packets to the other networks are just
getting
> > > > dropped.
> > > >
> > > > To debug it I placed an ACL on VLAN x on the 6509 and uncovered some
> very
> > > > strange behaviour.
> > > >
> > > > If I explicitity allow access to one of the networks on the 7206
using
> an
> > > > ACL on the 6509 the packets are allowed through. If I add an ACL
with
> a
> > > > "permit ip any any", or use no ACL at all it doesn't work. I
explicity
> > > have
> > > > to list the source or the destination for it to work.
> > > >
> > > > The network layout is like this:
> > > >
> > > >             /30
> > > >     6509 ------------ 7206
> > > >       |               x.x.a.2/27
> > > > Trunk |               x.x.b.2/24
> > > >       |               x.x.c.2/26
> > > >       |               x.x.d.2/24
> > > >     3550
> > > >       |
> > > >       | VLAN x
> > > >       |
> > > >     Host A
> > > >    x.x.e.1/24
> > > >
> > > > Without any access-list on VLAN x on the 6509 Host A can only ping
> x.x.a.2
> > > > and x.x.c.2
> > > >
> > > > If I create an ACL like this:
> > > >
> > > > ip access-list extended debug-routing-1
> > > >   permit ip any x.x.b.0 0.0.0.255 log
> > > >   permit ip any any
> > > >
> > > > int VLAN x
> > > >   ip access-group debug-routing-1 in
> > > >
> > > > Then Host A is now able to ping x.x.a.2, x.x.b.2 and x.x.c.2 but not
> > > x.x.d.2
> > > >
> > > > If I create an access list that explicity allows access to
x.x.d.0/24
> then
> > > > it can. Also, if I create an ACL explicity allowing accessing from
> Host
> > > A's
> > > > subnet (x.x.e.0/24) then it can access all the networks on the 7206.
> > > >
> > > > Further more, specify an mask that explicity covers a range (for
> example
> > > > permit ip x.y.z.0 0.0.31.255 any for a /19) doesn't work. The
sources
> > > either
> > > > have to be explicity
> > > >
> > > > I've also tried static routing the networks rather than using OSPF
and
> > > > gotten the same result. Equipement I've tested from (Host A in the
> > > diagrams)
> > > > have been a 7206, a 2651 and a linux host. On the cisco routers
(which
> > > have
> > > > variously been running OSPF or static routes), the routing and CEF
> tables
> > > > have been correct, and the OSPF database looks good.
> > > >
> > > > >From the networks listed above it looks like it's only affecting
> /24s,
> > > but
> > > > I've tried configuring other networks of different sizes without any
> luck
> > > > (including /26s and /27s).
> > > >
> > > > The 6509 is running 12.1(20)E native.
> > > >
> > > > Has anyone got any idea what the hell is going on here?
> > > >
> > > > 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/
> > >
> >
>
> _______________________________________________
> 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/
>