I have a cisco 7204 router to which 2 Mikrotik connects with PPTP for VPN.
first Mikrotik has ROS 2.9.51, the second 3.23
ping from cisco to first with packet size over mtu/mru will be correct fragmented, but
ping from cisco to second gets 90-100% Packet loss.
Furthermor second one has lan gw MTU 1420 so i wanna set mru on Mikritk to 1380 but even if i set it to this value on status it says mru is 1400 (testet to be the lowes possible value)
cisco#ping vrf MYVLAN FIRST size 1600 timeout 1 repeat 5 validate
Type escape sequence to abort.
Sending 5, 1600-byte ICMP Echos to FIRST, timeout is 1 seconds:
Reply data will be validated
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
cisco#ping vrf MYVLAN SECOND size 1600 timeout 1 repeat 5 validate
Type escape sequence to abort.
Sending 5, 1600-byte ICMP Echos to SECOND timeout is 1 seconds:
Reply data will be validated
.....
Success rate is 0 percent (0/5)
i tested with another line with 3.20 and there it works. I think the problem is that uplink has mtu 1420 and mikrotik ros 3.23 semms to be unable to set MRU on pptp client lower than 1400 (1380 needed so packets a droped. )
any hint how to set MRU to 1380 ?
linux src iptraf log:
Thu Jun 25 16:48:02 2009; ******** IP traffic monitor started ********
Thu Jun 25 16:48:18 2009; ICMP; eth0; 1340 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; echo req
Thu Jun 25 16:48:18 2009; ICMP; eth0; 25 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; fragment
Thu Jun 25 16:48:19 2009; ICMP; eth0; 1340 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; echo req
Thu Jun 25 16:48:19 2009; ICMP; eth0; 25 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; fragment
Thu Jun 25 16:48:20 2009; ICMP; eth0; 1340 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; echo req
Thu Jun 25 16:48:20 2009; ICMP; eth0; 25 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; fragment
Thu Jun 25 16:48:21 2009; ICMP; eth0; 1340 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; echo req
Thu Jun 25 16:48:21 2009; ICMP; eth0; 25 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; fragment
Thu Jun 25 16:48:22 2009; ICMP; eth0; 1340 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; echo req
Thu Jun 25 16:48:22 2009; ICMP; eth0; 25 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; fragment
Thu Jun 25 16:48:23 2009; ICMP; eth0; 1340 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; echo req
Thu Jun 25 16:48:23 2009; ICMP; eth0; 25 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; fragment
Thu Jun 25 16:48:24 2009; ICMP; eth0; 1340 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; echo req
Thu Jun 25 16:48:24 2009; ICMP; eth0; 25 bytes; from IP-aus-VPN to PPTP-Einwahl-IP; fragment
Thu Jun 25 16:49:11 2009; ******** IP traffic monitor stopped ********
and tik log:
has anyone a idee why both GRE packet receives but only the smaller icmp framgent is shown?
The old Line is away, but now i have a new, similar problem on another Line:
I have a Cisco 7200 acting as PPTP Server
I have 2 different DSL lines, which have each a Mikrotik rb450 with ROS 4.5.
Both have an pptp-tunnel (client) to the cisco
On one line ping fragmentaion to ext ip and from vpn to int ip are working fine.
On the other line ping to ext ip is working but to vpn big pakets get lost.
I startet sniffer on the malfunc tik.
It looks like, that when a paket is too large, it will be fragemented (thats ok)
and most of the time, the smaller paket with “fragment number 2”
will be received before “paket with fragment 1” and Mikrotik cant handle this.
On the snif you can see, that both GRE pakets from the pptp tunnel are received, but in the tunnel
mikrotik only shows the 2nd fragment:
I have witenessed this as well on Lt2P tunnels.. since it’s UDP the packets arrive out of order and then encryption gets out of sync. I still would love to figure this one out. My theories are here:
1 - some other router along the way is reordering packets, maybe there is a ecmp route somewhere on the net. async routing.
2 - there is qos somewhere in the middle prioritizing and sending smaller packets first.
3 - IP fragmentation reassembly should just work even if this happens, I thought. As long as connection-tracking is turned on. Maybe someone can chime in on why this kernel can’t handle out of order packets like this.
SYMPTOMS
Microsoft Point-to-Point Tunneling Protocol (PPTP) discards all packets that are received out of sequence.
CAUSE
PPTP relies on the Internet Generic Routing Encapsulation (GRE) protocol. Microsoft is strictly following RFC 2890 “Key and Sequence Number Extensions to GRE” which states in section 2.2:
When the decapsulator receives an out-of sequence packet it SHOULD be silently discarded.
So it looks like no only Mikrotik has problems with such bogus dsl who transmits GRE Packets out of order
run this to your IP address and see how many different paths are near you - maybe you can find the spot within your ISP to ask them to help fix the problem?
The above tool takes a little while because it traceroutes to you from a lot of locations. It gives you a good idea of the topology of the path your packets take. My guess is that the packets are getting out of order because something upstream is doing ECMP or qos, or maybe your router is? Do you have ANY qos on your router?
im curious, could you get a pcap of some of those out of order packets as they are leaving your router, and check the sequence numbers to see if they are out of order already - or if it is happening on the net somewhere? Also, check the TTL on the received packets to see if they are different number of hops when they are received?
IP (icmp ping):
bad ping:
Frame 45 Total Length: 124 Time to live: 59 Fragment offset: 1376
Frame 48 Total Length: 388 Time to live: 59 Fragment offset: 1480
good ping:
Frame 54 Total Length: 1396 Time to live: 59 Fragment offset: 0
Frame 55 Total Length: 124 Time to live: 59 Fragment offset: 1376
Frame 57 Total Length: 388 Time to live: 59 Fragment offset: 1480
Sequence Number present (capital S), 1-bit
If set then the Sequence Number field is present and contains valid information.
Sequence Number, 32 bits
Contains a number which is inserted by the encapsulator. It may be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver.
pcap dump says bit=1 and the sequency number as shown.
so imho mikrotik should be able to rearrange the pakets correctly
Occasionally packets lose their sequencing across a complicated
internetwork. Say, for example that a PNS sends packets 0 to 5 to a
PAC. Because of rerouting in the internetwork, packet 4 arrives at
the PAC before packet 3. The PAC acknowledges packet 4, and may
assume packet 3 is lost. This acknowledgment grants window credit
beyond packet 4.
When the PAC does receive packet 3, it MUST not attempt to transmit
it to the corresponding PPP client. To do so could cause problems,
as proper PPP protocol operation is premised upon receiving packets
in sequence. PPP does properly deal with the loss of packets, but
not with reordering so out of sequence packets between the PNS and
PAC MUST be silently discarded, or they may be reordered by the
receiver. When packet 5 comes in, it is acknowledged by the PAC
since it has a higher sequence number than 4, which was the last
highest packet acknowledged by the PAC. Packets with duplicate
sequence numbers should never occur since the PAC and PNS never
retransmit GRE packets. A robust implementation will silently
discard duplicate GRE packets, should it receive any.
because this dsl sends 97% out of order (smaller packets receive earlier than bigger ones) I would like to know if it would be possible to implement “reordering by receiver” instead of “discarding”?
