[Xorp-users] XORP + User Click

Marko Zec zec@icir.org
Sat, 15 Jan 2005 01:19:19 +0100


On Friday 14 January 2005 23:45, Pavlin Radoslavov wrote:
> > On Friday 14 January 2005 22:02, Pavlin Radoslavov wrote:
> > ...
> >
> > > Myself I am not familiar enough with Click configurations to say
> > > whether it is possible to create user-level Click configuration
> > > that can pick-up the packets originated from the local host so
> > > they can be forwarded by user-level Click.
> >
> > KernelTun() element could help in such scenarios, and should work
> > for both receiving and sending packets from Click to the OS. 
> > Here's an example config (pretty much useless, though):
> >
> > rt :: LinearIPLookup(
> >                 192.168.200.200/30 2,
> >                 161.53.0.0/16 0,
> >                 10.0.0.0/8 1
> >                 );
> >
> > kt :: KernelTun(10.1.2.3/24);
> >
> > kt -> rt;
> >
> > rt[0] -> Print("0") -> Discard;
> > rt[1] -> Print("1") -> Discard;
> > rt[2] -> Print("2") -> kt;
> >
> >
> > At least on FreeBSD, this will automatically instantiate a "tun"
> > network interface in the kernel, and any packets sent down this
> > interface will then show up in Click.
>
> Thanks, that is useful to know it.
> Though, my question was slightly different.
>
> If the user uses the ping command on that host (as Julian did),
> then the ICMP packets originated by the ping command will be
> sent-down the IP stack of the OS, will be looked-up against the
> kernel forwarding table (and eventually throwed away if there is no
> matching forwarding entry).
>
> With your example above I understand that if somehow the user
> explicitly specifies that the outgoing ICMP ping packets are sent on
> the "tun" interface, then the outgoing ICMP ping packets will be
> forwarded properly by user-level Click.
>
> However, it doesn't seem that you can tell ping (at least the
> FreeBSD ping) to send the packets on a specific interface.
> Hence, even with the help of KernelTun, it looks like it is not
> possible to intercept all packets sent down to the IP stack (unless
> they are explicitly sent via the tun interface).


Agreed.  Still, one could use policy-based routing, such as ipfw fwd 
rules, to force selected traffic to go down the "tun" device, regardles 
on what the kernel forwarding table has to say.  Or alternatively use 
netgraph(4) to intercept outgoing packets at the ethernet layer and 
then loop them back to the host so that Click can fetch them via 
FromDevice().  However, those are really OS-specific hacks, rather then 
generic and portable solutions.


> If someone wants to do that, I believe the answer would be
> "use kernel-level Click".


Yup, that would be the proper way.

Cheers,

Marko