Network Interfaces and packet selection

Network Interfaces and packet selection

Post by Matt » Thu, 13 May 2004 14:13:23



Does anyone know if it is possible to force Solaris to
send a packet back out the interface it arrived on,
regardless of the optimal route (a packet arrives on
an interface on network A, the default route says to
send the return packet to a router on network B, but
we want to return the packet to a router on network B
since it came in on that network). This would require
some statefullness, which I am not sure if Solaris
provides. I have searched through docs and google, and
can't seem to turn up a concrete answer (other than using ipfilter).

Thanks for any insight,
- Ryan

 
 
 

Network Interfaces and packet selection

Post by Barry Margoli » Thu, 13 May 2004 23:46:17




> Does anyone know if it is possible to force Solaris to
> send a packet back out the interface it arrived on,
> regardless of the optimal route (a packet arrives on
> an interface on network A, the default route says to
> send the return packet to a router on network B, but
> we want to return the packet to a router on network B
> since it came in on that network). This would require
> some statefullness, which I am not sure if Solaris
> provides. I have searched through docs and google, and
> can't seem to turn up a concrete answer (other than using ipfilter).

No, it's not possible.  The OS doesn't know that an outgoing packet is
in reply to any specific incoming packet.

--

Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 
 
 

Network Interfaces and packet selection

Post by Darren Dunha » Thu, 13 May 2004 23:57:52



Quote:> Does anyone know if it is possible to force Solaris to
> send a packet back out the interface it arrived on,

No.  I don't think you mean exactly what you say, either.  I'm imagining
that rather than send the same packet out the interface, you want a
packet generated as a *response* to go out the same interface that the
*request* was received on.

However, unless the application is doing a lot of work itself, the OS
doesn't keep track of the interface for received traffic.  So when the
response is created, neither the application nor the OS have any way of
finding the "incoming interface".  

Further, some traffic simply doesn't behave in the simple request -
response pattern, so "the incoming interface" simply wouldn't exist in
any real sense.

Quote:> regardless of the optimal route (a packet arrives on
> an interface on network A, the default route says to
> send the return packet to a router on network B, but
> we want to return the packet to a router on network B
> since it came in on that network). This would require
> some statefullness, which I am not sure if Solaris
> provides.

It does not.

Quote:> I have searched through docs and google, and
> can't seem to turn up a concrete answer (other than using ipfilter).

Even using ipfilter for this isn't quite the same concept.  Rather than
the statefullness of sending out the incoming interface, you often set
it up so that outgoing packets are routed based on source address rather
than destination address.  For many simple multi-headed servers, this
gives you about the same behavior.

Is there a reason you can't use ipfilter to do this?

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

 
 
 

Network Interfaces and packet selection

Post by Matt » Fri, 14 May 2004 11:57:10




>> Does anyone know if it is possible to force Solaris to
>> send a packet back out the interface it arrived on,

> No.  I don't think you mean exactly what you say, either.  I'm imagining
> that rather than send the same packet out the interface, you want a
> packet generated as a *response* to go out the same interface that the
> *request* was received on.

Yes ... similar to disabling oportunistic routing on some Cisco devices.

Quote:> However, unless the application is doing a lot of work itself, the OS
> doesn't keep track of the interface for received traffic.  So when the
> response is created, neither the application nor the OS have any way of
> finding the "incoming interface".  

> Further, some traffic simply doesn't behave in the simple request -
> response pattern, so "the incoming interface" simply wouldn't exist in
> any real sense.

>> regardless of the optimal route (a packet arrives on
>> an interface on network A, the default route says to
>> send the return packet to a router on network B, but
>> we want to return the packet to a router on network B
>> since it came in on that network). This would require
>> some statefullness, which I am not sure if Solaris
>> provides.

> It does not.

I kinda figured but wanted to double check.

Quote:>> I have searched through docs and google, and
>> can't seem to turn up a concrete answer (other than using ipfilter).

> Even using ipfilter for this isn't quite the same concept.  Rather than
> the statefullness of sending out the incoming interface, you often set
> it up so that outgoing packets are routed based on source address rather
> than destination address.  For many simple multi-headed servers, this
> gives you about the same behavior.

> Is there a reason you can't use ipfilter to do this?

It adds complexity to an already overcomplex network :( I
may be forced into it. Thanks for the feedback.
 
 
 

Network Interfaces and packet selection

Post by Darren Dunha » Sat, 15 May 2004 01:45:29



Quote:>>> regardless of the optimal route (a packet arrives on
>>> an interface on network A, the default route says to
>>> send the return packet to a router on network B, but
>>> we want to return the packet to a router on network B
>>> since it came in on that network). This would require
>>> some statefullness, which I am not sure if Solaris
>>> provides.

>> It does not.

> I kinda figured but wanted to double check.

Do other OS's do this?  Does Linux?  How is it configured?

The only system I know of that does something like this is a NetApp.
The three core protocols (NFS, CIFS, HTTP) can have incoming requests
tagged with the arrival interface, and responses go out the tagged
interface.  I believe this was done as a performance tweak (the system
doesn't have to run through the routing table for all the outgoing
packets), but it still works well for things like this.

--

Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

 
 
 

Network Interfaces and packet selection

Post by Barry Margoli » Sat, 15 May 2004 02:28:46





> >>> regardless of the optimal route (a packet arrives on
> >>> an interface on network A, the default route says to
> >>> send the return packet to a router on network B, but
> >>> we want to return the packet to a router on network B
> >>> since it came in on that network). This would require
> >>> some statefullness, which I am not sure if Solaris
> >>> provides.

> >> It does not.

> > I kinda figured but wanted to double check.

> Do other OS's do this?  Does Linux?  How is it configured?

I don't think any general purpose OSes do it.

--

Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 
 
 

1. Router dropping packets from eth interface to ppp interface

Hi,

I have the following setup:

Web server |------| Router |------| Web client
                 eth0     ppp0

The link between the web server and the router is a 10Mbps Ethernet
link, while the link between the router and the web client is a ppp
link.

Using tcpdump, I captured the web tcp packet traces at both the
router's eth0 and ppp0 interfaces.

What I found was that some of the TCP packets that arrived at eth0,
did not appear at the ppp0 interface. It seems to have been dropped.
As a result, after some time, the web server retransmitted the same
packets again, and this time, the retransmitted packets were
successfully routed from the eth0 interface to the ppp0 interface.

Anyone has any idea why the original packets were dropped somewhere
between the eth0 and ppp0 interfaces? And how can I solve for this
problem? The router machine is running Linux 2.4.5

Thanks,
Wee Lum

2. Problem compiling kernel pl12

3. Lost UDP packets above network interface

4. going online with linux ...

5. Lost UDP packets above network interface layer !!

6. Please help with (perhaps) silly question, thanks!

7. IP Aliases and address selection of outgoing packets

8. Help with DLL

9. multicast interface card selection.

10. Matrox Mystique ands X.

11. Question about selection of user interface/database software

12. network interface names ethX and renaming interfaces

13. Disk Selection Not responding to selection under 2.5