Routing outgoing packets over multiple interfaces?
I have two network interfaces (eth0 and eth1) with separate IP addresses on the same subnet. All outgoing traffic uses eth0 regardless of the interface the incoming traffic came in on.
I assume the outgoing packets still have the correct source IP address (not always eth0's), and I'd like the packets to go out on the interface with the corresponding IP address.
I think I have half the solution to my problem:
http://www.novell.com/support/viewConte … Id=7000318
The other half is that my IPs are dynamic, so ddclient could change my IPs and then the routing would be invalid.
Last edited by MindlessXD (2009-02-10 07:06:16)
Setup custom route tables to be used depending on the iptables conntrack marks below
ip route flush table 1
ip rule del fwmark 101 table 1
ip route add table 1 default via <ETH0 IP ADDRESS>
ip rule add fwmark 101 table 1
ip route flush table 2
ip rule del fwmark 102 table 2
ip route add table 2 default via <ETH1 IP ADDRESS>
ip rule add fwmark 102 table 2
I'm not 100% sure if you can add a route via the interfaces IP address. This code has been modified from a box using 2 different ISP's so they have different upstream routers. You might need to replace the 'via' parts with 'src'
# Ensure traffic in one interface goes back out the same interface
iptables -t mangle -F PREROUTING
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -i eth0 -m state --state NEW -j MARK --set-mark 101
iptables -t mangle -A PREROUTING -i eth1 -m state --state NEW -j MARK --set-mark 102
Similar Messages
-
Solaris 10 ip address of outgoing packets on logical interfaces
Hi there.
I have a Sun here with Solaris 10 and one physical interface e0 and one logical interface on it e0:1.
e0 has address 1.2.3.4
e0:1 has address 1.2.3.5
gateway is 1.2.3.254
To every ip address I bind a sendmail deamon.
For incoming connection the ip packtes come out with the right ip address
from the interface to which the connection was established.
But for outgoing packets it seems that only the ip address of e0 is used even if the sendmail on e0:1 makes an outgoing connection.
On Solaris 9 every app that binds to an logigical interface uses that ip for outgoing connection, but on Solaris 10 it looks, that only the ip address of the primary (physical) interface (e0) is used.
Is there a way to make outgoing connections of apps binding e0:1 to use the ip address of the e0:1 interface?
I dont use zones, both interfaces are in the global zone.I'm not that familiar with postfix, but thats where the solution should be. As I mentioned earlier in this thread, the application has full control here and should be the place to set it. I'll bet postfix has a setting for what outbound IP address to use.
Trying to coerce this at the OS level is much more difficult.
Especially with your phrase about "if packet enters..." There's two possible things you might mean by that.
#1 is if the packet coming in starts a TCP session. That session sets the two IP addresses, and the OS can't override that address for outbound packets. The usesrc setting is only valid for TCP sessions started by your machine.
#2 is if the "packet coming in" you refer to really means an email in (which gets completed), and then your machine sends an email back out. But then there's no association (in the OS) between the two emails, so it doesn't know that this mail "should" go out that interface.
In both cases, I think you'll want postfix to handle this.
Darren -
Non-global zone sending TCP SYN-ACK packet over wrong interface.
After spending many hours looking at ipmon/ethereal logs, I believe I've found
a explanation (a bug?) for the following strange behaviour (Solaris 10u1):
I've got a non-global zone with Apache2 with dedicated IP and bound to interface e1000g2 of a Sun X4200 box. The global zone has a different dedicated IP bound to a different interface e1000g0.
When I point a browser at the web site, the HTML page often comes up immediately, but sometimes it will hang and only load when I press the reload browser button one or multiple times. This is reproducible with different browsers from different networks with or without DNS resolution. It's reproducible with other non-local zones configured alike and running different TCP based services (namely SSH or non-Apache HTTP).
This is what happens in a failing case (Ethereal client dump "dump_failed.txt" and IPF log "att1.txt" lines 1-3 pp): the incoming TCP SYN comes over interface e1000g2 (correct) and is passed by IPF. However, the non-global zone sends the TCP SYN-ACK package back over interface e1000g0, which is wrong and causes IPF to fail to build a correct state entry. Then, afterwards, the response packets from the webserver will be filtered by IPF, since it has no state entry.
In the success case (Ethereal client dump "dump_success.txt" and IPF log "att1.txt" lines 19-21 pp), the incoming TCP SYN is answered correctly by a TCP SYN-ACK both over interface e1000g2. IPF can build a state entry and all subsequent packets from the webserver reach the client.
=====
The non-global zone has this setup:
zonecfg:ws1> info
...snip...
net:
address: 62.146.25.34
physical: e1000g2
zonecfg:ws1>
=====
The relevant (as of the IPF log) IPF rules are:
rule 1: block out log all
rule 16: pass in log quick proto tcp from any to 62.146.25.34 port = 80 keep state
=====
If I didn't miss an important point, I suspect this to be a bug in Zones and/or IPF.
Any hints?
Thx,
Tobias
"att1.txt":
LINE PACKET_DT PACKET_FS PACKET_IFC RULE_NUMBER RULE_ACTION SOURCE_IP SOURCE_PORT DEST_IP DEST_PORT PROTOCOL TCP_FLAGS
1 08.05.2006 21:24:09 786741 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp S
2 08.05.2006 21:24:09 786863 e1000g0 16 p 62.146.25.34 80 84.56.16.159 60693 tcp AS
3 08.05.2006 21:24:09 808218 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp A
4 08.05.2006 21:24:09 837170 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
5 08.05.2006 21:24:09 837189 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
6 08.05.2006 21:24:09 837479 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
7 08.05.2006 21:24:12 823801 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
8 08.05.2006 21:24:12 823832 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
9 08.05.2006 21:24:13 210039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
10 08.05.2006 21:24:18 839318 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
11 08.05.2006 21:24:18 839351 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
12 08.05.2006 21:24:19 970040 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
13 08.05.2006 21:24:24 840073 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AF
14 08.05.2006 21:24:30 870503 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
15 08.05.2006 21:24:30 870538 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
16 08.05.2006 21:24:33 480059 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
17 08.05.2006 21:24:45 347464 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AF
18 08.05.2006 21:24:45 347498 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
19 08.05.2006 21:24:47 857068 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp S
20 08.05.2006 21:24:47 857118 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AS
21 08.05.2006 21:24:47 878257 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
22 08.05.2006 21:24:47 907630 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AP
23 08.05.2006 21:24:47 907644 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
24 08.05.2006 21:24:47 907892 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AP
25 08.05.2006 21:24:47 976361 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AP
26 08.05.2006 21:24:47 976375 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
27 08.05.2006 21:24:47 976487 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AP
28 08.05.2006 21:24:48 127599 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
29 08.05.2006 21:24:54 932569 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AFP
30 08.05.2006 21:24:54 932595 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
31 08.05.2006 21:25:00 490052 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
32 08.05.2006 21:25:02 980057 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AF
33 08.05.2006 21:25:03 1890 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
34 08.05.2006 21:25:09 907916 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AF
35 08.05.2006 21:25:09 907949 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
36 08.05.2006 21:25:42 948502 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AFP
37 08.05.2006 21:25:42 948535 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
38 08.05.2006 21:25:54 500051 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
39 08.05.2006 21:26:54 510046 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
40 08.05.2006 21:27:54 520041 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
41 08.05.2006 21:28:54 530040 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
42 08.05.2006 21:29:54 540039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
43 08.05.2006 21:30:54 550039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
44 08.05.2006 21:31:54 560041 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
"dump_failed.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1079 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x0269 (617)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde9d [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x5c3c [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.022698 62.146.25.34 192.168.1.101 TCP http > 1079 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x002f (47)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ed8 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1079 (1079), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1079 (1079)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xd017 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.022749 192.168.1.101 62.146.25.34 TCP 1079 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x026a (618)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdea4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbdac]
No. Time Source Destination Protocol Info
4 0.022919 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x026b (619)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcfd [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 3.013084 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 5 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0276 (630)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcf2 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
6 9.029003 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 6 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x027f (639)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce9 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
7 21.060827 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 7 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0284 (644)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 35.561984 192.168.1.101 62.146.25.34 TCP 1079 > http [FIN, ACK] Seq=423 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 8 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x029a (666)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde74 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 423, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbc05]
"dump_success.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1083 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x02a3 (675)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde63 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x70ca [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.020553 62.146.25.34 192.168.1.101 TCP http > 1083 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x006b (107)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2e9c [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xb530 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.020599 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02a4 (676)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde6a [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xa2c5]
No. Time Source Destination Protocol Info
4 0.020746 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x02a5 (677)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcc3 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xb2be]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.071290 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=1 Ack=423 Win=49368 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006c (108)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea3 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xe046 [correct]
No. Time Source Destination Protocol Info
6 0.075838 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 200 OK (text/html)
Frame 6 (413 bytes on wire, 413 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 399
Identification: 0x006d (109)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d3b [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 359
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Next sequence number: 360 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x29b8 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
7 0.095473 192.168.1.101 62.146.25.34 HTTP GET /favicon.ico HTTP/1.1
Frame 7 (407 bytes on wire, 407 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 393
Identification: 0x02aa (682)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdd03 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 423, Ack: 360, Len: 353
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Next sequence number: 776 (relative sequence number)
Acknowledgement number: 360 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65176
Checksum: 0x1b3d [incorrect, should be 0x1e0c]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 0.139786 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=360 Ack=776 Win=49368 Len=0
Frame 8 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006e (110)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea1 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xdd7e [correct]
No. Time Source Destination Protocol Info
9 0.144850 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 404 Not Found (text/html)
Frame 9 (464 bytes on wire, 464 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 450
Identification: 0x006f (111)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d06 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 410
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Next sequence number: 770 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x7a71 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
10 0.269307 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=776 Ack=770 Win=64766 [TCP CHECKSUM INCORRECT] Len=0
Frame 10 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02af (687)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde5f [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 776, Ack: 770, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 776 (relative sequence number)
Acknowledgement number: 770 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 64766
Checksum: 0x19dc [incorrect, should be 0x9fbe]lev wrote:This performance regression renders openvpn with a tun adapter unusable if client and server use kernel 3.14 .
Thus I created a bug report: https://bugs.archlinux.org/task/40089
i actually noticed it to be an "either-or" type of thing; my Windows clients were seeing the same thing coming off a 3.14 openvpn server.
yeah, weird issue. like i noticed spurts of even-powers-of-2 sized packets
Client connecting to 10.10.10.6, TCP port 5001
TCP window size: 416 KByte
[ 3] local 10.10.10.1 port 40643 connected with 10.10.10.6 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 2.0- 4.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 4.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 6.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 8.0-10.0 sec 128 KBytes 524 Kbits/sec
[ 3] 10.0-12.0 sec 128 KBytes 524 Kbits/sec
[ 3] 12.0-14.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 14.0-16.0 sec 128 KBytes 524 Kbits/sec
[ 3] 16.0-18.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 18.0-20.0 sec 128 KBytes 524 Kbits/sec
[ 3] 20.0-22.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 22.0-24.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 24.0-26.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 26.0-28.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 28.0-30.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 30.0-32.0 sec 128 KBytes 524 Kbits/sec
[ 3] 32.0-34.0 sec 640 KBytes 2.62 Mbits/sec
[ 3] 34.0-36.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 36.0-38.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 38.0-40.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 40.0-42.0 sec 128 KBytes 524 Kbits/sec -
How to Supress Hello packets on an interface enabled for OSPF
As I understand it, enabling an interface to join an area with the
NETWORK command, also causes Hello packets to be sent out the
interface. But if its a stub network, and you want it advertised, but
there is no need for Hello packets to be sent out the interface, how do
you suppress them?
The passive-interface command seems to be discouraged in OSPF, since
there is far more granular control over which interfaces are affected
by the network command.
The "redistribute connected subnets" could be used after entering the
network command with a very restrictive mask that advertises only
non-stub network interface(s). But that seems to open a whole new can
of redristribute issues.
This is simple to do, right?
CheersI don't why passive interface would be discouraged in OSPF--I've seen it used a lot in the networks I've worked on. In fact, with the advent of the passive-interface default command, it's much easier use passive interface in all the routing protocols.
The general rule of thumb is, if you want the routes to be internals, then use passive interface. If you want them to be externals, then use redistribute connected. You can filter the routes you pull in through redistribute connected using a route map. You can control which interfaces are pulled in through passive using the network statement.
Russ.W -
Traceroute: Warning: Multiple interfaces found
I have added a route by
route add 10.224.36.0 -netmask 255.255.255.224 10.224.18.1
I can even ping to that IP. However when i do a traceroute it gives-->
$ traceroute 10.224.36.1
traceroute: Warning: Multiple interfaces found; using 10.224.8.152 @ ce0
traceroute to 10.224.36.1 (10.224.36.1), 30 hops max, 40 byte packets
1 10.224.18.1 (10.224.18.1) 0.608 ms 0.542 ms 0.410 ms
2 10.224.36.1 (10.224.36.1) 40.482 ms 45.331 ms 40.516 ms
What's wrong?
AnmolI don't think the version of traceroute here uses the routing tables at all, but just picks an interface to transmit on. That's why it whines about finding multiple interfaces. I'm not sure if other versions address this.
Try providing the interface directly.
Darren -
How to route traffic between two different interfaces
Hi,
I need to setup a routing between two different interfaces on a host.
Inferface ce1 : 192.168.120.12
Inteface ce2 : 192.168.110.50
Is it possible to add a route which enables the ce2 interface to catch packets from the ce1 interface ?
Regards,
ArminThe problem is a application which is only able to listen on one interface.
To fix this, I have to make all packages visible on one interface. -
Load balancing over multiple E3s
Hi all,
For the same VP , can I make load balancing over multiple E3s connected bet the BPX 8600 and MGX 8850.
Asking the question in another way:
Is there a possibility for load balancing over multiple LSPs (multiple E3 interfaces) in Cell-Mode MPLS...and if possible,plz provide me with any good links for configuration.Following link might be useful to you
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/bpx8600/9_2/ref92/bpxrtag.htm -
Assigning multiple interfaces for Oracle API Gateway (OAG)
We are deploying Oracle API Gateway to throttle our incoming API requests. We would like to keep the incoming external API requests separate from the internal configuration management so that they go through different interfaces when accessing the OAG server. This is mainly for security reasons so that the external people won’t have access to the interface used by internal operations team to manage OAG. Based on your experience, is there any standard best practice to accomplish this? We were thinking to perhaps use two of the server’s network interfaces with different IPs, one for the incoming API requests and the other for the internal admin management of OAG. But not sure if this is the best way to do what we need. We are aware of OAG's capability to support two separate ports to handle this situation, but would like a more secure set-up that could completely eliminate external access to the OAG management done by the IT team.
Would appreciate any thoughts on best practices used regarding multiple interfaces for OAG set-up. Thank you. Oracle Marketing Cloud.You are on the right track.
Here is how you can achieve this:
You can use multiple network interfaces on the UNIX machine and setup networking/routing in such a way that all external traffic comes on on one card and is routed internally via a different card.
Segregate difference types of services (i.e to be used by external clients vs internal apps) into difference different "Service Groups". Have each of these service groups listen on different port + NIC card (under Listeners, you can define a port to list to list on a specific network address and port instead of *).
Setup additional protection for services that will be accessed by external clients. Use "Threatening Content " filter to protect your services.
Setup 2 way SSL for the interface that will be called by external clients. Setup a DN based authorization check if you want to have both authentication and authorization.
Hope this helps.
-Thanks,
Ankit Kumar -
Multiple Interface Determination
Hello everybody,
I am working on the following szenarion:
- one sender and sender interface (incoming IDOC).
- one receiver with two different receiver interfaces (outgoing BAPIs). For one of these interfaces there exit two different interface and message mappings. So, 1 incoming interface => 3 outgoing with 2 different interfaces
So in the interface determination I want to rout the message by use of XPath expression to use one of the two interface (no problem at all), but also to choose one of two interface mappings for the same interface. If I try this by creating three lines in the interface determination and using different XPaths, the last entered interface always is deleted automatically.
Thanks for your help.Hi,
To do what you want you may have to use both Receiver Determination and Interface Determination. XPath expressions can be used in both places.
In Receiver Determination, you will have 2 receiver services. Then, in one of the receiver services, you will have 2 Interface Determinations. So, you will end up with something like the following:
Receiver service1: interface1
Receiver service2: interface1, interface2
Regards,
Bill -
Multiple interfaces with same IP address?
Can anyone suggest how to configure multiple (logical or physical) interfaces with the same IP address?
There is a teaser in the solaris 8 man page for 'route' that suggests this is possible:
"In a change or add command where the destination and gateway are not sufficient to specify the route (for example, , when several interfaces have the same address), the -ifp or -ifa modifiers may be used to determine the interface or interface address."
I can find no other reference to -ifp or -ifa, and at the moment I cannot seem to bring up two interfaces (logical or physical) with the same ip address.
I realise this is an obscure config. Anyone intimately familiar with route of ifconfig?
AJBYes. I could have laid odds that this would be the first response :-)
I know it is unusual, and I am aware of the inherent issues with doing something like this. I have read the multipathing guide, but it wasn't that helpful, because I want the same IP address, not just the same subnet. It is NOT for load balancing, or failover support. I'm afraid I can't give too much detail at the moment because of the nature of research project. What I will add is that I want to do this on an 802.1q enabled NIC, on the same physical port, with different logical interfaces for each VLAN having the SAME IP address.
We can already do this on Linux, and as I said in the original post, the route man page suggests that it can probably be done on Solaris. What I really need to know is how?
Any takers?
AJB -
Pack HUs - pack a single BUNDLE over multiple BOX
Hi gurus,
In our actual model, we pack each SHU separately in a box package, or as multi level packing we pack multiple SHU in a single box package. We would now be interested to achieve a model with a single SHU packed over multiple box package, i.e. illustrated as follow:
Hierarchy level
Line identification
Material/Packaging Material
Packed quantity
Batch
0
3105639
WOODEN BOX
1
30070137000
BUNDLE
2
000001
4014378
918,000 KG
3003888501
0
3105640
WOODEN BOX
1
30070137000
BUNDLE
2
000001
4014378
918,000 KG
3003888502
Is it achievable?
Thanks & bye.Hi Rich,
The combine files feature isn't available when you're using Reader for iOS. However, you can log on to the web interface at Adobe Acrobat.com using your Adobe ID and credentials, and use the Combine Files feature there.
Please let us know if you need further assistance.
Best,
Sara -
LOST TCP SESSION, LDP AND BGP, OVER ONE INTERFACE
On 7609 PE router, lost only TCP session attach to one interface (Te3/3). The router shows this log
Aug 4 13:17:31.424: %LDP-5-NBRCHG: LDP Neighbor 200.111.117.251:0 (1) is DOWN (Session KeepAlive Timer expired)
Aug 4 13:19:52.493: %BGP-5-ADJCHANGE: neighbor 200.11.96.126 Down BGP Notification sent
Aug 4 13:19:52.493: %BGP-3-NOTIFICATION: sent to neighbor 200.11.96.126 4/0 (hold time expired) 0 bytes
Aug 4 13:42:11.265: %BGP-5-ADJCHANGE: neighbor 200.11.96.126 Up
Aug 4 13:42:23.549: %LDP-5-NBRCHG: LDP Neighbor 200.111.117.251:0 (1) is UP
The device did not present a interface flap.
The device did not present lost of OSPF adyacency, over the same interface
The device did not present lost of TCP session over oher interfaces
Please help me,
I suspect a bug, but I failed to find
ChristianHi Nagendra
This is output og sh tcp brief
PE2-PCS-RANCAGUA#sh tcp brief
TCB Local Address Foreign Address (state)
4B558124 200.11.98.9.646 200.11.98.37.51654 ESTAB
53336910 200.11.98.9.646 200.111.117.61.49833 ESTAB
4B4CF2A0 200.11.98.9.646 200.111.117.20.64138 ESTAB
536E56A4 200.11.98.9.61369 200.11.96.126.179 ESTAB
53359454 200.11.98.9.22913 200.11.96.81.646 ESTAB
4B6C25EC 200.11.98.9.646 200.111.117.251.53802 ESTAB
537CFBE4 200.11.98.9.62975 200.11.96.125.179 ESTAB
5330A774 200.11.98.9.646 200.111.117.86.62367 ESTAB
4B4D97EC 200.11.98.9.18753 200.11.96.88.646 ESTAB
4B018A28 200.11.98.9.61292 200.11.98.8.646 ESTAB
4B0B176C 200.11.98.9.23 190.151.64.218.36508 ESTAB
4B1976F0 200.11.98.9.17760 190.151.97.92.646 ESTAB
4B261BD0 200.11.98.9.646 200.72.146.42.64641 ESTAB
537CEFF8 200.11.98.9.646 200.111.117.74.54785 ESTAB
531F4890 200.11.98.9.15536 190.151.97.77.646 ESTAB
5359F5B4 200.11.98.9.24658 190.151.97.74.646 ESTAB
PE2-PCS-RANCAGUA#
Christian -
Intercepting outgoing packets with DLPI, or other means
My company is porting a network traffic-monitoring application to Solaris. We would like to use the Solaris "DLPI" interface to receive packets for analysis. However, my understanding is that DLPI will only provide incoming packets addressed to the local machine. In order to receive outgoing packets also, I understand that DLPI requires that the application place the network interface in promiscuous mode, which we are loathe to do for efficiency reasons. Is there a way in Solaris 7 or 8 to use the DLPI interface to receive both incoming packets addressed to the local machine and also outgoing packets from the local machine? If not, is there some other means of accomplishing this short of writing our own device driver? Thank you.
You are correct, the arp's come down like normal messages in DL_UNITDATA_IND
You can see them in hmeudreq. If you look into the message, you will see two blocks (the second hanging off mp->b_cont), something like the following. I haven't tried decoding it all, but you can see the arp (0806) in there.
blk=0 len=28:
00 00 00 07 00 00 00 08 00 00 00 14 00 00 00 00
00 00 00 00 ff ff ff ff ff ff 08 06
blk=1 len=28:
00 01 08 00 06 04 00 01 00 40 2e 33 ca 82 01 01
01 01 ff ff ff ff ff ff 01 01 01 02
which is an arp request for 1.1.1.2 from 1.1.1.1.
Hope this helps.
S. -
Routing outgoing messages to a spam filter
Hi
I need to configure messaging server to route all the outgoing messages to two IP addresses of our spam filters. Where that needs to be configured? Thanksalchalel wrote:
I need to configure messaging server to route all the outgoing messages to two IP addresses of our spam filters. Where that needs to be configured? ThanksYou can use the daemon keyword to route outgoing messages to a dedicated address e.g.
! tcp_local
tcp_local smtp mx single_sys remotehost inner switchchannel identnonenumeric subdirs 20 maxjobs 7 pool SMTP_POOL
maytlsserver maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0 loopcheck daemon <hostname>
tcp-daemonIf you want to route outgoing messages to more then one system then you need to create an MX record that lists both of the addresses and then use this MX address instead of the <hostname> in the above example. The daemon keyword does NOT accept multiple relay addresses.
Regards,
Shane. -
How do I run a table over multiple pages?
Hi I write TV scripts using a simple two column table which can be many rows long - how can I get Pages to automatically run the table over multiple pages whilst still allowing me to cut and paste and rearrange the script? This is simple in Word and must work in pages but I can't work out how to get it to work. I've tried looking at the Page Break feature but it won't come up from the table?
many thanksAt this time, There is no way to drive tables in Pages with AppleScript.
Do your job in Numbers which allow that.
Yvan KOENIG (from FRANCE vendredi 6 février 2009 13:54:35)
Maybe you are looking for
-
Payment media file not saved on the local PC in FBPM
Dear all, In transaction FBPM, if I choose the option ouput to the file system and point out the path to the folder where the file to be generated on my local PC, by the running of the transaction I am getting the following error: BFIBL02182 - The fi
-
How to take out ventilator on Mac OS X 10.3.9
Hi, I still use the old mac os x version 10.3.9 for some of my music recordings. The ventilator is too loud. Can I disconnect it? Jo
-
I lost my photo album pictures, trying to locate them ,but I have been unsuccessful in doing so, it gives me the option to switch albums ,but there is only the second album showing that I had to recreate.
-
I am trying to remove my name from showing in one of my email address. How would I do that?
-
Timeout issue in Bulk Edit Tool
Hi, I request help to resolve an issue in Bulk Edit Tool (Solution Starter). I have deployed Bulk Edit Tool in Ms Project Server 2010 environment. However, I am facing following issue in Bulk Edit: After entering filter criteria in the first page of