Packets in XI

Hi All,
I had almost 80,000 records that to be send in a day from BW to Oracle by using proxy,
so how can i set them in a Packet size?
Where can i set the Packets?
How much i can set as Max size of Packet?
Points will be rewarded.
Thanks in Advance,
Sriram

hi
did u get any performance issues while sending 80,000 records from BW to Oracle?
so u want to send records through proxy communication as packets (like idoc).
i think it is not possible by using proxies.
if so plz update in sdn.
regards
pradeep.

Similar Messages

Unable to capture packets on ASA(ASDM)

Hi all,
We have site to site VPN connection to one of our client. From which we both are accessing our applications and other resources. Now client needs to acccess two of our internal server. So we have created Static NAT in our ASA. For one server they are accessing without any issues. But the other server they are not able to connect. Since its vpn tunnel we havent blocked any ports and its open to all traffic. But their side they have restricted and we need to see whether the packets hitting our ASA or not. Once we observes this, its easy for us to escalate them. I tried packet capture wizard in ASDM. But its not showing anything. Can anyone tell me how to capture packets realated to Static NAT. Please let me know if you want anyother details?
local 20.0.0.0/24 -->this will get natted to --->12.0.6.0/24 when going in for tunnel
we have created
static(outside,inside) 12.0.6.10 20.0.0.10 255.255.255.255 working
static(outside,inside) 12.0.6.11 20.0.0.11 255.255.255.255 not working, we need to check whether its hitting 12.0.6.11
Kindly advise...
Regards,
Bala

Where are you trying to initiate the connection from?
If they are trying to initiate the connection towards your end, and the traffic doesn't reach your end, then there will be nothing on your ASA packet capture.
Please share what you have configured to capture the traffic?
To check if the traffic is reaching the inside interface, just configure ACL between source (real IP) and destination (remote IP), and apply the capture on the inside interface. This will confirm if the traffic is coming inbound towards the inside interface.
To check if the traffic is leaving the inside interface towards the host behind your ASA, configure ACL between source (remote IP), and destination (host real IP), and apply the capture on the inside interface. This will confirm if the traffic is leaving your ASA inside interface towards the host.

Traceroute timeouts and lots of packet loss when a...

I host various site via the above, and since late last night and today, I am having connection timeout issues on all of them (but sites like bbc, bt etc are fine). I contacted them and performed a traceroute to my default site southee.co.uk which timed out. Below are the results:
traceroute to southee.co.uk (37.61.236.12), 64 hops max, 52 byte packets
1 bthomehub (192.168.1.254) 2.733 ms 2.414 ms 2.415 ms
2 esr5.manchester5.broadband.bt.net (217.47.67.144) 72.412 ms 29.705 ms 131.735 ms
3 217.47.67.13 (217.47.67.13) 31.390 ms 29.680 ms 103.936 ms
4 213.1.69.226 (213.1.69.226) 41.172 ms 32.700 ms 129.323 ms
5 31.55.165.103 (31.55.165.103) 30.791 ms 31.639 ms 130.306 ms
6 213.120.162.69 (213.120.162.69) 31.248 ms 59.138 ms 30.657 ms
7 31.55.165.109 (31.55.165.109) 32.159 ms 31.507 ms 31.513 ms
8 acc2-10gige-9-2-0.mr.21cn-ipp.bt.net (109.159.250.228) 31.499 ms 31.325 ms
acc2-10gige-0-2-0.mr.21cn-ipp.bt.net (109.159.250.194) 31.197 ms
9 core2-te0-12-0-1.ealing.ukcore.bt.net (109.159.250.147) 41.744 ms
core2-te0-13-0-0.ealing.ukcore.bt.net (109.159.250.139) 41.346 ms
core2-te0-5-0-1.ealing.ukcore.bt.net (109.159.250.145) 41.744 ms
10 peer1-xe3-3-1.telehouse.ukcore.bt.net (109.159.254.211) 39.527 ms
peer1-xe10-0-0.telehouse.ukcore.bt.net (109.159.254.122) 38.791 ms 38.910 ms
11 te2-3.sov-edge1.uk.timico.net (195.66.224.111) 54.032 ms 37.941 ms 38.642 ms
12 78-25-201-30.static.dsl.as8607.net (78.25.201.30) 45.830 ms 46.413 ms 42.448 ms
13 * * *
They then performed a traceroute from the server and got the following, again with timeouts and packet loss. See below:
1. 37.61.236.1 0.0% 10 0.5 0.7 0.4 2.9 0.8
2. ae0-2061.ndc-core1.uk.timico 0.0% 10 0.3 0.3 0.2 0.5 0.1
3. te2-3.sov-edge1.uk.timico.ne 0.0% 10 10.5 9.7 4.2 30.2 8.7
4. linx1.ukcore.bt.net 0.0% 10 4.1 4.3 4.1 5.9 0.6
5. host213-121-193-153.ukcore.b 0.0% 10 5.5 8.0 4.9 12.7 2.3
6. acc2-10GigE-4-3-1.mr.21cn-ip 0.0% 10 11.4 11.4 11.4 11.6 0.1
7. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8. 31.55.165.108 0.0% 10 12.1 12.1 11.8 12.4 0.2
9. 213.120.162.68 0.0% 10 12.0 12.1 12.0 12.3 0.1
10. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
I've just spent a fustrating 15 minutes with Bt Support chat who just seemed want to pass me on to the BT Business team, so I thought I'd post here, for a more informed response.

Hi Jane, Thanks for the reply. I have now purchased an AEBS(n) to try to overcome this problem. The Apple site says it is compatible with all versions of Airport card so I thought it would solve the problem. My new problem is to be found here: http://discussions.apple.com/thread.jspa?threadID=1087292&tstart=0
However to answer your questions, The OS is 10.4.10 and I have run every updater I can find for all Macs concerned. hope this helps.

Unable to receive UDP broadcast packets on PPP connection

I am struggling for two days now with no success. I have two modems (do not ask, some special stuff), that uses dial up (PPP) connection. I tried this on windows XP and it works like a charm. I am sending unicast and broadcast UPD packets. If I
repeat that on Windows 7 i can send only unicast data, broadcast packets seems to be lost somewhere. I tried to use Microsoft Network Monitor and I can see that broadcasted packets are being received on my PPP connection. But after that, they are gone. Somewhere
in the kernel. I truly do not understand why. I disabled firewall, antivirus, base filtering engine, tried to log dropped packed in Windows
Filtering Platform, tried clean WIN7 machine and all that with no success.
Here is a sample packet received on interface, but it has newer reach my app:
No. Time Source Destination Protocol Length Info
1 13:20:56.093380000 192.168.1.50 192.168.1.255 UDP 49 Source port: x11 Destination port: x11
Frame 1: 49 bytes on wire (392 bits), 49 bytes captured (392 bits)
Encapsulation type: Ethernet (1)
Arrival Time: May 7, 2014 13:20:56.093380000 Central Europe Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1399461656.093380000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 49 bytes (392 bits)
Capture Length: 49 bytes (392 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:udp:data:vssmonitoring]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: ae:4e:20:00:01:00 (ae:4e:20:00:01:00), Dst: Xerox_00:00:00 (01:00:01:00:00:00)
Destination: Xerox_00:00:00 (01:00:01:00:00:00)
Address: Xerox_00:00:00 (01:00:01:00:00:00)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: ae:4e:20:00:01:00 (ae:4e:20:00:01:00)
Address: ae:4e:20:00:01:00 (ae:4e:20:00:01:00)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.1.50 (192.168.1.50), Dst: 192.168.1.255 (192.168.1.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 34
Identification: 0x0032 (50)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 126
Protocol: UDP (17)
Header checksum: 0xb817 [correct]
[Good: True]
[Bad: False]
Source: 192.168.1.50 (192.168.1.50)
Destination: 192.168.1.255 (192.168.1.255)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: x11 (6001), Dst Port: x11 (6001)
Source port: x11 (6001)
Destination port: x11 (6001)
Length: 14
Checksum: 0xafd1 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Data (6 bytes)
0000 34 34 34 34 34 34 444444
Data: 343434343434
[Length: 6]
VSS-Monitoring ethernet trailer, Source Port: 127
Src Port: 127
I am running out of my ideas, if anyone could help, with any idea, please do. I am not sure if this feature is dropped in win7 or not.

Hi,
From your description, you may gather the network monitor traces to ensure which part lost UDP broadcast packets.
Thank you.
Best regards,
Stevens Song
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Getting the data from a TCP/IP packet

I am dealing with an industrial network that sends and recieves data over TCP/IP between a sort of supervisory system running on Unix and some machines via a bridge that converts messages onto other non TCP/IP networks. This is all old legacy equipment and the bridge now need upgrading. However the original source code is not availiable and no-one is very sure of the messages being sent. I thought it was going to be easy knocking something together in Java to intercept these messages and test various things but have come up against big problems.
The main problem being that all the data is binary meaning I cant use any of the reader or writer classes I am used too. I am trying to use either DataInputStream or BufferedInputStream to read data in but am struggling. Idealy I need to be able to read (once) the complete data content of each packet that is sent and I need to tell each time a new packet of data arrives so that I can process it as a complete packet. As far as I know there are no eof or eol or any other details that tell me how many bytes of data there are, and they do vary in length, but each packet is a seperate message or message reply.
I was hoping that there might be someway of getting this information from the TCP/IP layers but cant see how to do it as that all seems to work invisibly. Nor can I see any methods to call on the stream classes that indicate how to tell the lenght of the latest packet or when a new packet has arrived. I am not sure how some of the methods like mark() and reset|() are supposed to be used so am not sure if I couuld use these but am desperate for any help or pointers in the right direction.

The TCP/IP packets can represent complete messagesThere is no guarantee to this effect anywhere in TCP/IP. Consider the case where a single message requires multiple writes. Consider the case where a write contains the end of one message and the beginning of another. Consider the case where there are multiple messages in a single packet. Consider ... There are just too many of these cases.
The TCP/IP takes care of numbering the packets so that they can be reasembled in the correct order. Each TCP/IP packet contains information about the size of data the packet contains ...Thank you, I do know how TCP works.
so in theory if we could get at the TCP/IP layers we should be able to get this information.No. You can get all the packet information out of packets. What you can't get is message information, because it isn't in there. It's in the application protocol, which to TCP/IP is just a stream of bytes. You can get the stream of bytes that the application sent. What it means is up to you.
I really need to be able to read each packet of data seperately to be able to do anything with itWhy? Given the lack of correlation between writes() and packets and reads() due to TCP streaming, what is the point? And if you want packets you already have them via your sniffer.
From your first post:
each packet is a seperate message or message reply.You can't rely on that. There is no guarantee of this anywhere in TCP/IP.
I also direct your attention to the Nagle algorithm, which coalesces outgoing packets under common conditions.

Terrible Packet Loss in Game- Please help!

Computing statistics for 100 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Sam-PC.home [192.168.1.5]
0/ 25 = 0% |
1 2ms 0/ 25 = 0% 0/ 25 = 0% Wireless_Broadband_Router.home [192.168.1.1]
1/ 25 = 4% |
2 13ms 1/ 25 = 4% 0/ 25 = 0% L100.WASHDC-VFTTP-126.verizon-gni.net [173.66.228.1]
0/ 25 = 0% |
3 11ms 1/ 25 = 4% 0/ 25 = 0% G1-5-0-4.WASHDC-LCR-21.verizon-gni.net [130.81.213.68]
0/ 25 = 0% |
4 20ms 1/ 25 = 4% 0/ 25 = 0% so-12-1-0-0.RES-BB-RTR1.verizon-gni.net [130.81.151.230]
0/ 25 = 0% |
5 12ms 1/ 25 = 4% 0/ 25 = 0% 0.xe-8-0-0.BR2.IAD8.ALTER.NET [152.63.38.129]
0/ 25 = 0% |
6 34ms 1/ 25 = 4% 0/ 25 = 0% ae17.edge1.washingtondc12.level3.net [4.68.62.137]
0/ 25 = 0% |
7 33ms 2/ 25 = 8% 1/ 25 = 4% vl-3503-ve-117.ebr1.Washington12.Level3.net [4.69.158.26]
0/ 25 = 0% |
8 29ms 3/ 25 = 12% 2/ 25 = 8% ae-6-6.ebr1.Atlanta2.Level3.net [4.69.148.105]
0/ 25 = 0% |
9 30ms 2/ 25 = 8% 1/ 25 = 4% ae-63-63.ebr3.Atlanta2.Level3.net [4.69.148.241]
0/ 25 = 0% |
10 50ms 1/ 25 = 4% 0/ 25 = 0% ae-7-7.ebr3.Dallas1.Level3.net [4.69.134.21]
1/ 25 = 4% |
11 56ms 2/ 25 = 8% 0/ 25 = 0% ae-63-63.csw1.Dallas1.Level3.net [4.69.151.133]
0/ 25 = 0% |
12 54ms 2/ 25 = 8% 0/ 25 = 0% ae-1-60.edge2.Dallas1.Level3.net [4.69.145.11]
0/ 25 = 0% |
13 54ms 2/ 25 = 8% 0/ 25 = 0% 4.59.197.34
1/ 25 = 4% |
14 50ms 3/ 25 = 12% 0/ 25 = 0% 64.25.32.9
0/ 25 = 0% |
15 --- 25/ 25 =100% 22/ 25 = 88% 64.25.32.26
0/ 25 = 0% |
16 48ms 3/ 25 = 12% 0/ 25 = 0% 64.25.39.1
These are the results of a test I ran, but I don't know how to solve the problem. The game is unplayable because of the amount of packet loss. I know it is an issue of connection between the game and my router, so should I get a new router if mine is old?

The router I would imagine to be okay for the first bit, but for the sake of things, reboot the router and also try giving your ONT a reboot by unplugging it from AC power and then disconnecting the battery. Re-connect it after 30 seconds by connecting the battery and then plugging it back into AC power.
Also, see if the packet loss takes place during specific times of the day. If your router has a WAN connection over Coax (rather than an Ethernet connection) to your ONT, also consider checking your MoCa speeds based on this FAQ. Poor MoCa speeds can suggest shoddy coaxial causing some issues, too: https://secure.dslreports.com/faq/verizonfios/3.2_MOCA#16569
========
The first to bring me 1Gbps Fiber for $30/m wins!

DMVPN-Why received packet doesn't use UDP port 4500 but 500?

Hello everyone
I got a problem with my DMVPN. Spoke is behind a NAT device. x.x.x.x is an public IP address which hub uses. I don't know why it discovered that the hub is also inside a NAT device. And after it sends a packet using port 4500, the received packet from hub was not using port 4500 but 500. I'm confused now. Any advise would be much appreciated.
*Sep 10 08:56:02 UTC: ISAKMP:(0): beginning Main Mode exchange
*Sep 10 08:56:02 UTC: ISAKMP:(0): sending packet to x.x.x.x my_port 500 peer_port 500 (I) MM_NO_STATE
*Sep 10 08:56:02 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Sep 10 08:56:02 UTC: ISAKMP (0): received packet from x.x.x.x dport 500 sport 500 Global (I) MM_NO_STATE
*Sep 10 08:56:02 UTC: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Sep 10 08:56:02 UTC: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_I_MM2
*Sep 10 08:56:02 UTC: ISAKMP:(0): processing SA payload. message ID = 0
*Sep 10 08:56:02 UTC: ISAKMP:(0): processing vendor id payload
*Sep 10 08:56:02 UTC: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
*Sep 10 08:56:02 UTC: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Sep 10 08:56:02 UTC: ISAKMP:(0):found peer pre-shared key matching
*Sep 10 08:56:02 UTC: ISAKMP:(0): local preshared key found
*Sep 10 08:56:02 UTC: ISAKMP : Scanning profiles for xauth ...
*Sep 10 08:56:02 UTC: ISAKMP:(0):Checking ISAKMP transform 1 against priority 1 policy
*Sep 10 08:56:02 UTC: ISAKMP: encryption 3DES-CBC
*Sep 10 08:56:02 UTC: ISAKMP: hash MD5
*Sep 10 08:56:02 UTC: ISAKMP: default group 1
*Sep 10 08:56:02 UTC: ISAKMP: auth pre-share
*Sep 10 08:56:02 UTC: ISAKMP: life type in seconds
*Sep 10 08:56:02 UTC: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
*Sep 10 08:56:02 UTC: ISAKMP:(0):atts are acceptable. Next payload is 0
*Sep 10 08:56:02 UTC: ISAKMP:(0):Acceptable atts:actual life: 0
*Sep 10 08:56:02 UTC: ISAKMP:(0):Acceptable atts:life: 0
*Sep 10 08:56:02 UTC: ISAKMP:(0):Fill atts in sa vpi_length:4
*Sep 10 08:56:02 UTC: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
*Sep 10 08:56:02 UTC: ISAKMP:(0):Returning Actual lifetime: 86400
*Sep 10 08:56:02 UTC: ISAKMP:(0)::Started lifetime timer: 86400.
*Sep 10 08:56:02 UTC: ISAKMP:(0): processing vendor id payload
*Sep 10 08:56:02 UTC: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
*Sep 10 08:56:02 UTC: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Sep 10 08:56:02 UTC: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Sep 10 08:56:02 UTC: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM2
*Sep 10 08:56:02 UTC: ISAKMP:(0): sending packet to x.x.x.x my_port 500 peer_port 500 (I) MM_SA_SETUP
*Sep 10 08:56:02 UTC: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Sep 10 08:56:02 UTC: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Sep 10 08:56:02 UTC: ISAKMP:(0):Old State = IKE_I_MM2 New State = IKE_I_MM3
*Sep 10 08:56:02 UTC: ISAKMP (0): received packet from x.x.x.x dport 500 sport 500 Global (I) MM_SA_SETUP
*Sep 10 08:56:02 UTC: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Sep 10 08:56:02 UTC: ISAKMP:(0):Old State = IKE_I_MM3 New State = IKE_I_MM4
*Sep 10 08:56:02 UTC: ISAKMP:(0): processing KE payload. message ID = 0
*Sep 10 08:56:02 UTC: ISAKMP:(0): processing NONCE payload. message ID = 0
*Sep 10 08:56:02 UTC: ISAKMP:(0):found peer pre-shared key matching x.x.x.x
*Sep 10 08:56:02 UTC: ISAKMP:(2746): processing vendor id payload
*Sep 10 08:56:02 UTC: ISAKMP:(2746): vendor ID is Unity
*Sep 10 08:56:02 UTC: ISAKMP:(2746): processing vendor id payload
*Sep 10 08:56:02 UTC: ISAKMP:(2746): vendor ID is DPD
*Sep 10 08:56:02 UTC: ISAKMP:(2746): processing vendor id payload
*Sep 10 08:56:02 UTC: ISAKMP:(2746): speaking to another IOS box!
*Sep 10 08:56:02 UTC: ISAKMP:received payload type 20
*Sep 10 08:56:02 UTC: ISAKMP (2746): NAT found, both nodes inside NAT
*Sep 10 08:56:02 UTC: ISAKMP:received payload type 20
*Sep 10 08:56:02 UTC: ISAKMP (2746): My hash no match - this node inside NAT
*Sep 10 08:56:02 UTC: ISAKMP:(2746):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Sep 10 08:56:02 UTC: ISAKMP:(2746):Old State = IKE_I_MM4 New State = IKE_I_MM4
*Sep 10 08:56:02 UTC: ISAKMP:(2746):Send initial contact
*Sep 10 08:56:02 UTC: ISAKMP:(2746):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
*Sep 10 08:56:02 UTC: ISAKMP (2746): ID payload
next-payload : 8
type : 1
address : 192.168.1.101
protocol : 17
port : 0
length : 12
*Sep 10 08:56:02 UTC: ISAKMP:(2746):Total payload length: 12
*Sep 10 08:56:02 UTC: ISAKMP:(2746): sending packet to x.x.x.x my_port 4500 peer_port 4500 (I) MM_KEY_EXCH
*Sep 10 08:56:02 UTC: ISAKMP:(2746):Sending an IKE IPv4 Packet.
*Sep 10 08:56:02 UTC: ISAKMP:(2746):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Sep 10 08:56:02 UTC: ISAKMP:(2746):Old State = IKE_I_MM4 New State = IKE_I_MM5
*Sep 10 08:56:03 UTC: ISAKMP (2746): received packet from x.x.x.x dport 500 sport 500 Global (I) MM_KEY_EXCH
*Sep 10 08:56:03 UTC: ISAKMP:(2746): phase 1 packet is a duplicate of a previous packet.
*Sep 10 08:56:03 UTC: ISAKMP:(2746): retransmitting due to retransmit phase 1
*Sep 10 08:56:04 UTC: ISAKMP:(2746): retransmitting phase 1 MM_KEY_EXCH...
*Sep 10 08:56:04 UTC: ISAKMP (2746): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
*Sep 10 08:56:04 UTC: ISAKMP:(2746): retransmitting phase 1 MM_KEY_EXCH
*Sep 10 08:56:04 UTC: ISAKMP:(2746): sending packet to x.x.x.x my_port 4500 peer_port 4500 (I) MM_KEY_EXCH
*Sep 10 08:56:04 UTC: ISAKMP:(2746):Sending an IKE IPv4 Packet.

This could be because the port 4500 packet that is being sent is not being received by the peer side or it is ignoring that packet.
Since the port 500 packet that you are receiving is a duplicate of the previous packet it is definitely not a reply packet for the port 4500 packet.
If you can get the debugs from the other end, then you could see if the peer side is receiving the udp port 4500 packets.
If not that then this could be a UDP port 4500 block with the ISP.

Regrd the data packet size

Hi
i have two questions
1) where can i set the data packet size in BW and R3 and also in BI how and where can we set .
2)by what method/logic we will select the key fields in dso.
ex: i have 5 tables in the sourse and each table will have primary keys, now how do we know that particular primary keys should be kept in KEY FIELDS folder in DSO.
full points will be assigned.

HI,
Data package settings for the data to be extracted from R3 to BI can be done through :
1) SBIW>General Settings> Maintain Control Parameters for Data Transfer
These settings are common for all the info packages which extract data from R3.
2) If u want to do settings relevent to specific Infopackage then :
RSA1>Click On the Specific Infopackage>Scheduler(in the Menu Bar)-->DataS Default Data Transfer.
3) And if you want to do DSO Package settings then:
Got to Transaction RSODSO_SETTINGS
Here u can do package settings for DSO activation ,paramenter for SID generation ect.
And selection of Key fileds depends upon the requirement.
Based on the key fields what all the data fileds u want to overwrite or add the corespomding data fields
Regards,
Chaitanya.

Cisco ASA VPN question: %ASA-4-713903: IKE Receiver: Runt ISAKMP packet

Dear community,
quite frequently I am now receiving the following error message in my ASA 5502's log:
Oct 17 12:52:17 <myASA> %ASA-4-713903: IKE Receiver: Runt ISAKMP packet discarded on Port 4500 from <some_ip>:<some_port>
Oct 17 12:52:22 <myASA> %ASA-4-713903: IKE Receiver: Runt ISAKMP packet discarded on Port 4500 from <some_ip>:<some_port>
Oct 17 12:52:27 <myASA> %ASA-4-713903: IKE Receiver: Runt ISAKMP packet discarded on Port 4500 from <some_ip>:<some_port>
The VPN Clients (in the last case: A linux vpnc) disconnect with message
   vpnc[7736]: connection terminated by dead peer detection
The ASA reports for that <some_ip> at around the same time:
Oct 17 12:52:32 <myASA> %ASA-4-113019: Group = blah, Username = johndoe, IP = <some_ip>, Session disconnected. Session Type: IPSecOverNatT, Duration: 2h:40m:35s, Bytes xmt: 2410431, Bytes rcv: 23386708, Reason: User Requested
A google search did not reveal any explanation to the "%ASA-4-713903: IKE Receiver: Runt ISAKMP packet..." message -- so my questions would be
   1) What does the message exactly mean -- I know runts as a L2 problem so I d suppose it means the same: The ISAKMP packet is somehow
       crippled (I d suppose this happens during rekeying) ?
   2) Any idea where to look for the cause of this
          WAN related (however I d assume no -- why does this happen in these regular time frames as show above)?
          SW related (vpnc bug)?
Thanks in advance for any pointer...
Joachim

Yes. You need to eliminate the things I've said to eliminate with the other side. Ensure your configs are matching exactly. They probably are, whatever, just make sure of it because it's easy. You both need to run packet captures on your interfaces both in and out to even begin to have an idea of where to look.
The more info you can have just one person responsible for the better. What I mean by that is, it's typically a nice step for the 'bigger end' to have the 'smaller end's' config file to look at.
If you are seeing packets come in your inside, leave your outside, and never make it to his inside, then take it a step at a time.
If you're seeing them come in his interface and never come back out, you know where to look.
Set your caps to a single host to single host if need be, and generate traffic accordingly.
You need to narrow down where NOT to look so that you know where TO look. I would say then, and only then, do you get the ISP involved. Once you're sure the problem exists between his edge device and your edge device.
I do exactly this for a living on a daily basis...day after day after day. I'm responsible for over 200 IPSec s2s connections and thousands of SSL VPN sessions. I always start the exact same way...from the very bottom.

ASA 5505 remote vpn - not receiving packets from ASA

I am having problem configuring remote vpn between ASA5505 and Cisco VPN client v5. I can successfully establish connection between ASA and Vpn client and receive IP address from ASA. VPN client statistics windows shows that packets are send and encrypted but none of the packets is Received/Decrypted. Any ideas on what I have missed?
Thanks in advance for any help,M

crypto isakmp nat-traversal
Please rate helpful posts.

WIFI Packet Loss/Jitter MacBook Air 11 & LION OSX 10.7.1

I started using computers more than 30 years ago when I was 5, I had my first IBM PC at the age of 10 and have never had any interest in paying over the odds for an Apple mac mainly because I saw the Mac as a kind of "Can't open nothing", one mouse buttoned retard of the computer world.
That is, until now.
I set up an online business 3 years ago and rented a dedicated server and set the whole business up in a cloud, so to speak. Having done that, all I needed a laptop for was a remote desktop connection and to run a SIP phone (Internet phone).
My PC based laptops had almost nothing installed on them, and I wasn't using software on the laptop itself, I was using remote desktop, so - why not try a MAC? The new Macbook Air 11 is small, light and made of metal and glass so should be robust enough to travel with me.
I have to say, this was the worst move I've ever made.
I opened the new shiny macbook and the first thing I noticed was that the internet seemed hit and miss. Moving around the room I managed to find a spot whereby pages woud load quickly. Strange, my £200 acer laptop was sh.t fast everywhere in the house. No matter, I packed it back away and carried on working on the Windows machine.
I've come to Newquay this week, and i've started to try and use the Macbook again in a hotel. The wireless signal in the room is low, and speedtest shows about 1 meg down and 3/4 meg up. That may sound bad to you, but remote desktop uses about 5k/sec (modem dial up speed) and the softphone, well, my Asterisk VOIP setup is confugured to use the GSM codec so that's 8k/sec each way + overheads.
This whole setup was deliberately designed to be "thin" so I can travel with ease and work on bad connections like USB internet sticks.
Anyhow, the Macbook was unable to hold a stable connection to the remote desktop or SIP phone, even though the speed test showed a whopping 1 meg up and down. What you may not be aware of is that there is more to a connection than the speed, there is the quality as well. How many packets are lost / how much "jitter" is on the line.
Anyhow, we're not living in the 3rd world, I ran a PINGTEST and it showed a small amount of jitter but told me the line was class B, online games may suffer but voip should be fine.
I unpacked the Acer, placed it in exactly the same spot as the Apple had sat in and it worked beautifully with 1 bar of wireless signal, all day long. Phone calls were clear.
So you know now what I'm thinking. I'm sitting here with my £200 acer because I can't use the £1500 macbook air 11. I paid nearly sixteen hundred pounds for this piece of .... and it doesn't ...... work. Time to contact Apple support.
2nd Mistake!
Representitive 1: - Told me that I can't compare the Macbook Air to the Acer, the Acer has Google Chrome and everybody knows Google Chrome is the fastest browser. I was told there was nothing more he could do, its probably a bad line at the hotel. When I explained the Acer works fine for voip I was told well, maybe it is getting a better signal. I explained the Acer has the cheapest possible parts inside it and paid 1500 for this macbook, expecting it to have quality parts inside and was told I'd paid for the size, because its so small but its not considered "powerful". Apple do you train your staff? Clearly not.
Thank god I wasn't paying to talk to this moron.
Representitive 2: - Had no idea what packet loss or Jitter was, got me to do a speedtest and said that looks fine. Then he got me to remove the WIFI adapter and re add it in the network settings.
Guess what, nothing changed, its still the same hardware and software.
Representitive 3: - Still not really understanding "quality" issues with the networking interface, I was asked to install the latest Java client. I did it, only because I wanted to comply with Apples wishes so they'd help me, but they weren't helping and Java has nothing to do with the network adapter, so that was useless advice too.
Apple seem to have no idea there is a problem, even though Google has pages and pages of people saying the same as me, and their own discussion forums have thousands of people complaining https://discussions.apple.com/thread/2664670?start=0&tstart=0
Finally, late yesterday whilst speaking to d.ck head number 3 at Apple support, we found a forum post talking about a fix, 10.7.1 update. I told d. head number 3 about the update and he suggested I applied it. So I did and everything looked great, for a whole evening.
This morning, I switched on again and the same thing, slow remote desktop, choppy unusable phone. Remember the phone needs less than 20k for a conversation, thats 0.2 meg. Speedtest again showing a whole meg both ways.
I called apple support again, this time being a little forceful, and I've asked for this to be escalated, but the bottom line is - they have no fix, they don't aknowledge this as a problem and I was told LION is new, so maybe it's got a bug..
I told the guy on the phone this is a network driver issue, the intermittency of the problem shows that and the Apple's lack of settings for the network adapter means the unit is autonegotiating with the router and choosing speed and duplex settings on its own. Sometimes it does that correctly, other times not and the connection although fast has a lot of noise / packet loss / corruption.
I've found a workaround, you put the unit to sleep and wake it up again and it runs fast until the next shutdown. Not really acceptable seeing as I was paying for "the cream of the crop".
I will definately not be recommending Apple products, and i'll certainly not be replacing the Windows laptops in my business with Apple's toytown system- i'd go out of business if I had to rely on this.
All there is left now, is to look at Boot camp and see if I can wipe this waste of space linux hack from the unit and install Windows 7.

I started using computers more than 30 years ago when I was 5, I had my first IBM PC at the age of 10 and have never had any interest in paying over the odds for an Apple mac mainly because I saw the Mac as a kind of "Can't open nothing", one mouse buttoned retard of the computer world.
That is, until now.
I set up an online business 3 years ago and rented a dedicated server and set the whole business up in a cloud, so to speak. Having done that, all I needed a laptop for was a remote desktop connection and to run a SIP phone (Internet phone).
My PC based laptops had almost nothing installed on them, and I wasn't using software on the laptop itself, I was using remote desktop, so - why not try a MAC? The new Macbook Air 11 is small, light and made of metal and glass so should be robust enough to travel with me.
I have to say, this was the worst move I've ever made.
I opened the new shiny macbook and the first thing I noticed was that the internet seemed hit and miss. Moving around the room I managed to find a spot whereby pages woud load quickly. Strange, my £200 acer laptop was sh.t fast everywhere in the house. No matter, I packed it back away and carried on working on the Windows machine.
I've come to Newquay this week, and i've started to try and use the Macbook again in a hotel. The wireless signal in the room is low, and speedtest shows about 1 meg down and 3/4 meg up. That may sound bad to you, but remote desktop uses about 5k/sec (modem dial up speed) and the softphone, well, my Asterisk VOIP setup is confugured to use the GSM codec so that's 8k/sec each way + overheads.
This whole setup was deliberately designed to be "thin" so I can travel with ease and work on bad connections like USB internet sticks.
Anyhow, the Macbook was unable to hold a stable connection to the remote desktop or SIP phone, even though the speed test showed a whopping 1 meg up and down. What you may not be aware of is that there is more to a connection than the speed, there is the quality as well. How many packets are lost / how much "jitter" is on the line.
Anyhow, we're not living in the 3rd world, I ran a PINGTEST and it showed a small amount of jitter but told me the line was class B, online games may suffer but voip should be fine.
I unpacked the Acer, placed it in exactly the same spot as the Apple had sat in and it worked beautifully with 1 bar of wireless signal, all day long. Phone calls were clear.
So you know now what I'm thinking. I'm sitting here with my £200 acer because I can't use the £1500 macbook air 11. I paid nearly sixteen hundred pounds for this piece of .... and it doesn't ...... work. Time to contact Apple support.
2nd Mistake!
Representitive 1: - Told me that I can't compare the Macbook Air to the Acer, the Acer has Google Chrome and everybody knows Google Chrome is the fastest browser. I was told there was nothing more he could do, its probably a bad line at the hotel. When I explained the Acer works fine for voip I was told well, maybe it is getting a better signal. I explained the Acer has the cheapest possible parts inside it and paid 1500 for this macbook, expecting it to have quality parts inside and was told I'd paid for the size, because its so small but its not considered "powerful". Apple do you train your staff? Clearly not.
Thank god I wasn't paying to talk to this moron.
Representitive 2: - Had no idea what packet loss or Jitter was, got me to do a speedtest and said that looks fine. Then he got me to remove the WIFI adapter and re add it in the network settings.
Guess what, nothing changed, its still the same hardware and software.
Representitive 3: - Still not really understanding "quality" issues with the networking interface, I was asked to install the latest Java client. I did it, only because I wanted to comply with Apples wishes so they'd help me, but they weren't helping and Java has nothing to do with the network adapter, so that was useless advice too.
Apple seem to have no idea there is a problem, even though Google has pages and pages of people saying the same as me, and their own discussion forums have thousands of people complaining https://discussions.apple.com/thread/2664670?start=0&tstart=0
Finally, late yesterday whilst speaking to d.ck head number 3 at Apple support, we found a forum post talking about a fix, 10.7.1 update. I told d. head number 3 about the update and he suggested I applied it. So I did and everything looked great, for a whole evening.
This morning, I switched on again and the same thing, slow remote desktop, choppy unusable phone. Remember the phone needs less than 20k for a conversation, thats 0.2 meg. Speedtest again showing a whole meg both ways.
I called apple support again, this time being a little forceful, and I've asked for this to be escalated, but the bottom line is - they have no fix, they don't aknowledge this as a problem and I was told LION is new, so maybe it's got a bug..
I told the guy on the phone this is a network driver issue, the intermittency of the problem shows that and the Apple's lack of settings for the network adapter means the unit is autonegotiating with the router and choosing speed and duplex settings on its own. Sometimes it does that correctly, other times not and the connection although fast has a lot of noise / packet loss / corruption.
I've found a workaround, you put the unit to sleep and wake it up again and it runs fast until the next shutdown. Not really acceptable seeing as I was paying for "the cream of the crop".
I will definately not be recommending Apple products, and i'll certainly not be replacing the Windows laptops in my business with Apple's toytown system- i'd go out of business if I had to rely on this.
All there is left now, is to look at Boot camp and see if I can wipe this waste of space linux hack from the unit and install Windows 7.

My MBP has started to send out TCP packets larger than the MTU on the NIC - is there any place that this can be overriden?

Got a very weird issue here and wondering if anyone has any other ideas. Basically over the wired NIC only, my Mac has started to send out large HTTP/HTTPS packets from the browser (> 1500 bytes) Captures show packet sizes from 2000 all the way to 4000 sometimes. This happens in Firefox and Chrome so doesn't appear to be application related.
This causes fragmentation issues and traffic drops which basically causes most of my websites and tools to crash and burn (and I get all sorts of SSL errors from applications, etc).
It appears to be limited to just TCP packets as pings with the DF bit set will not send any larger than 1500 bytes.
However if I switch to wireless, everything works fine and captures show the correct maximum packet size of 1500 for all packets leaving my client.
The MTU on the en0 interface is 1500 as per ifconfig and I made sure that it was set to 1500 in Network config panel (because there is an option for jumbo frames there which bumps up the MTU).
A packet capture also shows that during the three way handshake the TCP MSS is successfully sent and negotiated as 1480, but then it appears to ignore that when sending packets later in the TCP stream.
I've rebooted, upgraded to 10.7.4, checked the "sysctl" outputs and matched against a Mac not having the issue.
This is the newest MBP 15 inch model.
Any other ideas on things to check?

Have you used any sort of "tuner" software? You are obviously an advanced user. Sometimes we hack things up and forget about it later. If you are sure you didn't do that, maybe poke around with IPv6 settings. Supposedly people are trying to enable that and it is going to be a disaster.

How to decipher SQL*Net protocols/packets?

hi,
we have a customer that sells compliance solutions that basically track and audit information at the packet level. in order to expand their customer base they would like to offer their solutions to customer that have business systems built on Oracle Forms 6.x and Pro*C. to do this they need to understand how our network communication works. is this something that is generally available? here are some details for what the partner wants from us ...
Their product intercepts the communication between a typical Db client and Db server at packet level, performs analysis on the packets and extracts the information required for SOX compliance. It's been successfully installed and working for various versions of Oracle servers and Clients, however it does not handle Oracle Forms and pro*C clients.
It also wrks for pro*c client except for bind variables and arrays.
We need information on packet formats during communication between Oracle database and Forms and pro*c clients. This will help our product to work for SOX compliance for the customers who have FORMS and pro*c clients without replacing them
I know that form Forms to DB its SQL*Net, not sure what the protocol is for PRO*C to DB communication but do we have documentation on both?

Assuming you are on Windows, you can download the client installable from
http://download.oracle.com/otn/nt/oracle10g/10201/10201_client_win32.zip -- for Oracle 10g client
http://download.oracle.com/otn/nt/oracle11g/win32_11gR1_client.zip -- for Oracle 11g client
If you are looking for any other version, please mention the same.

Verizon FIOS Intermittent Packet Loss Problem - How to Convince Verizon Support it's NOT ME

Hi,
I have been having a problem with Verizon FIOS Internet AND Phone since Thursday afternoon.
Basically I have intermittent outages several times a day of 15-40 seconds where my download doesn't work, but upload still does. This happens on BOTH my phone and internet. Therefore it's not my router or computer equipment causing the problem.
Here's what happens:
- On the internet: I have a periodic download problem where I can receive no data for about 15 - 40 seconds. After that it returns to normal
- On the phone: If I'm on the phone at the same time then during that period of internet loss I also can not hear anything that the person I am talking to says. However they can hear me just fine (ie. download only problem)
I have been talking to Verizon technical support and they have blamed my router and ONT. I have tried switching off the router, and using a different one. Also they have replaced the ONT twice.
* This problem occurs on BOTH the phone and internet at the same time. This clearly suggests the problem is not in my own house.
In fact I know exactly where the problem lies. I did a traceroute to google below:
Tracing route to google.com [74.125.113.106]
over a maximum of 30 hops:
1     4 ms     1 ms    <1 ms 192.168.1.1
2     5 ms     4 ms     4 ms L300.NWRKNJ-VFTTP-122.verizon-gni.net [74.105.157.1]
3     9 ms     8 ms     7 ms G2-0-0-1822.NWRKNJ-LCR-08.verizon-gni.net [130.81.133.156]
4    11 ms     8 ms     7 ms P15-0.NWRKNJ-LCR-07.verizon-gni.net [130.81.30.148]
5     9 ms     6 ms     7 ms so-5-0-0-0.NWRK-BB-RTR1.verizon-gni.net [130.81.29.8]
6     7 ms     6 ms     7 ms 0.so-7-0-0.XL3.EWR6.ALTER.NET [152.63.19.177]
7     9 ms    10 ms     9 ms 0.so-1-0-1.XL3.NYC4.ALTER.NET [152.63.0.213]
8     9 ms     9 ms     9 ms TenGigE0-6-0-0.GW8.NYC4.ALTER.NET [152.63.22.41]
9    33 ms    31 ms    35 ms google-gw.customer.alter.net [152.179.72.62]
10     8 ms    11 ms    10 ms 209.85.252.215
11    18 ms    17 ms    16 ms 209.85.249.11
12    31 ms    29 ms    29 ms 209.85.241.222
13    30 ms    29 ms    29 ms 209.85.241.207
14    41 ms    39 ms    34 ms 209.85.243.1
15    27 ms    27 ms    29 ms vw-in-f106.1e100.net [74.125.113.106]
Trace complete.
Then I pinged each device for hops 2-4. When the problem occurs the first one in the hop - 74.105.157.1 - runs fine. The second device - 130.81.133.156 - times out, and all other devices further down the chain time out. This clearly suggest that the device:
130.81.133.156 has major problems.
I have mentioned this to tech support, but they have no way for me to send them logs. Apparently the support technicians at Verizon can not be trusted with even the most basic of tools like email and the web. They also shield me from the NT (Network technician), who is so special that even the tech support guys are only allowed to text chat with him, not actually talk to him. I have enough logs here to clearly show what the problem is.
The latest from tech support is that they are sending yet another guy by my house tomorrow to witness this problem firsthand. Then he will call support that will text chat with the NT, and MAYBE they'll start thinking it's not me.
My main question here is: "How do I get Verizon to believe it really could be a problem in their own network?"
Here are some threads from last year that explain exactly the same problem I'm having. So it wasn't just me:
http://forums.verizon.com/t5/FiOS-TV-Technical-Assistance/Verizon-FIOS-intermittent-connection-drops...
http://forums.verizon.com/t5/FiOS-Internet/Intermittent-Network-Timeouts/m-p/28138
One person said Verizon finally fixed it by replacing a PON card. I'm not sure if this is the same problem as that though.
I am an avid Starcraft player and this is driving me crazy because I am getting dropped from my games all the time. Also phone conversations suck when there's these big lags where I can't hear who I'm talking to.
I have had Verizon FIOS internet for 3 years now and this is the first problem I've ever had with it. But I'm starting to get majorly frustrated at how long it's taking to resolve the problem.
Here is a sample of the ping logs I was talking about for different devices all at the same time.
Device 2 in the Trace Route:
Reply from 74.105.157.1: bytes=32 time=78ms TTL=126
Reply from 74.105.157.1: bytes=32 time=57ms TTL=126
Reply from 74.105.157.1: bytes=32 time=41ms TTL=126
Reply from 74.105.157.1: bytes=32 time=35ms TTL=126
Reply from 74.105.157.1: bytes=32 time=34ms TTL=126
Reply from 74.105.157.1: bytes=32 time=41ms TTL=126
Reply from 74.105.157.1: bytes=32 time=43ms TTL=126
Reply from 74.105.157.1: bytes=32 time=59ms TTL=126
Reply from 74.105.157.1: bytes=32 time=24ms TTL=126
Reply from 74.105.157.1: bytes=32 time=48ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=4ms TTL=126
Reply from 74.105.157.1: bytes=32 time=3ms TTL=126
Reply from 74.105.157.1: bytes=32 time=20ms TTL=126
Reply from 74.105.157.1: bytes=32 time=19ms TTL=126
Reply from 74.105.157.1: bytes=32 time=18ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=37ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=16ms TTL=126
Device 3 in the Trace Route:
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=10ms TTL=253
Reply from 130.81.133.156: bytes=32 time=9ms TTL=253
Reply from 130.81.133.156: bytes=32 time=10ms TTL=253
Reply from 130.81.133.156: bytes=32 time=13ms TTL=253
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=6ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=14ms TTL=253
Device 4 in the Trace Route:
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Any help, thoughts, suggestions, etc would be great appreciated!
~David

I understand your logic, but you have not eliminated 74.105.157.1 as the problem. It could be allowing packets out, like outside callers hearing you, but not allow them back in. Since you have results pinging out, trying ping back in. Use this packet loss tool. You do not need to catch it when it's not working because this tool will ping your IP address (and all the hops in between) for up to 7 days. You will easily see when packet loss is occurring.
If it can successfully ping 74.105.157.1 when the problem occurrs, then 130.81.133.156 is not the issue. This may not help dealing with the personalities at Verizon, but it will help definitively knowing which device is the issue.

A connection was abortively closed after one of the peers sent an rst packet

Hello,
i have a dvr on netwoek that is wok fine. i tried to publish it over internet.
i have tmg with two wan connections(load Balancing) and two internal networks.
i create a server application rule and and but dvr protcols on it.
when i try to open it from outside it's not working. on tmg log it's give me this error:
A connection was closed because no SYN/ACK reply was received from the server.
also with others dvr i get this error:
a connection was abortively closed after one of the peers sent an rst packet
i tired to read all post on forums but i didn't get a solution for it.
please not that the network rule from internal to external is route and the publish rule is set to make the request is from local host.
so whats the problem?
thanks.

Hi,
Thank you for your post here.
As far as i know, if you would like to publish server located in internal, you need to set the relationship between internal and external as NAT.
Best Regards
Quan Gu

What is the use of Data packet dim with Virtual cube with services

Hi Friends,
Could anybody tell me what is the use of Packet dimension in Virtual cube with services , It cannot contain data persistently ,Just fetch at runtime,Then there is no Physical load happening,Then why it should be automatically created for this??
Message was edited by: Pradeep choudhari

Hi Maik,
Unit dimension will not be created automatically until and unless you have keyfigure referning units..
But my question is : Why should we have data pack dimension , which is useless in this case of Virtual cube with services.It should not be created automatically!! What do you say??

Packets in XI

Similar Messages

Maybe you are looking for