[LARTC] Re: What am I missing?

2006-07-27 Thread Ray Van Dolson
Follow-up to my own post here:

  http://marc.theaimsgroup.com/?l=lartc&m=115332794424197&w=2

Problem ended up being that the tc included in the iproute RPM in Fedora
Core 2 was built specifically against the headers in the glibc-kernheaders
RPM.

When I switched to a custom kernel (for built-in MPPE support), apparently
some symbols referenced in the glibc-kernheaders package are not present in
the non-RH kernel.  This was causing my issue.

Solution was to modify the .spec file for iproute and tell it to compile
against my custom kernel's headers specifically.

Specifically I had to make the following changes to the .spec file to get
things to work:

 - Modify iproute2-2.4.7-kernel.patch to point to /usr/src/linux/include
 - Do not apply iproute2-2.4.7-misc.patch
 - Do not apply iproute2-2.4.7-in_port_t.patch

This makes everything happy once again!  I'm not sure what the consequenes
are of not applying those RedHat patches, but the tool still works normally
as far as I can tell.

Ray
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[LARTC] What am I missing?

2006-07-19 Thread Ray Van Dolson
On a custom compiled Linux 2.6.13 kernel...

# tc qdisc add dev ppp145 handle : ingress
# tc filter add dev ppp145 parent : protocol ip prio 50 u32 match ip src 
0.0.0.0/0 police rate 384kbit burst 10k drop flowid :1
RTNETLINK answers: Invalid argument

This works fine on a CentOS machine and my Fedora Core 2 box with default
kernel.  I'm trying to figure out what is missing in the custom built 2.6.13
kernel.  strace isn't real helpful, and there doesn't appear to be a way to
make tc present more useful error messages...

Non ingress filtering works.  Here's an excerpt from kernel config:

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
CONFIG_CLS_U32_PERF=y
CONFIG_NET_CLS_IND=y
# CONFIG_CLS_U32_MARK is not set
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

Any ideas?  Can paste entire kernel config if necessary.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[LARTC] Egress shaping recommendations (based on source ip)

2006-06-21 Thread Ray Van Dolson
I'm trying to set up customer egress shaping on concentrator that customers
connect to using pptp (which uses pppd).  This means customers each have a
pppXXX interface when they connect.  It's easy to shape their "down" speed
this way, and when they disconnect the interface is gone and thus the
shaping rules automatically go away as well.

However, shaping their upload (traffic that forwards from their ppp
interface and out the ethernet interface on the server) is a different
matter and I'm trying to figure out the best way to do it.

I was planning to do this with CBQ... initially I created a root qdisc with
the full Ethernet bandwidth available.

I created two classes below that, one with the full bandwidth available, and
one with only 9Mbps available (internet bandwidth we have at this site).

To the 9Mbps class, I want to attach child classes limited to the rate plan
each customer is assigned.  These classes should be created when the
customer connects, and removed when they disconnect.  I will create a filter
based on "ip src" and point to the appropriate class for each customer.

The problem I'm running into is that when I customer disconnects, I cannot
find a "clean" way to remove their associated classes and filters.  I would
like to be able to do simply delete the class I created for them and have
all the attached filters automatically removed as well... kind of like how
you can delete the root qdisc and everything below is removed automatically.

However, this doesn't seem to work.  You have to delete the filters first
before removing any classes.

Instead of using classes should I be looking at using child qdisc's and
attaching filters directly to those (if that can be done)?

Just trying to avoid a situation on a busy server where a tc command fails
and I'm left with stale filters and classes.

Ray
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc