4 ms·

Hi aexaey, There are some things wrong on your comment, please let me comment on them: I don't think A0 are capped at all, I don't know where did you get that

Hi aexaey, There are some things wrong on your comment, please let me comment on them: I don't think A0 are capped at all, I don't know where did you get that: user@A0VM:~$ speedtest-cli Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Microsoft Corporation (40.113.XX.XX)... Selecting best server based on latency... Hosted by KsFiberNet (Wichita, KS) [45.26 km]: 139.703 ms Testing download speed........................................ Download: 44.48 Mbit/s Testing upload speed.................................................. Upload: 22.54 Mbit/s I just had to run one single test to get these results. Multi-threading will probably pump this up (let's say a multi-thread iPerf test between two VMs on two different regions, through their public IP addresses). (Funnily enough this VM is in Dublin, hence the latency to Wichita). You can get access to all your TCP/UDP ports by adding an instance-level IP: https://azure.microsoft.com/en-gb/documentation/articles/virtual-networks-instance-level-public-ip/ https://azure.microsoft.com/en-gb/documentation/articles/vir... (you can later protect it with NSGs --> https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-nsg/ https://azure.microsoft.com/en-us/documentation/articles/vir... ). What you've seen is when you create endpoints on the load balancer that points to the VMs behind it. Now in Azure Resource Manager, spinning up a VM from the new portal will actually get you an ILPIP and no load balancer by default. About that statement about a ton of weirdly configured network gear: Well, for starters you're doing network virtualization here :) but seriously now, the platform doesn't forward ICMPs to/from Internet, so I'm curious about those private IP addresses on a traceroute (and of course the packet drops). If you're talking about hops between you and the VIP (the load balanced public IP in front of your VM), that's probably your provider, other providers and finally Microsoft's Network. As per the rest of the path, you've said that ICMP doesn't go through, so traceroute it's not going to work (tcptraceroute also needs ICMP to work :)).

aexaey 11y ago
ILPIP look promising. I'll try it, thanks! Speed test though... hm... 22Mbit/s is not exactly unrestricted, plus not sure how long is the burst that "speedtest-cli" makes. In my experience A0's uplink is burstable (but unusably slow when recovering from a burst), with long-term average being bang-on 5Mbps. I do of course see exactly one "my" private IP in traceroute, but I'm not talking about that. I meant there are microsoft's private IPs (#12-#15) and dropped packets (#16 and on). And of course, "platform doesn't forward ICMPs" is an annoyance in itself - i can't even ping my own VM. # target IP anonymized, but still have enough granularity to reproduce the traceroute traceroute to xxxxx.cloudapp.net (191.235.128.128), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 0.093 ms 0.117 ms 0.063 ms 2 193.47.232.12 (193.47.232.12) 0.785 ms 0.785 ms 0.776 ms 3 microsoft.mix-it.net (217.29.66.112) 1.219 ms 1.233 ms 1.225 ms 4 xe-0-1-1-0.fra-96cbe-1a.ntwk.msn.net (207.46.42.12) 8.700 ms 8.902 ms 8.430 ms 5 * * * 6 * * * 7 104.44.9.142 (104.44.9.142) 42.112 ms 39.194 ms 38.987 ms 8 * * * 9 be-6-0.ibr01.dub30.network.microsoft.com (104.44.4.142) 39.738 ms 38.266 ms 38.929 ms 10 * * * 11 ae2-0.db3-96c-3b.ntwk.msn.net (204.152.141.81) 36.986 ms 36.984 ms 36.925 ms 12 25.149.64.247 (25.149.64.247) 36.951 ms 36.775 ms 37.152 ms 13 10.10.132.81 (10.10.132.81) 36.917 ms 37.477 ms 37.287 ms 14 10.60.31.77 (10.60.31.77) 37.317 ms 37.699 ms 37.899 ms 15 10.60.31.69 (10.60.31.69) 37.653 ms 37.326 ms 37.441 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * P.S. #12 - lol!
- mobiplayer 11y ago
  Yeah, the ICMP stuff could be a bit annoying :) My comment about the traceroute was because you previously said that you've found those weird IP addresses between the VM and Internet. That's not how I actually see it, but I get your point, too. The ones you identify as packet loss are just the ones you didn't get an ICMP back. I don't know anything about your background, but as per my experience with networking I've stopped considering traceroute as something remotely useful further than the first hop long ago, especially on environments outside my control (i.e. Internet). There are things out there like ICMP throttling and the fact that I could send you the "TTL Expired" ICMP identifying myself with any IP address. Remember the "Star Wars traceroute"? http://www.theregister.co.uk/2013/02/15/star_wars_traceroute/ http://www.theregister.co.uk/2013/02/15/star_wars_traceroute... (doesn't seem to work for me now). (About #12, WTF? Weird!)
  - aexaey 11y ago
    Actually, in public Internet traceroutes are reasonably reliable. It's corporate networks where you would expect weird stuff like that. > (About #12, WTF? Weird!) There is a fairly boring explanation to that. Similar to public IPv4 exhaustion, RFC1918-style private IPv4 addresses can easily be exhausted in a big private network as well. If you have noticed, MS has actually run out of RFC1918, and uses RFC6598 (a.k.a. 100.64.0.0/10) network in Azure for their "classic" segment. 100.64.0.0/10 was not supposed to be used as RFC1918-style general-purpose private IP space, but rather as a local side of a CGN pool. But then again, if you squint a bit, well... it's still private, so will never be advertised into the Internet, so it's fair game to use it if you run out of RFC1918, right? Some people choose to squint even further, and declare anything that is not advertised into public BGP as a fair game. I've seen a big ISP "borrowing" 44.0.0.0/8 (amateur radio AX.25) subnet to deploy video segment of their huge "triple-play" network. 33/8 (US DoD) is also popular as "borrowed" private space, 1/8 was fairly popular until it actually became real public address space handed to APNIC (oops!). Now we have an example of using 25/8 like that as well.
    - X-Istence 11y ago
      This is why it is unfortunate that more companies are not using IPv6 or moving towards it. Currently working at a large MSP, and all of our stuff is still IPv4 only. Although we happen to have a ton of extra IPv4 space, so we aren't as concerned, but there is no movement towards IPv6 at all.

aexaey 11y ago

ILPIP look promising. I'll try it, thanks! Speed test though... hm... 22Mbit/s is not exactly unrestricted, plus not sure how long is the burst that "speedtest-cli" makes. In my experience A0's uplink is burstable (but unusably slow when recovering from a burst), with long-term average being bang-on 5Mbps. I do of course see exactly one "my" private IP in traceroute, but I'm not talking about that. I meant there are microsoft's private IPs (#12-#15) and dropped packets (#16 and on). And of course, "platform doesn't forward ICMPs" is an annoyance in itself - i can't even ping my own VM. # target IP anonymized, but still have enough granularity to reproduce the traceroute traceroute to xxxxx.cloudapp.net (191.235.128.128), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 0.093 ms 0.117 ms 0.063 ms 2 193.47.232.12 (193.47.232.12) 0.785 ms 0.785 ms 0.776 ms 3 microsoft.mix-it.net (217.29.66.112) 1.219 ms 1.233 ms 1.225 ms 4 xe-0-1-1-0.fra-96cbe-1a.ntwk.msn.net (207.46.42.12) 8.700 ms 8.902 ms 8.430 ms 5 * * * 6 * * * 7 104.44.9.142 (104.44.9.142) 42.112 ms 39.194 ms 38.987 ms 8 * * * 9 be-6-0.ibr01.dub30.network.microsoft.com (104.44.4.142) 39.738 ms 38.266 ms 38.929 ms 10 * * * 11 ae2-0.db3-96c-3b.ntwk.msn.net (204.152.141.81) 36.986 ms 36.984 ms 36.925 ms 12 25.149.64.247 (25.149.64.247) 36.951 ms 36.775 ms 37.152 ms 13 10.10.132.81 (10.10.132.81) 36.917 ms 37.477 ms 37.287 ms 14 10.60.31.77 (10.60.31.77) 37.317 ms 37.699 ms 37.899 ms 15 10.60.31.69 (10.60.31.69) 37.653 ms 37.326 ms 37.441 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * P.S. #12 - lol!

mobiplayer 11y ago
Yeah, the ICMP stuff could be a bit annoying :) My comment about the traceroute was because you previously said that you've found those weird IP addresses between the VM and Internet. That's not how I actually see it, but I get your point, too. The ones you identify as packet loss are just the ones you didn't get an ICMP back. I don't know anything about your background, but as per my experience with networking I've stopped considering traceroute as something remotely useful further than the first hop long ago, especially on environments outside my control (i.e. Internet). There are things out there like ICMP throttling and the fact that I could send you the "TTL Expired" ICMP identifying myself with any IP address. Remember the "Star Wars traceroute"? http://www.theregister.co.uk/2013/02/15/star_wars_traceroute/ http://www.theregister.co.uk/2013/02/15/star_wars_traceroute... (doesn't seem to work for me now). (About #12, WTF? Weird!)
- aexaey 11y ago
  Actually, in public Internet traceroutes are reasonably reliable. It's corporate networks where you would expect weird stuff like that. > (About #12, WTF? Weird!) There is a fairly boring explanation to that. Similar to public IPv4 exhaustion, RFC1918-style private IPv4 addresses can easily be exhausted in a big private network as well. If you have noticed, MS has actually run out of RFC1918, and uses RFC6598 (a.k.a. 100.64.0.0/10) network in Azure for their "classic" segment. 100.64.0.0/10 was not supposed to be used as RFC1918-style general-purpose private IP space, but rather as a local side of a CGN pool. But then again, if you squint a bit, well... it's still private, so will never be advertised into the Internet, so it's fair game to use it if you run out of RFC1918, right? Some people choose to squint even further, and declare anything that is not advertised into public BGP as a fair game. I've seen a big ISP "borrowing" 44.0.0.0/8 (amateur radio AX.25) subnet to deploy video segment of their huge "triple-play" network. 33/8 (US DoD) is also popular as "borrowed" private space, 1/8 was fairly popular until it actually became real public address space handed to APNIC (oops!). Now we have an example of using 25/8 like that as well.
  - X-Istence 11y ago
    This is why it is unfortunate that more companies are not using IPv6 or moving towards it. Currently working at a large MSP, and all of our stuff is still IPv4 only. Although we happen to have a ton of extra IPv4 space, so we aren't as concerned, but there is no movement towards IPv6 at all.