Задачи с работы
Просто заметки. Не хочу тратить время на перевод, поэтому на английском :)
Phenomena
Ordinary tracert by packets with payload of 12 bytes are ok, while packets with payload of 1400 are lost:
At the same time ping and services are ok.
If we tracert directly connected device (in our case X.50) there is no losses as well:
Analysis
I checked this issue in different regions and reproduced it successfully in 100% cases. All CXs act this way. ATNs don’t have this problem.
It really looked like some protection mechanism. But protection from what? Here I started to think how tracert works.
As you probably knows Huawei equipment sends UDP packets along the path to destination with TTL increasing from 1 to 30 until reaching destination. Each hop decreases TTL by 1. If TTL=0, device will drop packet and send ICMP message TTL expired in Transit. For originator of tracert it indicates that next hop reached.
Let’s imagine if routing loop happens - Gigabits of traffic will rotate in this loop until TTL=0. Then all this Gigabits should be dropped and CPU generate ICMP message for each packets. We will meet ICMP storm and CPU died under heavy pressure.
To protect device and network from this issue TTL-expiration protection is implemented in the following way:
0. Device has a special queue for packets with TTL=0 with size, let’s say, 3000bps - actual value depends on version.
1. Packet with TTL=1 comes to Network Processor. It will decrease value to 0 by hardware (no influence to CPU) and then put this packet to that special queue.
2. If packets fits completely to that queue it will pass the check and message will be forwarded to CPU to make it to generate ICMP TTL Expired in transit.
3. If packet can’t be put to the queue, it will be dropped, no any message to CPU will be sent, no ICMP message will be generated.
So what do we have?
Ordinary tracert sends three UDP-packets with payload of 12 bytes. Totally 3*12=36 bytes. It is normally fits to 3000bps of the queue and all 3 packets will cause ICMP message sending to the source.
Then we run tracert with probe size of 1400 for example - totally 3*1400=2800+1400. First 1400 perfectly fit to 3000 bps, while last packet don’t - it will be dropped without any notification of tracert originator - so we get * in results.
We can see it by
And one more question exists: why tracert of directly connected device is always ok?
It is easy. Such UDP packet has IP of directly connected device as destination IP. Anyway it will be delivered to CPU without TTL check. So no * appears in spite of size of packets.
Solution
Why do you need the solution?
Phenomena
Ordinary tracert by packets with payload of 12 bytes are ok, while packets with payload of 1400 are lost:
At the same time ping and services are ok.
If we tracert directly connected device (in our case X.50) there is no losses as well:
Analysis
I checked this issue in different regions and reproduced it successfully in 100% cases. All CXs act this way. ATNs don’t have this problem.
It really looked like some protection mechanism. But protection from what? Here I started to think how tracert works.
As you probably knows Huawei equipment sends UDP packets along the path to destination with TTL increasing from 1 to 30 until reaching destination. Each hop decreases TTL by 1. If TTL=0, device will drop packet and send ICMP message TTL expired in Transit. For originator of tracert it indicates that next hop reached.
Let’s imagine if routing loop happens - Gigabits of traffic will rotate in this loop until TTL=0. Then all this Gigabits should be dropped and CPU generate ICMP message for each packets. We will meet ICMP storm and CPU died under heavy pressure.
To protect device and network from this issue TTL-expiration protection is implemented in the following way:
0. Device has a special queue for packets with TTL=0 with size, let’s say, 3000bps - actual value depends on version.
1. Packet with TTL=1 comes to Network Processor. It will decrease value to 0 by hardware (no influence to CPU) and then put this packet to that special queue.
2. If packets fits completely to that queue it will pass the check and message will be forwarded to CPU to make it to generate ICMP TTL Expired in transit.
3. If packet can’t be put to the queue, it will be dropped, no any message to CPU will be sent, no ICMP message will be generated.
So what do we have?
Ordinary tracert sends three UDP-packets with payload of 12 bytes. Totally 3*12=36 bytes. It is normally fits to 3000bps of the queue and all 3 packets will cause ICMP message sending to the source.
Then we run tracert with probe size of 1400 for example - totally 3*1400=2800+1400. First 1400 perfectly fit to 3000 bps, while last packet don’t - it will be dropped without any notification of tracert originator - so we get * in results.
We can see it by
And one more question exists: why tracert of directly connected device is always ok?
It is easy. Such UDP packet has IP of directly connected device as destination IP. Anyway it will be delivered to CPU without TTL check. So no * appears in spite of size of packets.
Solution
Why do you need the solution?