|
Ticket ID: SIXXS #8825718 Ticket Status: User PoP: ruled01 - EDPnet N.V. (St.Petersburg)
proto41 does not work with IP 80.240.252.50 (T97502)
![[ru]](/s/countries/ru.gif) Shadow Hawkins on Friday, 15 February 2013 10:24:18
server - 77.109.111.178
customer - 80.240.252.50
ICMP between server and customer: SUCCESS
Sniffer does not show any traffic with proto 41 received from 77.109.111.178
when trying ping 2a02:578:5002:44::1
but at page of tunnel traffic statistic packets count grow up
Packet In2013-02-15 10:17:02 (1360923422; 0 days 00:00:01 ago)
Packets In66 (up)
Packet Out2013-02-15 10:17:02 (1360923422; 0 days 00:00:01 ago)
Packets Out99 (up)
Was made test with another ISP
and same tunnel 6to4 between hosts 80.240.252.50 - 86.62.100.132 working fine.
I thisnk that problem nere 77.109.111.178 or in path of ISPs between server and customer.
State change: user
The state of this ticket has been changed to user
proto41 does not work with IP 80.240.252.50 (T97502)
server - 77.109.111.178
You mean the PoP.
customer - 80.240.252.50
You mean your endpoint.
ICMP between server and customer: SUCCESS
What kind of "ICMP"?
Sniffer does not show any traffic with proto 41 received from 77.109.111.178
Which could be anything on the path dropping those packets. How does your network look like? Can you provide a traceroute too? Did you check if any ICMP packets are being delivered or other intermediate hosts responding?
What is the setup of your endpoint? Please read the big yellow box while posting and provide the details requested.
when trying ping 2a02:578:5002:44::1
Where is the tcpdump?
but at page of tunnel traffic statistic packets count grow up
Then the PoP at least receives them, and according to that is also sending them out.
I thisnk that problem nere 77.109.111.178 or in path of ISPs between server and customer.
If that path filters then you will have a problem. Is there maybe a firewall on your host?
According to the "Live Tunnel Status" the tunnel used to work and you send a packet towards your own tunnel endpoint over the tunnel to the PoP about 2 hours ago. What changes have you been making?
proto41 does not work with IP 80.240.252.50 (T97502)
Shadow Hawkins on Friday, 15 February 2013 13:40:33What kind of "ICMP"?
ipv4 icmp echo request\reply
endpoint - Mikrotik router wich connected to Internet by PPPoE (interface "Kursknet")
No any changes was made at last 3-5 days.
sniffer running at Mikrotik (at all interfaces)
/tool sniffer> print
interface: all
only-headers: no
memory-limit: 100KiB
memory-scroll: yes
file-name:
file-limit: 1000KiB
streaming-enabled: no
streaming-server: 0.0.0.0
filter-stream: yes
filter-mac-address:
filter-mac-protocol:
filter-ip-address: 77.109.111.178/32
filter-ip-protocol:
filter-port:
filter-direction: any
running: no
here is sample of traffic when i ping both addresses of PoP (v4 and v6(p2p))
0 time=0.005 num=1 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=41 size=76
ip-packet-size=76 ip-header-size=20 dscp=0 identification=0
fragment-offset=0 ttl=64
1 time=0.026 num=2 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=0 identification=12639
fragment-offset=0 ttl=255
2 time=0.103 num=3 direction=rx interface=kursknet src-address=77.109.111.178
dst-address=80.240.252.50 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=26 identification=25848
fragment-offset=0 ttl=57
3 time=1.077 num=4 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=0 identification=12640
fragment-offset=0 ttl=255
4 time=1.154 num=5 direction=rx interface=kursknet src-address=77.109.111.178
dst-address=80.240.252.50 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=26 identification=25849
fragment-offset=0 ttl=57
5 time=1.162 num=6 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=41 size=76
ip-packet-size=76 ip-header-size=20 dscp=0 identification=0
fragment-offset=0 ttl=64
6 time=2.1 num=7 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=0 identification=12641
fragment-offset=0 ttl=255
7 time=2.177 num=8 direction=rx interface=kursknet src-address=77.109.111.178
dst-address=80.240.252.50 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=26 identification=25850
fragment-offset=0 ttl=57
8 time=2.457 num=9 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=41 size=76
ip-packet-size=76 ip-header-size=20 dscp=0 identification=0
fragment-offset=0 ttl=64
9 time=3.098 num=10 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=0 identification=12642
fragment-offset=0 ttl=255
10 time=3.177 num=11 direction=rx interface=kursknet src-address=77.109.111.17>
dst-address=80.240.252.50 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=26 identification=25851
fragment-offset=0 ttl=57
11 time=3.463 num=12 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=41 size=76
ip-packet-size=76 ip-header-size=20 dscp=0 identification=0
fragment-offset=0 ttl=64
12 time=4.104 num=13 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=0 identification=12643
fragment-offset=0 ttl=255
13 time=4.291 num=14 direction=rx interface=kursknet src-address=77.109.111.17>
dst-address=80.240.252.50 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=26 identification=25852
fragment-offset=0 ttl=57
14 time=4.467 num=15 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=41 size=76
ip-packet-size=76 ip-header-size=20 dscp=0 identification=0
fragment-offset=0 ttl=64
15 time=5.098 num=16 direction=tx interface=kursknet src-address=80.240.252.50
dst-address=77.109.111.178 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=0 identification=12644
fragment-offset=0 ttl=255
16 time=5.176 num=17 direction=rx interface=kursknet src-address=77.109.111.17>
dst-address=80.240.252.50 protocol=ip ip-protocol=icmp size=56
ip-packet-size=56 ip-header-size=20 dscp=26 identification=25853
fragment-offset=0 ttl=57
And traceroute
/tool> traceroute 77.109.111.178
# ADDRESS RT1 RT2 RT3 STATUS
1 80.240.241.5 55ms 53ms 53ms
2 80.240.241.157 60ms 61ms 61ms
3 80.240.241.245 54ms 61ms 58ms
4 77.51.253.173 60ms 61ms 60ms
5 77.51.252.246 66ms 150ms 66ms
6 193.232.244.16 67ms 65ms 65ms
7 212.71.11.197 78ms 79ms 80ms
8 77.109.111.178 77ms 114ms 77ms
and configuration of 6to4 interface:
/interface 6to4> print detail
Flags: X - disabled, R - running
0 R name="IPv6_sixxs.net" mtu=1480 local-address=80.240.252.50 remote-address=77.109.111.178
No firewall rules for this traffic
According to the "Live Tunnel Status" the tunnel used to work and you send a packet towards your own tunnel endpoint over the tunnel to the PoP about 2 hours ago. What changes have you been making?
today the sixxs's system e-mail me alarm and i try analyse situation.
From this time i just "pinging" ipv6 address of PoP interface. No answers. This traffic you can see at "Live Tunnel Status", but i not receive packets from PoP.
proto41 does not work with IP 80.240.252.50 (T97502)
filter-ip-address: 77.109.111.178/32
As clearly stated in the "Reporting Problems" list do not restrict what you are looking for. Please note that intermediate nodes might send helpful ICMP messages which might clarify the problem at hand.
here is sample of traffic when i ping both addresses of PoP (v4 and v6(p2p))
It is not very useful as there is no icmp type/code and thus little can be said what is happening there.
and configuration of 6to4 interface:
Please note that SixXS does not provide 6to4, thus hopefully this is just misnamed and actually just means 6in4
/interface 6to4> print detail Flags: X - disabled, R - running 0 R name="IPv6_sixxs.net" mtu=1480 local-address=80.240.252.50 remote-address=77.109.111.178
An MTU of 1480? You might want to either adjust this on your side or in the webinterface. Per default SixXS tunnels are at 1280. Do make sure that your path is 1480 clean which it likely is not as you are using PPPoE thus typically you have overhead there already.
Note that you have not provided any other configuration details at all, especially routing and addresses would be good to see.
No firewall rules for this traffic
Thus you mean that there are firewall rules, just that you do not think they might affect it.
Please check your rules...
From this time i just "pinging" ipv6 address of PoP interface.
You sent a packet over the tunnel that had the destination address of YOUR tunnel endpoint.
That should never happen, and the only way it could possibly happen is if your local endpoint is misconfigured.
proto41 does not work with IP 80.240.252.50 (T97502)
Shadow Hawkins on Friday, 15 February 2013 14:50:24As clearly stated in the "Reporting Problems" list do not restrict what you are looking for. Please note that intermediate nodes might send helpful ICMP messages which might clarify the problem at hand
Do you mean what traffic can't be delivered and some router in the middle send ICMP packet with error code?
If "yes" then this packet will be sent to source address = to PoP address
and i can't sniff it.
It is not very useful as there is no icmp type/code and thus little can be said what is happening there
Here all clear:
native ICMP between 80.240.252.50 and 77.109.111.178 (PoP) correctly delivered and i got answer (normal answer with pattern).
All packets with proto=41 is are my echo request's to 2a02:578:5002:44::1
But i check Your theory and listen all ICMP traffic when i ping remote address of ipv6 tunnel and i not see anything interesting, only packets like "i am bot, are you here? Yes, i am here."
An MTU of 1480? You might want to either adjust this on your side or in the webinterface. Per default SixXS tunnels are at 1280. Do make sure that your path is 1480 clean which it likely is not as you are using PPPoE thus typically you have overhead there already.
Yes, thanks, it's fixed now to 1280
Note that you have not provided any other configuration details at all, especially routing and addresses would be good to see.
I specially do not provide routing table cuz i ping p2p interface at "connected" network, but if You want it, of course i give this information.
/ipv6> route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
# DST-ADDRESS GATEWAY DISTANCE
0 A S 2000::/3 2a02:578:5002:44::1 1
1 ADC 2a02:578:5002:44::/64 IPv6_sixxs.net 0
2 ADC 2a02:578:5002:8044::/64 br0-local 0
/ipv6> address print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
# ADDRESS FROM-... INTERFACE ADV
0 G 2a02:578:5002:44::2/64 IPv6_sixxs.net yes
1 G 2a02:578:5002:8044::1/64 br0-local yes
2 DL fe80::20c:42ff:fec3:7774/64 ether1 no
3 DL fe80::20c:42ff:fec3:7775/64 br0-local no
4 DL fe80::50f0:fc32/128 IPv6_sixxs.net no
Please check your rules...
/ip firewall filter
add action=reject chain=input disabled=no dst-port=21 in-interface=kursknet \
protocol=tcp reject-with=icmp-admin-prohibited
add action=reject chain=input disabled=no dst-port=21 in-interface=ether1 \
protocol=tcp reject-with=icmp-host-prohibited src-address=!10.0.0.0/8
add action=accept chain=input disabled=no dst-port=21-22 protocol=tcp \
src-address=10.0.0.0/8 tcp-flags=syn
add action=accept chain=forward disabled=no dst-port=3389 protocol=tcp \
src-address=10.0.0.0/8 tcp-flags=syn
add action=accept chain=forward disabled=no dst-port=3389 protocol=tcp \
src-address=89.20.0.0/16 tcp-flags=syn
add action=reject chain=input disabled=no dst-port=21-22 protocol=tcp \
reject-with=icmp-admin-prohibited src-address-list=ssh-flooders \
tcp-flags=syn
add action=reject chain=forward disabled=no dst-port=3389 protocol=tcp \
reject-with=icmp-admin-prohibited src-address-list=rdp-flooders \
tcp-flags=syn
add action=accept chain=input disabled=no dst-limit=\
20/1h,10,src-and-dst-addresses/1d dst-port=21-22 protocol=tcp tcp-flags=\
syn
add action=accept chain=forward disabled=no dst-limit=\
30/1h,10,src-and-dst-addresses/1d dst-port=3389 protocol=tcp tcp-flags=\
syn
add action=add-src-to-address-list address-list=ssh-flooders \
address-list-timeout=1d chain=input disabled=no dst-port=21-22 limit=2,0 \
protocol=tcp tcp-flags=syn
add action=add-src-to-address-list address-list=rdp-flooders \
address-list-timeout=1d chain=forward disabled=no dst-port=3389 limit=\
10/1m,0 protocol=tcp tcp-flags=syn
add action=add-src-to-address-list address-list=ssh-flooders \
address-list-timeout=1d chain=input disabled=no dst-port=21-22 protocol=\
tcp tcp-flags=syn
add action=add-src-to-address-list address-list=rdp-flooders
address-list-timeout=1d chain=forward disabled=no dst-por
tcp tcp-flags=syn
Here no anything intresting...
ping 2a02:578:5002:87::1 src-address=2a02:578:5002:87::2 HOST SIZE TTL TIME STATUS
2a02:578:5002:87::1 56 64 13ms echo reply
2a02:578:5002:87::1 56 64 14ms echo reply
2a02:578:5002:87::1 56 64 14ms echo reply
sent=3 received=3 packet-loss=0% min-rtt=13ms avg-rtt=13ms max-rtt=14ms
You sent a packet over the tunnel that had the destination address of YOUR tunnel endpoint.
That should never happen, and the only way it could possibly happen is if your local endpoint is misconfigured.
Why not?
I have another tunnel when it's working correctly and i can use this ping of my neightbor for checking connectivity
> ping 2a02:578:5002:87::1 src-address=2a02:578:5002:87::2
HOST SIZE TTL TIME STATUS
2a02:578:5002:87::1 56 64 13ms echo reply
2a02:578:5002:87::1 56 64 14ms echo reply
2a02:578:5002:87::1 56 64 14ms echo reply
sent=3 received=3 packet-loss=0% min-rtt=13ms avg-rtt=13ms max-rtt=14ms
PoP have *::1 and endpoint have *::2 so why i can just ping :1 from :2? Uhh?
proto41 does not work with IP 80.240.252.50 (T97502)
Do you mean what traffic can't be delivered and some router in the middle send ICMP packet with error code? If "yes" then this packet will be sent to source address = to PoP address and i can't sniff it.
For packets that the PoP sends that is correct, but in that case the PoP will show this in the Live Tunnel Status overview (it shows ICMP errors received).
For packets that your endpoints send you will receive the ICMP reports.
It is not very useful as there is no icmp type/code and thus little can be said what is happening there Here all clear: native ICMP between 80.240.252.50 and 77.109.111.178 (PoP) correctly delivered and i got answer (normal answer with pattern).
What is 'native ICMP' ????
Please note that ICMP is a lot more than just 'ping'. It is used for signalling error conditions.
But i check Your theory and listen all ICMP traffic when i ping remote address of ipv6 tunnel and i not see anything interesting, only packets like "i am bot, are you here? Yes, i am here."
What do you mean with "I am bot... " ?
I specially do not provide routing table cuz i ping p2p interface at "connected" network
And the IPv4 routing table? And the interfaces and all the other information requested on the contact page?
Hence why there are big yellow/orange notes when posting... we do not ask it for nothing.
/ip firewall filter
Please start out with an EMPTY firewall ruleset, we are not your firewall debugging service.
ping 2a02:578:5002:87::1 src-address=2a02:578:5002:87::2 HOST SIZE TTL TIME STATUS 2a02:578:5002:87::1 56 64 13ms echo reply 2a02:578:5002:87::1 56 64 14ms echo reply 2a02:578:5002:87::1 56 64 14ms echo reply sent=3 received=3 packet-loss=0% min-rtt=13ms avg-rtt=13ms max-rtt=14ms
Does that mean that you currently can ping the remote end of the tunnel?
That should never happen, and the only way it could possibly happen is if your local endpoint is misconfigured. Why not?
Because you sent a packet *toward* your tunnel endpoint over the tunnel, that destination address should always end on your side of the tunnel.
I have another tunnel when it's working correctly and i can use this ping of my neightbor for checking connectivity
So, instead of providing the full details of your setup you now have multiple tunnels!?
As you are unable/willing to provide details of your complete setup, we cannot help.
Please, instead of wasting our time in this, use the forums to debug your setup.
proto41 does not work with IP 80.240.252.50 (T97502)
Shadow Hawkins on Monday, 18 February 2013 13:22:27Because you sent a packet *toward* your tunnel endpoint over the tunnel, that destination address should always end on your side of the tunnel.
Do You want to kill me?
I ping not my side!
PoP IPv62a02:578:5002:44::1
Your IPv62a02:578:5002:44::2
PoP (2a02:578:5002:44::1) <======> I am (2a02:578:5002:44::2)
I *CAN* send ICMP to 2a02:578:5002:44::1 from my address 2a02:578:5002:44::2 cuz it's correct and possible.
I do not understand about what You talking...
proto41 does not work with IP 80.240.252.50 (T97502)
Do You want to kill me?
Lets ignore such comments..
I ping not my side!
Something caused a packet destined to 2a02:578:5002:44::2 to be sent back up the tunnel, that is what:
Same In&Output Interface: 352, last: 2a02:578:5002:44::2 2013-02-15 09:50:54 (1360921854; 3 days 04:02:41 ago)
means in the live tunnel status. Note the date and time.
This can happen when there is a (default) route and the endpoint (read: your endpoint) did not terminate the address (that is, that it was not configured) and thus decided to route that packet back up the tunnel.
Why that happend, is unknown, but it did happen.
I *CAN* send ICMP to 2a02:578:5002:44::1 from my address 2a02:578:5002:44::2 cuz it's correct and possible.
Nobody is stating anything against it.
I do not understand about what You talking...
Try reading what is written... it helps.
proto41 does not work with IP 80.240.252.50 (T97502)
Shadow Hawkins on Monday, 18 February 2013 13:28:31
Jeroen, I collect enough information about problem:
1 (and basic). I show that i not receive 6in4 packets from PoP when i sniff traffic at interface, only ipv4 "native" (native - without tunnel) packets coming to me from PoP side.
What are You want to know else?
Why You cannot escalate ticket to ruled01 side?
proto41 does not work with IP 80.240.252.50 (T97502)
Why You cannot escalate ticket to ruled01 side?
What are we supposed to do about YOUR problem?
Obviously you are unsure about your configuration and you are unable to provide any details about it.
The Live Tunnel Status is showing that the PoP is sending packets to your endpoint.
We do not control the path between your host and the PoP.
Please note that all hops in between the PoP and your endpoint seem to not filter proto-41:
# hping3 -0 -t 1 -H 41 -T 80.240.252.50
HPING 80.240.252.50 (eth0 80.240.252.50): raw IP mode set, 20 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=77.109.111.177 name=77.109.111.177.static.edpnet.net
hop=2 TTL 0 during transit from ip=212.71.11.198 name=router01.mskm9.ru.edpnet.net
hop=3 TTL 0 during transit from ip=193.232.245.6 name=msk-ne40-1.ctc.ctcs.ru
hop=4 TTL 0 during transit from ip=77.51.254.235 name=UNKNOWN
hop=5 TTL 0 during transit from ip=77.51.253.63 name=BLG-CRS2-ORL-CRS1.ip.center.rt.ru
hop=6 TTL 0 during transit from ip=77.51.253.174 name=KRS-NE1-KRS-CRS2.ip.center.rt.ru
--- 80.240.252.50 hping statistic ---
16 packets transmitted, 6 packets received, 63% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
traceroute to 80.240.252.50 (80.240.252.50), 30 hops max, 60 byte packets
1 77.109.111.177.static.edpnet.net (77.109.111.177) 0.388 ms 0.427 ms 0.482 ms
2 router01.mskm9.ru.edpnet.net (212.71.11.198) 12.749 ms 12.799 ms 12.836 ms
3 msk-ne40-1.ctc.ctcs.ru (193.232.245.6) 13.626 ms 13.613 ms 13.616 ms
4 77.51.254.235 (77.51.254.235) 19.211 ms 19.211 ms 19.201 ms
5 BLG-CRS2-ORL-CRS1.ip.center.rt.ru (77.51.253.63) 32.013 ms 31.998 ms 31.992 ms
6 KRS-NE1-KRS-CRS2.ip.center.rt.ru (77.51.253.174) 25.067 ms 24.745 ms 26.752 ms
7 pvt2-226.kursknet.ru (80.240.241.226) 24.451 ms 24.444 ms 24.415 ms
8 MSN-poll-net252-50.kursknet.ru (80.240.252.50) 80.875 ms 82.358 ms 78.402 ms
Indeed that is one hop in front of your node that is not responding.
As you claimed that you did not change anything, but you obviously had to make changes like the MTU change, and that it worked before, there is nothing to be done.
Things that you can do:
- verify the configuration of your endpoint by providing full details and asking people on the forum to help you configure it properly
- disable router advertisements on your link (tunnels are static, next to that the other side will not accept it)
- change the tunnel type to AYIYA to avoid any protocol-41 filtering that might be happening at your ISP.
proto41 does not work with IP 80.240.252.50 (T97502)
Shadow Hawkins on Monday, 18 February 2013 15:45:35
Very helpfull information.
Please make also traceroute to 80.240.250.128 this host also at same ISP but working via tunnelbroker.net
And if You accept, wi can create else one tunnel to 80.240.250.128 and check connectivity from this host
proto41 does not work with IP 80.240.252.50 (T97502)
Please make also traceroute to 80.240.250.128 this host also at same ISP but working via tunnelbroker.net
# hping3 -0 -t 1 -H 41 -T 80.240.250.128
HPING 80.240.250.128 (eth0 80.240.250.128): raw IP mode set, 20 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=77.109.111.177 name=77.109.111.177.static.edpnet.net
hop=2 TTL 0 during transit from ip=212.71.11.198 name=router01.mskm9.ru.edpnet.net
hop=3 TTL 0 during transit from ip=193.232.245.6 name=msk-ne40-1.ctc.ctcs.ru
hop=4 TTL 0 during transit from ip=77.51.254.235 name=UNKNOWN
hop=5 TTL 0 during transit from ip=77.51.253.213 name=KRS-CRS1-BLG-CRS2.ip.center.rt.ru
hop=6 TTL 0 during transit from ip=77.51.253.222 name=KRS-NE40-2-KRS-CRS1.ip.center.rt.ru
^C
--- 80.240.250.128 hping statistic ---
29 packets transmitted, 6 packets received, 80% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
traceroute to 80.240.250.128 (80.240.250.128), 30 hops max, 60 byte packets
1 77.109.111.177.static.edpnet.net (77.109.111.177) 0.307 ms 0.363 ms 0.415 ms
2 router01.mskm9.ru.edpnet.net (212.71.11.198) 12.715 ms 12.756 ms 12.819 ms
3 msk-ne40-1.ctc.ctcs.ru (193.232.245.6) 13.923 ms 14.728 ms 14.726 ms
4 77.51.254.235 (77.51.254.235) 20.102 ms 20.098 ms 20.086 ms
5 KRS-CRS1-BLG-CRS2.ip.center.rt.ru (77.51.253.213) 32.161 ms 32.148 ms 32.146 ms
6 KRS-NE40-2-KRS-CRS1.ip.center.rt.ru (77.51.253.222) 31.230 ms 45.891 ms 30.039 ms
7 pvt2-158.kursknet.ru (80.240.241.158) 27.236 ms 26.498 ms 27.430 ms
8 MSN-poll-net250-128.kursknet.ru (80.240.250.128) 359.355 ms 354.866 ms 355.844 ms
Something is filtering something there. Note though that existence or non-existence of ICMP responses do not tell everything, it is just an indicator.
And if You accept, wi can create else one tunnel to 80.240.250.128 and check connectivity from this host
You can request tunnels from the webinterface.
|
![[ch]](/s/countries/ch.gif)
on Friday, 15 February 2013 12:19:08
Posting is only allowed when you are