ipv6 and path mtu problems in anycast networks...ipv6 requires that every link in the internet have...
Post on 08-Sep-2020
3 Views
Preview:
TRANSCRIPT
Hossein Lo)i Director of Performance Engineering EdgeCast Networks Inc.
IPv6 and Path MTU problems in AnyCast networks
About EdgeCast
• Performance Oriented Content Delivery Network with world-‐wide presence • HTTP Caching Pla)orm for StaGc Content • ApplicaGon Delivery Network for Dynamic Content (Lots of TCP OpGmizaGons) • Streaming • DNS Pla)orm
What performance team does at EdgeCast
Analyze Performance Trends and come up with ideas to make the CDN faster
TCP Op=miza=ons
TCP Op=miza=ons
Performance Op=miza=on of: • Network Stack • Rou=ng • Kernel • Applica=on
we work on the most complex cases. they usually mean find needle in a haystack
We will talk about: • In the first half of this presentaGon we will explain How we tested our network prior to IPv6 Launch
• Broken flows that we discovered and signs of a bigger problem with AnyCast flows
• Our troubleshooGng process • Possible soluGons
6/6/12
TesGng methodology: • SyntheGc monitoring • Real User monitoring • RIPE Atlas • Internal RUM • TCP_INFO
SyntheGc monitoring
!
• Servers in DataCenters • Strategically located • Very well peered and monitored
SyntheGc nodes that were available to us
11,180,768 Tests/mo
SyntheGc nodes are usually connected to main Internet Exchange Centers
One Synthe=c Failure is Too Many !Prior to world IPv6 launch date, none of SyntheGc nodes that we worked with had reliable v6 connecGvity
RUM (Real User Monitoring)
CDN1 CDN2 CDN3
ReporGng Server
How does RUM work
40 ms
More visibility using RUM
RUM helped us detect a problem causing Albania traffic to go to US
RUM data is too noisy. Look for trends and pa`erns, not individual data points
Main RUM pla)orms were not offering IPv6 prior to v6 day
RIPE Atlas
This talk is not about Atlas but Lets see how Atlas helped us to fine tune our network for IPv6 launch
Ability to run MulGple TestsAPI
HTTP tests are in Beta
IPv6 reachability analysis by Atlas
AS-‐path analysisAS-‐path of failed traces
We need more Atlas probes in US !
Current acGve probes in a major US mobile network
If you are thinking about launching a looking glass, consider hosGng an Atlas probe instead. It will help the community way be`er than tradiGonal looking glasses
and yes! one thing that atlas can not provide is BGP data
What did we learn from Atlas about our IPv6 Performance
and availability?
VisualizaGon of “which POP is handling traffic coming from a country?” and latency
Ukraine goes to POP1 and POP7. POP7 has much higher latency
We launched a beacon dedicated to IPv6 measurements that tested the following:
•IPv4 only •IPv6 only •Dual v4 and v6
In order to reduce the failures to a more acGonable set, the beacon also checked connecGvity to ipv6.google.com. We first focused on cases where AS numbers fail to reach us over v6 but can browse ipv6.google.com
Availability predicGons before launch
v4-‐Ok, v6: Fail, Dual:Okv4:Ok, v6: Fail, Dual:Failv4:Ok, v6: Ok, Dual: Failv4:Ok, v6: Ok, Dual: Okv4:Fail, v6: Fail, Dual: OK
Latency calculaGons prior to launch and their progress during our pre-‐launch performance opGmizaGons
IPv4 IPv6
In our h`p tesGng we noGced some clients can complete the trace to us, but fail to download h`p objects!!!
Here is what we saw in packet captures16:21:13.051353 IP6 2606:2800:234:1df9:13d:1d4e:6b0:10cf.443 > 2001:778:627f:cf1::55.42947: Flags [.], seq 1:1441, ack 101, win 225, length 1440 16:21:13.051367 IP6 2606:2800:234:1df9:13d:1d4e:6b0:10cf.443 > 2001:778:627f:cf1::55.42947: Flags [.], seq 1441:2881, ack 101, win 225, length 1440
16:21:13.051372 IP6 2606:2800:234:1df9:13d:1d4e:6b0:10cf.443 > 2001:778:627f:cf1::55.42947: Flags [P.], seq 2881:4097, ack 101, win 225, length 1216
16:21:13.051421 IP6 2606:2800:234:1df9:13d:1d4e:6b0:10cf.443 > 2001:778:627f:cf1::55.42947: Flags [.], seq 4097:5537, ack 101, win 225, length 1440
16:21:13.051427 IP6 2606:2800:234:1df9:13d:1d4e:6b0:10cf.443 > 2001:778:627f:cf1::55.42947: Flags [.], seq 5537:6977, ack 101, win 225, length 1440
16:21:13.051431 IP6 2606:2800:234:1df9:13d:1d4e:6b0:10cf.443 > 2001:778:627f:cf1::55.42947: Flags [P.], seq 6977:7603, ack 101, win 225, length 626
1500
1500
1276
1500
1500
686
✓
✓
Ack
Ack
HTTP Server
Client
This is a clear sign of a path MTU problem
h`p://www.networkworld.com/subnets/cisco/082307-‐ch7-‐ccna-‐icnd2.html
Lets try to explain what is happening here
But there is already a mechanism to prevent this from happening
h`p://www.networkworld.com/subnets/cisco/082307-‐ch7-‐ccna-‐icnd2.html
1500
ICMP : Packet Too Big
So Why the server did not adjust MSS based on “ICMP packet too big” message?
Did the server ever received the “ICMP packet too big” message?
No!
Server handling the
flow in
All other servers in
No!
How about all the servers in the world?
Found it in Paris!
✓
✘
✘✘✘✘
✘✘✘✘
✘✘✘✘
✘✘✘✘
✘✘✘✘
✘✘✘✘
✘✘✘✘
✘
✘✘
We searched our enGre pla)orm for that ICMP message
…and found the ICMP packet in Paris!
Why that packet was received in paris?
!!
Offending packet Source IP: AnyCast IP
DesGnaGon IP: Client IP
ICMP : Packet too big Source IP: Router-‐IP DesGnaGon IP: Client-‐IP
The answer is inside the “ICMP packet too big message”
Actual packet
ICMP Source IP: 2001:470:0:24f::2
Server IP: 2606:2800:234:124e:17ca:871:eb2:2067Client IP: 2002:5ee3:1e6b:0:705d:6734:7497:37e8
Since we had different peering arrangements with the AS number which was sending ICMP packets to us, the packets that were originated from that AS were going to a different pop
so we fixed the peering with offending router. What happened next?
No!
Server Handling the flow in Frankfurt
All other servers in Frankfurt
✘✘
✘
✘✘✘✘
✓
Now we receive the packet in the right pop, but by the wrong server
We have mulGple load balancing layers. One of them is based on Equal Cost MulG path (ECMP)
ECMP Load balancers do not check offending ICMP packets to make the forwarding decision
Load balancer
Server 1 Server 2 Server 3
Actual flow ICMP Messages
SoluGon?
The simples soluGon is in the RFC 2460:
5. Packet Size Issues!!IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.
This is happening in IPv4 as well, and if you have an Anycast
network, your availability could be impacted by this problem as
well!
The Bigger Problem:
EdgeCast took a different approach to make sure IPv4
ICMP messages are received by the right server. But since it is
only specific to our architecture, we will skip talking about it.
SuggesGons:• To measure the impact of this problem, we recommend monitoring orphaned ICMP messages in Anycast networks. • You can also setup last mile tests and compare availability of Anycast and Unicast services.
top related