[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with Netfilter (Packet Marking) and ip util
On Thu, 31 Aug 2000, you wrote:
> On Wed, 30 Aug 2000, Jonathan Earle wrote:
> > Hi all,
> > Background
> > ----------
> > The box in question is running kernel 2.4.0-test5 (I need this kernel for a
> > specific MPLS + TC patch which destabilizes on later kernels). System is
> > Redhat 6.2, iptables 1.1.0, iproute2 (March 5, 2000).
> > I have an incoming UDP data stream, source and destination IP are consistent
> > within each packet, but I vary the destination port, starting at 1024 and
> > counting to 1123. My intent is to mark 50% of the incoming packets (those
> > with dports 1024:1073) with one marker, and the other 50% (1074:1123) with
> > another marker. The ip util would then be called to create two new routing
> > tables, based on these markers, implement the routing tables, and finally
> > mplsadm (James Leu) with Steven Van den Berghe's TC (diffserv for mpls)
> > patches is called to build two MPLS paths based on the contents of the new
> > routing tables.
> I am totaly confused as to what you are trying to do.
> And what is "Steven Van den Berghe's TC"?
The patch to tc just adds the knowledge of a MPLS-protocol, the major changes
for supporting DS over MPLS are in sch_dsmark (to get the DSCP out of the
MPLS-header instead of the TOS).
> > The Problem
> > -----------
> > This all works if the marks I specify with iptables are < 10. Anything
> > higher, and the packets appear to be missed by either the netfilter code or
> > the ip code.
> > mplsadm simply operates on the contents of the routing tables, so I figure
> > the problem must lie earlier on in the chain of events.
> > I've tried looking at the code for netfilter, and have determined that the
> > marker should be an unsigned int, which should accomodate 10, 11, etc as
> > marks.
> I think you just have too many variables (netfilter, MPLS, diffserv). It
> is kind of difficult to pin what exactly your problem is. You need to
> narrow things down some more or post more information.
> Is this the ingress policing on MPLS?
> > Related Issues
> > --------------
> > 1. What purpose would a mark on a packet serve? Why would people do this?
> to uniquely put an "internal to linux" tag that would be used to for some
> > (Genuinely interested since it may help me debug the problem). If I can try
> > another application/test which uses packet marking, I can see if the packets
> > are in fact being marked or not. Even a quick and dirty utility/patch to
> > dump the relevant portion of the skbuff structure would show whether
> > netfilter is at fault or not.
> Turn on netfilter debugging.
> > 2. Testing ip routing tables other than the default table is something I'm
> > not sure how to accomplish. If I stick a remote network into a user-defined
> > routing table, ping reports that the destination address is unknown, but
> > I've definately created the route entry - I can see it via 'ip route show
> > table ...' and mplsadm is able to use it to properly create the paths. Is
> > ping is need of a patch?
No, but you have to be sure that you are also marking the ICMP-packets
> > Any thoughts on where to go from here?
> I think you should narrow down the problem. Which additional component
> screws things? Does MPLS by itself for example work fine? Does the
> policing + MPLS work fine? etc.
Jonathan, could you try it without the MPLS-encapsulation (so, use netfilter
with marks>10 to drive multiple routing tables)? I'd do it myself, but my
testbed is out of action for a few weeks :(
Steven Van den Berghe
Department Information Technology
Ghent University - Belgium
Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99
File not found. Should I fake it? (Y/N)