netdev
[Top] [All Lists]

Re: IMQ / new Dummy device post.

To: Andy Furniss <andy.furniss@xxxxxxxxxxxxx>
Subject: Re: IMQ / new Dummy device post.
From: jamal <hadi@xxxxxxxxxx>
Date: 18 Apr 2004 17:07:28 -0400
Cc: netdev@xxxxxxxxxxx
In-reply-to: <4082E66D.2020707@xxxxxxxxxxxxx>
Organization: jamalopolis
References: <407E5905.9070108@xxxxxxxxxxxxx> <1082031313.1039.13.camel@xxxxxxxxxxxxxxxx> <407EE3E5.8060200@xxxxxxxxxxxxx> <1082087553.1035.287.camel@xxxxxxxxxxxxxxxx> <4080356F.4020609@xxxxxxxxxxxxx> <1082145341.1026.125.camel@xxxxxxxxxxxxxxxx> <40810957.6030209@xxxxxxxxxxxxx> <1082203795.1043.18.camel@xxxxxxxxxxxxxxxx> <4081A824.5020107@xxxxxxxxxxxxx> <1082298480.1041.94.camel@xxxxxxxxxxxxxxxx> <4082AE45.7030101@xxxxxxxxxxxxx> <4082E66D.2020707@xxxxxxxxxxxxx>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
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.
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


 



<Prev in Thread] Current Thread [Next in Thread>