[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with Netfilter (Packet Marking) and ip util

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 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?
> 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.