Ospf retransmission packet over transparent fwsm

Hello everyone!
I have a problem, ospf packets are lost over fwsm in transparent mode. my scheme cisco 6513 (vlan 602) - FWSM (transparent mode)- juniper mx 480 (vlan 1602)
sh ip ospf neighbor 10.25.78.102
Neighbor 10.25.78.102, interface address 10.25.4.49
In the area 0.0.0.25 via interface Vlan602
Neighbor priority is 0, State is FULL, 6 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x12 in Hello (E-bit L-bit )
Options is 0x52 in DBD (E-bit L-bit O-bit)
LLS Options is 0x1 (LR)
Dead timer due in 00:00:38
Neighbor is up for 00:34:26
Index 13/13, retransmission queue length 1377, number of retransmission 1829
First 0x56B71B24(22845)/0x541589D4(1980410) Next 0x56B71B24(22845)/0x53145CDC(1982479)
Last retransmission scan length is 1, maximum is 3
Last retransmission scan time is 0 msec, maximum is 0 msec
Link State retransmission due in 170 msec
fwsm version 4.1(15)
On fwsm there is a separate transparent context
interface Vlan1602
nameif outside_vos2
bridge-group 5
security-level 100
interface Vlan602
nameif inside_vos2
bridge-group 5
security-level 100
mtu outside_vos2 1600
mtu inside_vos2 1600
same-security-traffic permit inter-interface
access-group outside_vos2 in interface outside_vos2
access-group inside_vos2 in interface inside_vos2
vld-fwsm-3/Acon# sh access-list inside_vos2
access-list inside_vos2; 7 elements
access-list inside_vos2 line 1 extended permit icmp any any (hitcnt=3013) 0xdc0494dc
access-list inside_vos2 line 2 extended permit ospf any any (hitcnt=11870) 0x1a46fe16
access-list inside_vos2 line 3 extended permit ip any any (hitcnt=1) 0x8be5ad9f
access-list inside_vos2 line 4 extended permit ospf host 224.0.0.5 any (hitcnt=0) 0x96c6702
access-list inside_vos2 line 5 extended permit ospf host 224.0.0.6 any (hitcnt=0) 0xc8bc65d9
access-list inside_vos2 line 6 extended permit ospf any host 224.0.0.6 (hitcnt=0) 0xa6831776
access-list inside_vos2 line 7 extended permit ospf any host 224.0.0.5 (hitcnt=0) 0x1c1248b
vld-fwsm-3/Acon# sh access-list outside_vos2
access-list outside_vos2; 7 elements
access-list outside_vos2 line 1 extended permit icmp any any (hitcnt=3010) 0xda598b52
access-list outside_vos2 line 2 extended permit ospf any any (hitcnt=7886) 0x112dad2b
access-list outside_vos2 line 3 extended permit ip any any (hitcnt=10) 0x910c4a5a
access-list outside_vos2 line 4 extended permit ospf host 224.0.0.5 any (hitcnt=0) 0x2d6480d7
access-list outside_vos2 line 5 extended permit ospf host 224.0.0.6 any (hitcnt=0) 0x4a8401c0
access-list outside_vos2 line 6 extended permit ospf any host 224.0.0.5 (hitcnt=0) 0x70f8cbba
access-list outside_vos2 line 7 extended permit ospf any host 224.0.0.6 (hitcnt=0) 0x60783961
FWSM logs(there is no drops):
6|Apr 11 2014|14:47:40|302023|||||Teardown IP protocol 89 connection 12379739847668082336 for outside_vos2:10.25.4.49 to inside_vos2:10.25.4.54 duration 0:00:06 bytes 1520
6|Apr 11 2014|14:47:40|302022|||||Built IP protocol 89 connection 12379739847668082338 for inside_vos2:10.25.4.49 (10.25.4.49) to outside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:38|302022|||||Built IP protocol 89 connection 12379739847668082337 for inside_vos2:224.0.0.5 (224.0.0.5) to outside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:36|302023|||||Teardown IP protocol 89 connection 12379739847668082335 for inside_vos2:10.25.4.54 to outside_vos2:10.25.4.49 duration 0:00:05 bytes 164
6|Apr 11 2014|14:47:34|302022|||||Built IP protocol 89 connection 12379739847668082336 for outside_vos2:10.25.4.49 (10.25.4.49) to inside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:31|302023|||||Teardown IP protocol 89 connection 12379739847668082332 for outside_vos2:10.25.4.49 to inside_vos2:10.25.4.54 duration 0:00:05 bytes 1520
6|Apr 11 2014|14:47:31|302022|||||Built IP protocol 89 connection 12379739847668082335 for inside_vos2:10.25.4.49 (10.25.4.49) to outside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:29|302023|||||Teardown IP protocol 89 connection 12379739847668082329 for inside_vos2:10.25.4.54 to outside_vos2:224.0.0.5 duration 0:00:09 bytes 196
6|Apr 11 2014|14:47:26|302023|||||Teardown IP protocol 89 connection 12379739847668082330 for inside_vos2:10.25.4.54 to outside_vos2:10.25.4.49 duration 0:00:05 bytes 164
6|Apr 11 2014|14:47:25|302022|||||Built IP protocol 89 connection 12379739847668082332 for outside_vos2:10.25.4.49 (10.25.4.49) to inside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:21|302023|||||Teardown IP protocol 89 connection 12379739847668082328 for outside_vos2:10.25.4.49 to inside_vos2:10.25.4.54 duration 0:00:05 bytes 1520
6|Apr 11 2014|14:47:21|302022|||||Built IP protocol 89 connection 12379739847668082330 for inside_vos2:10.25.4.49 (10.25.4.49) to outside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:19|302022|||||Built IP protocol 89 connection 12379739847668082329 for inside_vos2:224.0.0.5 (224.0.0.5) to outside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:17|302023|||||Teardown IP protocol 89 connection 12379739847668082327 for inside_vos2:10.25.4.54 to outside_vos2:10.25.4.49 duration 0:00:05 bytes 164
6|Apr 11 2014|14:47:15|302022|||||Built IP protocol 89 connection 12379739847668082328 for outside_vos2:10.25.4.49 (10.25.4.49) to inside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:12|302023|||||Teardown IP protocol 89 connection 12379739847668082324 for outside_vos2:10.25.4.49 to inside_vos2:10.25.4.54 duration 0:00:04 bytes 1520
6|Apr 11 2014|14:47:11|302022|||||Built IP protocol 89 connection 12379739847668082327 for inside_vos2:10.25.4.49 (10.25.4.49) to outside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:10|302023|||||Teardown IP protocol 89 connection 12379739847668082322 for inside_vos2:10.25.4.54 to outside_vos2:224.0.0.5 duration 0:00:10 bytes 196
6|Apr 11 2014|14:47:07|302022|||||Built IP protocol 89 connection 12379739847668082324 for outside_vos2:10.25.4.49 (10.25.4.49) to inside_vos2:10.25.4.54 (10.25.4.54)
6|Apr 11 2014|14:47:07|302023|||||Teardown IP protocol 89 connection 12379739847668082323 for inside_vos2:10.25.4.54 to outside_vos2:10.25.4.49 duration 0:00:05 bytes 164
on svi interface cisco 6500 and juniper mx480 - ip mtu 1400.
when traffic goes without FWSM no packet loss
sh ip ospf neighbor 10.25.78.102
Neighbor 10.25.78.102, interface address 10.25.4.49
In the area 0.0.0.25 via interface Vlan1602
Neighbor priority is 0, State is FULL, 6 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x12 in Hello (E-bit L-bit )
Options is 0x52 in DBD (E-bit L-bit O-bit)
LLS Options is 0x1 (LR)
Dead timer due in 00:00:38
Neighbor is up for 00:00:36
Index 13/13, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec

Hi Mike,
Thanks for the reply. One of my colleagues had logged a TAC case recently and the advise was to redesign OSPF networking to reduce size of DBD packets and prevent fragmentation.
I accept this as a valid recommendation - the network does need work but was also looking for real life experiences where people had fixed similar issues.
I am looking at introducing another OSPF area and summarising as many routes as possible. I am also investigating / confirming MTU sizes on switch between ASA and FWSM. Based on some other research I am wondering whether I can increase MTU on FWSM,ASA and the interconnecting 3750 to alleviate issue.
The ASA has another neighbour with no problems - but very few routes recieved on the other network.
Thanks,
Pete

Similar Messages

EEM -automatic shut down or switch over of WAN link in OSPF when packet drop increase

Hi,
Need help..
can any one help me how can EEM help for automatic shut down or switch over of WAN link in OSPF when packet drop increase a predefined level.
I have a set up different branches connected together...OSPF is the routing protocol and need to communicate with two branches via hub locations.
need to shut or switch some percent of traffic from primary to back up when packet drop in the link.

I am not sure EEM can do what you want.
Another option could be to use SLA tacking/monitoring. But you will fall back to the new route when you lose some percentage of pings, you can't switch only part of the traffic.
I hope it helps.
PK

Adobe Air 2.0 beta causes overly transparent applications - unuseable

Hi,
   I'm running Crunchbang linux 9.04 (Ubuntu Jaunty) x64. I successfully installed Adobe Air 2.0 beta and apps run, but they are all so transparent that they can't be seen or used. Below is a screenpic of an adobe air application called doit.im. It works fine in Adobe air 1.5 on this rig, except it always asks me to click to okay the certificate and the window won't move, it's fixed where it is.
When running Adobe Air 2.0 apps, they are moveable, still ask me to click the certificate each time, but... they are WAY too unclear to see. When running the apps in a terminal, they yield no errors. I worked through all the gtk canberra errors successfully.
So I'm running the apps fine from 1.5, but just wondering if anyone know how to fix the overly transparent issue for adobe 2.0 beta - with X64 linux rigs.
    Thanks,
        Peace

Hi Tshann
Thanks for reporting this problem! We were aware of this issue and it will be fixed in the final release of AIR2.
-Thanks
Sundeep
AIR Team

Leaking netbios packets over dial up connection

I have used a verizon USB internet card for over 1 1/2 years and have just recently started having issues. After about 6 minutes I am disconnected from the internet. After several hours on the phone with verizon tech support, I was informed that my computer was "leaking netbios packets over my dial up connection." When I called apple the guy I spoke to told me he had never heard of such a thing. Does anyone know what this means and how I can fix it???

I guess you're using BootCamp and WinXP ??
In Windows, right-click on the hard drive
Highlight TCP/IP and select properties
Click on the Advanced button
Go to the WINS tab and select "Disable NetBIOS over TCP/IP"
Click OK to accept changes and close the window

Can you carry L3VPN MPLS packets over Ethernet XConnect?

Hi All,
Can you carry L3VPN MPLS packets over an ethernet port-based xconnect???
Current:
POP_1 >> Physical Circuit << POP_2
Proposed:
POP_1 >> Provider_Router_1 << ethernet port-based xconnect >> Provider_Router_2 << POP_2
We are cancelling our physical circuits between each POP and going with another provider who is going to carry all our traffic between the POPS using ethernet xconnects. We have a few L3VPN MPLS customers and I wasn't 100% sure if their L3VPN data would be carried over the proposed xconnects.
Thanks.
Andy

Thanks guys for your reply...
One thing that I've never fully understood is the MTU setting you need within the Service Provider's core network (and I've read quite a bit about it).
For example we've cut across to the new xconnect circuit last night and I can get a 1500 byte L3VPN MPLS packet through the Service Provider's core from one PE to another PE via the xconnect (see below). I think this is made up of the payload (1492 bytes) + 2 x Tunnel/VC headers (8 bytes) = 1500 bytes total - so the Service Provider's core has MTU of 1500 bytes (correct me if I'm wrong on this).
Now I don't know if this is good or bad??? What should I be looking for? How do I determine what MTU is required through the Service Provider's core???
PE_1#ping vrf NSTEST 172.16.100.17 size 1492 df-bit
Type escape sequence to abort.
Sending 5, 1492-byte ICMP Echos to 172.16.100.17, timeout is 2 seconds:
Packet sent with the DF bit set
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
PE_1#ping vrf NSTEST 172.16.100.17 size 1493 df-bit
Type escape sequence to abort.
Sending 5, 1493-byte ICMP Echos to 172.16.100.17, timeout is 2 seconds:
Packet sent with the DF bit set
Thanks.
Andy

Send broadcast packets over VPN

How can I send broadcast packets over vpn , something like bcrelay in poptop linux ?

Hi,
Do you want forward NetBIOS broadcast?
If so, open RRAS console, right clieck VPN server, properties, IPv4, check the option Enable broadcast name resolution.
Hope this helps.

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

Control Packets over non-MPLS connection

Is it possible to configure Cisco router 7204 to send BGP packets not over LSP that has been established for the BGP peer, PE router, but over non-MPLS connection, while all data traffic to the PE router get forwarded through the LSP. In other words, I'm wondering it is possible to constrain all control
packets, including BGP, OSPF and LDP, to the non-MPLS interfaces, even though the LSP exists for the destination prefixes for the BGP packets.
I hope it could be applied to establishing MP-iBGP sessions between PE routers in MPLS/VPN network, in other words, we want all BGP packets not be forwarded through the LSP established between two PE routers, which is actually an ATM LER system since we have established non-MPLS connections between LERs in order to forward control packets including routing protocol and MPLS signaling protocol.
Any response will greatly appreciated.
Regards,
Yongjun.

Yongjun,
r1------r2-----r3
\-------r4----/
r1, r3 are PEs
r2 is a P rotuer
r4 is a non-LSR
r1-r2-r3 is LSP
r1-r4-r3 is a ip path, non-lsp
Then, you can do 'local-policy routing on r1 and r3 to send the Bgp control traffic over r1--r4--r3 path.
config on r1:
ip local policy route-map foo
route-map foo perm 10
match ip addr 100
set ip next-hop
access-list 100 perm tcp host eq 179 host
access-list 100 perm tcp host host eq 179
you got to do similar config on r3.
let me know if you have further q's.
best regards,
gopal

Sending loafs of http packets over one connection

when i start my app i have it make an http connection (gets the stupid airtime message out the way)
once its done that every time u press a button its ment to send a http packet with some data sayin wich button u pressed
thing is every time i send a message the connection hangs i can never get past the ".close();" method
i need it to show down the stream and let me send other packets as other buttons are pressed
but its hanging on the first message been sent any ideas
can u send loads of messages over 1 connection ? thanks

Can't comment on the problem you're facing, but I think you should know that it's recommended to implement Runnable, not extend Thread. From the API for Runnable:
In most cases, the Runnable interface should be used if you are only planning to override the run() method and no other Thread methods. This is important because classes should not be subclassed unless the programmer intends on modifying or enhancing the fundamental behavior of the class.
luck, db

Fragmenting packets over Ethernet to improve voice quality

Setup:
1750--Ethernet---Satellite Receiver---128K Sat Link---Sat. Recvr--Ether---1750
Question:
Since the Satellite Link is only 128K there will be a problem of Serialization Delay. Is there a way to fragment packets and Interleave over ethernet ? The same way it is done over Frame Relay or MLPPP.
In this setup how does one lower down "Serialization Delay" ?

rocampo,
With a Satellite link, most the latency will be travel time and not serialization delay. I would expect VoIP quality to be an issue, since the users will have to tolerate long delays and have to wait to make sure the person on the other end has actually finished speaking before starting to speak. VoIP packets are generally small enough that they are already at or near Ethernet minimum packet size of 64 KBytes, so they are not fragmented on Ethernet. However, you may want to look into the QOS / COS capabilities of your LAN switches. But the real issue for you will be the large amount of latency across the satellite link. Be sure to use QOS on the satellite link, to send along VoIP packets on a preferred basis over other less time sensitive traffic. And you may want to see if you can use RTP header compression on the Satellite link to shrink the size of VoIP frames.
Regards,
Rob Bristow
AT&T Solutions
CCIE #3335

Discoverer over transparent gateway

I would like to know if any one has deployed Discoverer over non Oracle db using transparent gateway, particularly on DB2 or Teradata?
Regards,
Rocky

Hi,
I've been on sites where it has been done and seen it done. Unfortunately we aren't using it on our site here for me to give specific examples - but it works.
As soon as you can inter-link the RDBMS engines via SQL*Net and create your database link, your in business. Disco will natively pick up the remote objects and treat them as local. We have this piece of the puzzle working on-site.
You do however have to think about the performance of your remote and local RDBMS's, the network speed/loading and the volume of data your talking about.
Let me know if you have more specific questions - I have a very Senior Ex Oracle DBA sitting beside me. We were discussing this very topic yesterday - regarding a recent post "Can't create EUL in Oracle Discoverer" - where the poster was trying to hook-up Discoverer into a SQL*Server DB.
hope this helps,
Lance

Drawing Over Transparent Region of SplashScreen Image

Has anyone been successful trying to paint over a transparent region of an image using the Java 6 SplashScreen ?
I've got a PNG with a transparent background as my SplashScreen image, and I would like to paint over part of the transparent area. Whatever I try, I can't seem to accomplish it. I've played around with the Graphics2D setComposite and setClip, but I'm not having any luck. It paints over the non-transparent area, but not the transparent area. It's like there is a clip region for the image that I cannot seem to undo.
Anyone have any suggestions?

To expand on the problem, I tried doing the same thing just in a panel, like so:
public class SplashTest {
     public static final File IMAGE_FILE = new File("SplashTest.png");
     public static void main(String[] args) {
          SplashScreen splashScreen = SplashScreen.getSplashScreen();
          Graphics2D g2d = splashScreen.createGraphics();
          g2d.setColor(Color.RED);
          g2d.fillRect(0, 200, 300, 100);     // draw red rectangle across bottom
          g2d.dispose();
          splashScreen.update();
          try {
               Thread.sleep(3000);     // show splash for 3 seconds before exiting
          } catch (Exception e) {
               e.printStackTrace();
          splashScreen.close();
          SwingUtilities.invokeLater(new Runnable() {
               public void run() {
                    try {
                         JFrame frame = new JFrame("Try it again");
                         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                         final BufferedImage image = ImageIO.read(IMAGE_FILE);
                         Graphics2D g2d = image.createGraphics();
                         g2d.setColor(Color.RED);
                         g2d.fillRect(0, 200, 300, 100);     // draw red rectangle across bottom
                         g2d.dispose();
                         JPanel panel = new JPanel() {
                              @Override
                              protected void paintComponent(Graphics g) {
                                   super.paintComponent(g);
                                   g.drawImage(image, 0, 0, this);
                         frame.setContentPane(panel);
                         frame.setSize(300, 300);
                         frame.setLocationRelativeTo(null);
                         frame.setVisible(true);
                    } catch (IOException ioe) {
                         ioe.printStackTrace();
}The rectangle shows up completely in the JPanel, which suggests the problem is somehow specific to the SplashScreen. For now I'm just going to edit the image so I'm not trying to paint over any transparent regions. But if anyone can shed any light on this, please do. :-)
Edited by: Skotty on Jul 26, 2010 10:17 PM

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

Sending datagram packets over LAN

I have made a client server application.
When running in netbeans both client and server in the same computer the datagram packets get transferred and the transfer works properly.
but when i shift the client application to another computer in the LAN the datagram packets do not reach the Server. What may be the problem ?What can be the solution ?

Broadcast/Multi-cast packets and often blocked by default but routers. i.e. you will see them if you are on the same router but no where else.
This is to prevent such packets flooding the whole network. (Although there are better ways to deal with this, this is the simplest approach)
You need to ensure that all the routers between your two systems allow forwarding of UDP packets.

How to prevent packet forwarding over non-MPLS connection.

I'm wondering if it is possible to configure Cisco ESR to not forward packet over non-MPLS connection(VPI/VCI=0/32) when an LSP for its destination has not been established, while allowing control packets(BGP, LDP, OSPF) to be sent over non-MPLS connection. The reason why I ask about is as follows.
Referring to the following network configuration,
R1 --- Cisco_ESR --- ATM_LSR --- LER --- R2
<--> non-MPLS connection
----------------------->
LSPs
----------------------->
In the ordinary operation, when a packet arrives at Cisco_LER from R1, it gets forwarded over an LSP if available, while getting forwarded over non-MPLS connection(VPI/VCI=0/32) if the corresponding LSP is not available. In the configuration mentioned above,ATM_LSR does software-based packet processing for incoming packet through non-MPLS channel, while doing cell-switching for LSP traffic. Thus if ESR sends packet over non-MPLS connection, e.g, STM-1c, the ATM_LSR could get crashed or time-critical control traffic could be delayed or lost, thereby resulting in BGP/LDP session failure between ESR and ATM_LSR or LER.
In summary, my question is how to prevent Cisco_ESR from forwarding packets over non-MPLS connection when LSPs for their destinations are not available due to LSP failures.
Thanks.
Yongjun.

It already is, except for Aliens, they have access to everything on your phone(they always have had this access) .

Ospf retransmission packet over transparent fwsm

Similar Messages

Maybe you are looking for