I reviewed the case and it looks like it is progressing. I wanted to see if you could try the below, it explains why you can't send 10G and where the drops are happening. In the example 1G is sent, but with the overhead of EVPN and you wanting to send closer to 10G that could be tweaked. Please see attached topology screenshot.
On NCS540 and NCS5500, we need to take into account of accounting overhead issue.
When we generate the traffic under 1Gbps, and inject it into imposition PE NCS540-1, since it is EVPN L2VPN solution, so when traffic leave NCS540-1 Tenge port, each packet has 22bytes outer header ( 18 bytes outter ethernet header + 4 bytes EVPN VPN labels, NCS540-1 and NCS540-2 is connected back to back, so LSP label is implicit null), so the traffic rate is actually exceeding 1Gbps, however the core facing interface is 10GE, so we don't see drop in imposition PE here.
When the traffic arriving at NCS540-2 TenGE port, the traffic rate is also exceeding 1Gbps ( each packet has 22 bytes overhead), NCS540-2 checking the internal 1Gbps shaping/police before packet disposition action, so each packet size is still 1540 bytes ( instead of 1518), traffic rate actually exceed 1Gbps, so traffic getting dropped for VoQ taildrop reason.
After we enable accounting overhead “account user-defined 22”, so this 1Gbps internal shape/police will not count those 22 bytes overhead, then we can prevent such drop.On other platform such as ASR9k and NCS6K, such internal shape/police is done after packet disposition, so the packet size is already changed back to 1518 byte, so we don’t see this kind of issue.
Policy-map TEST
Class class-default
Shape average 1 gbps
!
Inter GigabitEthernet0/0/0/3
Service-policy output TEST account user-defined 22
Sam
