Re: [mpls-linux-general] Looking for examples to test TC/DS/IPTABLE

[Olivier D. <Oli...@rd...>]

Hi Jim,

Comments below ...

James R. Leu wrote:

> Comments below ....
> 
> On Tue, Dec 18, 2001 at 04:21:48PM +0100, Olivier Dugeon wrote:
> 
>>Hi Jim,
>>
>>James R. Leu wrote:
>>
>>
>>>I see the light now.....
>>>
>>>Last night I dug around the kernel and I now see why you think that
>>>netfilter is the best way for interacting with the ipv4 routing table.
>>>I will look more at your work and see how I can make it less MPLS specific.
>>>
>>>Right now I think I am going to add a new netlink.  POST_ROUTING_SLOW.
>>>This will allow a netlink to modify the route cache entry.  The result will
>>>be that the netlink code for this will only be run for the first packet
>>>in the "flow".    The rest will hit the entry in the route cache and
>>>will be redirected to the MPLS layer.
>>>
>>>
>>
>>Ok, i think it's a good way setup the process of the first packet. It's 
>>that we do by hacking the rt_set_nexthop code. This function is call 
>>only for the first packet of a flow (ie. the first ping packet). Then, 
>>the entry are kept into the route cash a moment (so, stoping a ping and 
>>start some time after a second ping, doesn't call another time 
>>rt_set_nexthop because the route cash entry is still valid).
>>
>>What do you intend to do with this new POST_ROUTING_SLOW netlink ?
>>
> 
> -change the pmtu
> -use the some index on the skb to lookup the moi, attach it to the route cache
>  entry
> -change rt->dst.output to be mpls_output
> 


Ok. fine.

> This will require that everytime a moi is deleted, the route cache must
> be cleared. :-(
> 


In our original code, the moi is not delete. The moi was setup with 
mplsadm but no route entry was added (ie. no fec was given to mplsadm 
and dst_aux_proto was not set)

The packet go to ip_route_input function first. Then, in the case of the 
first packet, fast route is not find (ie. there is no route cash entry 
corresponding to this flow). So, ip_route_input call ip_route_input_slow 
function which call rt_set_next_hop where reside the mpls processing 
stuff. After rt_set_nexthop, ip_route_input_slow finish to compute a new 
route cash entry and store it into the route cash table. So, the 
subsequent packet are only process by ip_route_input because a valid 
route cash entry is find. So, i think route cash entry is not cleared, 
only a new one is created.


> What do you think of this?
> 
> What should be done with skb that come through POST_ROUTING_SLOW but
> a moi could not be found?
> 
> 1. I could drop it, then a route cache entry will not be created and
> next time a packet for this flow is seen it will be slow routed again
> giving another chance for a valid moi to be found.
> 
> 2. I could let it pass and let it go via IP.  Also subsequent packets for
> this flow will be fast routed, thus not given a chance to find valid moi.
> To get around this everytime a new moi is created the route cache could
> be cleared, thuis forcing packets to go through the slow path again.
> 
> What do you suggest?
> 


2. If moi could not be found for the first packet, subsequent packet 
failed to. So, the better is to process this packet as usual ie. normal 
ip stuff routing without MPLS processing. But, don't drop it and don't 
clear the route cash entry. I think that if the first packet doesn't 
activate the MPLS processing, is that it don't do. If it failed because 
value are not correct (mplsadm, iptable ... miss configuration) it's an 
operator problem. So, saying that with an MPLS_DEBUG output is 
sufficient. I would add to mplsadm the iptable and tc configuration to 
avoid a such situation but haven't find any time to do it.

I think, POST_ROUTING_SLOW must be setup if you would use another value 
  (ie. nfmark or mpls_index) to retrieve the moi from this skb entry. I 
don't if need to be dynamic like you suggest or just a compile flag for 
the kernel like other CONFIG_xxx.

Your previous post about MPLS_OP_NF_FWD seems to be better. The kernel 
code (inside rt_set_nexthop) can dig with an mpls mark comming from the 
skb to retrieve the moi information. This mpls mark can be setup by what 
you want (iptable, ipchains, tc ...). The purpose of MPLS_OP_NF_FWD is 
just for mplsadm to setup a moi entry into the RADIX_TREE which 
correspond to this mpls mark (label value is user friendly). So, the 
normal processing become (pseudo code) :

if (mpls_mark)
     retrieve_moi_from_mpls_mark(mpls_mark);
else
     moi = proto_data[AUX_PROTO_DATA_MPLS];

Now, a better one is to merge the two approach. Only use mpls_mark. This 
mpls_mark can be setup by iptable, tc or other AND can be setup by the 
normal mpls stuff based only on the ip dst address. So, the process become:

retrieve_moi(mpls_mark ? mpls_mark : proto_data[AUX_PROTO_DATA_MPLS]);

proto_data doesn't contain a pointer to the moi, but the corresponding 
entry (ie. the label value)

What do think of this ?

Olivier
-- 
  FTR&D/DAC/CPN
  Technopole Anticipa     | mailto:Oli...@fr...
  2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
  F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52