Re: IMQ / new Dummy device post.

[Andy Furniss <andy.furniss@xxxxxxxxxxxxx>]

jamal wrote:
> On Sun, 2004-04-18 at 16:34, Andy Furniss wrote:
>
>
>
> > Hmm second thoughts - if I can route packets to dummy after demasquerade 
> > then I don't need to mark - I can use u32 as I do now to seperate per 
> > IP. Am I missing something here?
>
>
> The problem is dummy had some speacial reason for existence in the old
> days of slip/ppp dummy acts as blackhole; 
> some apps insist(ed) on getting a static IP address
> on primary interface when you are offline. So people would typically
> setup routes to the dummy device where packets just get swalloed.
>
> I have a feeling there are people who still use this functionality
> somewhere in the globe (sorry i am from .ca dont know what that means
> anymore;->). And i dont want to break this functionality.
> So what i was thinking is i will have dummy spare any fwmarked packets
> and reinject them back.

I think this would still be a solution for me - I allready mark 
everything coming in on ppp0 in prerouting filter (pre demasquerade) 
into three classes - interactive, new and
bulk. I then use u32 to further share bulk per dst IP post demasquerade 
on the HTB/IMQ. So as long as I can route to dummy post demasquerade I 
don't need IMQ. This would be alot better than messing around with connmark.

Andy.

> Another alternative is to just fsck this backward compatibility mode
> because people could use blackhole routes today.
> Yet another alternative is to create a brand new device and call it
> something like imq2. For such little code, this may be overkill.
>
> cheers,
> jamal