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

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



Hi,

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
> purpose.
> 
> > (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
correctly.

> > 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 :(

Cheers,
Steven
-- 
Steven Van den Berghe             
steven.vandenberghe@intec.rug.ac.be
Workgroup Broadband-Networks
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)                  
                                                         
                                                         
                                                         
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*