tcpdump 기록에 Tc qdisc 지연이 표시되지 않음

tcpdump 기록에 Tc qdisc 지연이 표시되지 않음

veth-pair로 연결된 두 개의 Linux 컨테이너가 있습니다. 한 컨테이너의 veth-interface에서 tc qdisc netem 지연을 설정하고 여기에서 다른 컨테이너로 트래픽을 보냅니다. tcpdump/wireshark를 사용하여 양쪽에서 트래픽을 관찰하면 보낸 사람과 받는 사람의 동일한 패킷의 타임스탬프가 선택한 지연에 따라 다르지 않음을 알 수 있습니다.

libpcap이 tc qdisc에 해당하는 송신 트래픽에 타임스탬프를 삽입하는 시점을 더 자세히 이해하고 싶었습니다. 인터넷에서 구성표/이미지를 검색했지만 찾지 못했습니다. 이 주제를 찾았습니다(Wireshark 패킷 캡처 지점) 그러나 컨테이너/인터페이스를 하나 더 가짐으로써 간접 참조를 도입하는 것이 좋습니다. 내 상황에서는 이것이 가능한 해결책이 아닙니다. 추가 중간 인터페이스를 도입하지 않고(즉, 토폴로지를 변경하지 않고) 이미 지정된 veth-인터페이스에 기록하는 것만으로 지연을 볼 수 있는 방식으로 문제를 해결할 수 있는 방법이 있습니까?

업데이트:

너무 빨라서 실수했어요. 아래에 제시된 내 솔루션(@AB 답변의 첫 번째 솔루션과 동일)이나 @AB의 IFB 솔루션(이미 확인함)도 내 문제를 해결하지 못합니다. 문제는 a1-eth0토폴로지에서 보낸 사람 인터페이스의 전송 대기열 오버플로로 인해 발생합니다.

[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2

나는 너무 빨랐고 a1-eth0라우터 사이의 링크에서 10ms의 지연만 확인했습니다 r1. 오늘 나는 지연을 100ms, 200ms로 더 높게 만들려고 노력했으며 결과(패킷당 지연 및 내가 얻은 속도 그래프)는 위의 토폴로지와 일반 토폴로지에서 달라지기 시작합니다.

[a1-eth0]---100Mbps---r1---100Mbps---r2

따라서 정확한 테스트를 위해 추가 링크를 가질 수 없습니다. Linux 브리지나 이 IFB 또는 다른 제3의 시스템에서도 소개할 수 없습니다. 혼잡 제어 방식을 테스트합니다. 그리고 특정 토폴로지에서 이를 수행하고 싶습니다. 그리고 단지 플롯을 위한 토폴로지를 변경할 수는 없습니다. 즉, 속도와 지연 결과/플롯이 동시에 변경되는 경우를 의미합니다.

업데이트 2:

그래서 아래에서 볼 수 있듯이 해결책을 찾은 것 같습니다(NFLOG 솔루션).

업데이트 3:

다음은 NFLOG 솔루션의 몇 가지 단점(페이로드가 0인 송신 TCP 패킷에 대한 큰 링크 계층 헤더 및 잘못된 TCP 체크섬)에 대해 설명하고 이러한 문제가 없는 NFQUEUE를 사용하여 더 나은 솔루션을 제안했습니다.길이가 0인 송신 패킷에 대한 TCP 체크섬이 잘못되었습니다(iptables로 캡처).. 그러나 내 작업(혼잡 제어 방식 테스트)에는 NFLOG나 NFQUEUE가 모두 적합하지 않습니다. 동일한 링크에서 설명했듯이 패킷이 커널의 iptables에서 캡처되면 전송 속도가 조절됩니다(이것이 제가 이해하는 방식입니다). 따라서 인터페이스에서 캡처하여(즉, 정기적으로) 보낸 사람에게 녹음하면 2GB 덤프를 얻게 되고, iptables에서 캡처하여 보낸 사람에게 녹음하면 1GB 덤프를 얻게 됩니다. 대략적으로 말하면.

업데이트 4:

마지막으로 내 프로젝트에서는 아래 내 답변에 설명된 Linux 브리지 솔루션을 사용합니다.

답변1

에 따르면Netfilter 및 일반 네트워킹의 패킷 흐름회로도, tcpdump 캡처(AF_PACKET) 후에송신(qdisc). 따라서 tcpdump에서 지연이 표시되지 않는 것이 정상입니다. 지연은 초기 캡처 시 이미 존재했습니다.

한 단계 더 일찍 캡처해야 하므로 세 번째 시스템을 포함시킵니다.

S1: system1, 나가는 인터페이스에서 tcpdump 실행
R: 라우터(또는 편의에 따라 브리지, 아무것도 변경되지 않음), qdisc netem 실행
S2: system2, 들어오는 인터페이스에서 tcpdump 실행

 __________________     ________________     __________________
|                  |   |                |   |                  |
| (S1) -- tcpdump -+---+- (R) -- netem -+---+- tcpdump -- (S2) |
|__________________|   |________________|   |__________________|

즉, 3개의 네트워크를 의미합니다.스택관련되어 있는지 여부, VM, 네트워크 네임스페이스(포함IP 네트워크, LXC, ...)


선택적으로 라우터(또는 브리지)의 모든 특수 설정을 속이고 이동할 수도 있습니다.IFB인터페이스거울에 비친트래픽: 트릭(이 경우 전용)을 사용하여 송신이 아닌 netem 정렬 후 수신을 삽입할 수 있습니다.

 _______     ______________________________________________     _______
|       |   |                                              |   |       |         
| (S1) -+---+- tcpdump -- ifb0 -- netem -- (R) -- tcpdump -+---+- (S2) |
|_______|   |______________________________________________|   |_______|

기본 IFB 사용 예가 있습니다.TC 미러링맨페이지:

ifb 인터페이스를 사용하면 sfq 인스턴스를 통해 수신 트래픽을 보낼 수 있습니다.

# modprobe ifb
# ip link set ifb0 up
# tc qdisc add dev ifb0 root sfq
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: u32 \
  match u32 0 0 \
  action mirred egress redirect dev ifb0

그냥 사용네템sfq 대신 ifb0에서(그리고 초기가 아닌 네트워크 네임스페이스에서는 ip link add name ifbX type ifbmodprobe 없이도 잘 작동합니다).

제대로 작동하려면 여전히 3개의 네트워크 스택이 필요합니다.


사용하여NFLOG

JenyaKh의 제안 이후, 다음을 사용하여 패킷을 캡처하는 것이 가능하다는 것이 밝혀졌습니다.tcpdump,~ 전에출구(따라서 qdisc 이전) 및 출구(qdisc 이후): 다음을 사용하여iptables(또는nftables) 전체 패킷을 netlink 로그 인프라에 기록하고 여전히 다음을 사용하여 읽습니다.tcpdump, 그런 다음 다시 사용하여tcpdump송신 인터페이스에서. 이를 위해서는 S1의 설정만 필요합니다(더 이상 라우터/브리지가 필요하지 않음).

그래서iptablesS1에서는 다음과 같습니다.

iptables -A OUTPUT -o eth0 -j NFLOG --nflog-group 1

수행된 테스트와 일치하도록 특정 필터를 추가해야 할 수 있습니다.tcpdumpnflog 인터페이스에서는 필터가 제한됩니다(wireshark가 이를 더 잘 처리해야 합니다).

답변 캡처가 필요한 경우(여기서는 다른 그룹에서 수행되므로 추가 작업이 필요함)tcpdump):

iptables -A INPUT -i eth0 -j NFLOG --nflog-group 2

필요에 따라 다른 곳으로 옮기는 것도 가능합니다.원시/출력그리고원시/사전 라우팅대신에.

와 함께tcpdump:

# tcpdump -i nflog:1 -n -tt ...

입력에 다른 그룹(= 2)이 사용된 경우:

# tcpdump -i nflog:2 -n -tt ...

그런 다음 평소와 같이 동시에 다음을 수행합니다.

# tcpdump -i eth0 -n -tt ...

답변2

업데이트:

그래서 마침내 이 솔루션을 사용했습니다. 내 솔루션에 존재합니다. 결국 그것은 나에게 잘 작동했습니다.


나(주제 시작자)는 Linux 브리지를 사용하여 문제를 해결했습니다. 여기 [https://www.linuxquestions.org/questions/linux-networking-3/transferring-all-traffic-through-an-extra-interface-4175656515] 나는 Linux 브리지를 사용할 수 있었지만 가능성을 무시했다고 썼습니다."그러나 이 솔루션은 실제로 h1-br0과 h1-eth0 인터페이스 사이에 추가 이더넷 링크가 있기 때문에 내 요구 사항에 적합하지 않습니다. 성능 측정을 위해 이 기능이 필요하므로 추가 이더넷 링크를 가질 수 없습니다. 이 솔루션은 다음을 의미합니다. 브리지가 추가 링크를 도입하여 토폴로지를 엉망으로 만들었습니다."

       a1
-----------------
|a1-br0---a1-eth0|---------local network
------------------

솔루션을 먼저 무시한 이유는 무엇입니까? 처음에 내 토폴로지는 다음과 같습니다.

a1---3Gbps---r1---100Mbps---r2

링크에는 r1---r2netem 속도가 100Mbps로 설정되어 있으며 링크에는 a1---r1속도 제한이 없습니다. r1라우터에 연결하는 라우터의 전송 대기열은 1000개의 패킷이므로 에서 r2로 트래픽을 보낼 때 대기열 오버플로(일부 패킷이 삭제됨) 효과가 있었습니다 . 그리고 이것은 괜찮았습니다. 이는 링크 병목 현상이 발생할 경우 라우터 대기열이 오버플로되는 현실 세계에서 발생하는 방식입니다.a1r2

이제 저는 지연 및 속도 제한을 추가하기 위해 이 모든 연구를 수행합니다 a1---r1. 그래서 저는 Linux 브리지를 사용하여 이 솔루션을 생각해냈습니다. 하지만 나는 이 해결책이 효과가 없을 것이라고 생각했다. 아래에서 Linux 브리지가 포함된 새로운 토폴로지를 볼 수 있습니다.

[a1-br0 ---3Gbps---a1-eth0]---100Mbps---r1---100Mbps---r2

그래서 해결책에 대한 내 문제는 큐 오버플로가 이제 인터페이스의 전송 큐에 존재할 것으로 예상했다는 것입니다 a1-eth0. 즉, r1에 연결하는 인터페이스에서 오버플로가 발생했던 이전 그림과 같은 방식입니다 r2. 유사하게.

그리고 나는 이 오버플로를 원하지 않습니다. 지연 측정을 위해 Linux 브리지를 사용하지 않는 일반 토폴로지에서는 다음 전송 대기열의 오버플로가 발생하지 않습니다 a1-eth0.

[a1-eth0]---100Mbps---r1---100Mbps---r2

a1그런데 어제 Linux 브리지(위 그림의 세 번째 토폴로지)를 사용하여 토폴로지를 다시 생성하고 에서 로 흐르는 토폴로지에서 트래픽을 시작했습니다 r2. 500ms 간격으로 주기적으로 a1-eth0명령을 호출 하는 전송 큐의 백로그(현재 큐에 있는 패킷 수)와 유사한 명령 의 전송 큐의 백로그를 확인했습니다 .tc -s qdisc show dev a1-eth0a1-br0

에 대해 본 내용은 다음과 같습니다 a1-eth0. 메시지를 받았습니다.

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 9461862 bytes 6393 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 133380b 90p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 15280534 bytes 10323 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 133380b 90p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 21110722 bytes 14257 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 118560b 80p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 26952766 bytes 18199 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 102258b 69p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 32788882 bytes 22137 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 103740b 70p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 38635372 bytes 26082 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 102258b 69p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 44477416 bytes 30024 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 102258b 69p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 50332798 bytes 33975 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 102258b 69p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 56157058 bytes 37905 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 125970b 85p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 61969532 bytes 41828 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 133380b 90p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 67784900 bytes 45752 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 133380b 90p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 73600268 bytes 49676 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 133380b 90p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 79415636 bytes 53600 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 133380b 90p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 85244342 bytes 57533 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 120042b 81p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 91080458 bytes 61471 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 102258b 69p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 96923984 bytes 65414 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 102258b 69p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 102761582 bytes 69353 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 102258b 69p requeues 0 

qdisc netem 8112: root refcnt 2 limit 1000 delay 10.0ms
 Sent 108606590 bytes 73297 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 103740b 70p requeues 0 

에 대해 본 내용은 다음과 같습니다 a1-br0. 메시지를 받았습니다.

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

qdisc noqueue 0: root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

a1-eth0따라서 오버플로가 발생하지 않으며 실제로는 a1-br0아무것도 보내는 것처럼 "보이지" 않지만 실제로는 보내는 것을 볼 수 있습니다 . 따라서 a1-bro및 사이의 링크는 및 라우터 a1-eth0사이의 링크(veth 쌍 링크)와 다릅니다 . 왜 그런지 모르겠습니다. 예를 들어 netem 지연 설정을 다음에서 설정할 수 있다는 것을 확인했기 때문에 이상합니다 . 따라서 일반 인터페이스와 같습니다.a1r1a1-br0

어쨌든 브리지를 사용한 솔루션이 내 요구 사항을 모두 충족하는지 확인했습니다. 나는 그것이 왜 작동하는지 아직 탐구하지 않았습니다. (위에서 설명한 것의 의미에서 큐 오버플로 등을 의미합니다.)


참조를 위해 호스트에서 실행한 명령은 다음과 같습니다 a1. 하지만 문맥 없이는 완전히 이해하기 어렵다는 점은 이해합니다. 그러나 아마도 미래에 누군가에게 도움이 될 것입니다.

brctl addbr a1-br0
brctl addif a1-br0 a1-eth0
ip link set dev a1-br0 up
ip addr add dev a1-br0 11.0.0.1/30
ip addr flush dev a1-eth0
route add default gw 11.0.0.2 dev a1-br0
ifconfig a1-eth0 0.0.0.0 up
ethtool -K a1-br0 tx off sg off tso off ufo off

명령을 적용한 IP 주소가 있는 토폴로지도 여기에 있습니다.이 라우터의 다른 인터페이스로 Linux 라우터의 한 인터페이스를 ping하는 중. 토폴로지는 다음과 같습니다.

------                           ------                            ------
| a1 |                           | r1 |                            | r2 |
|    | a1-eth0-----------r1-eth0 |    |r1-eth1--------------r2-eth1|    |
-----(11.0.0.1/30)   (11.0.0.2/30)----(11.0.0.9/30)   (11.0.0.10/30)----- 

관련 정보