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

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

veth-pair를 통해 연결된 두 개의 Linux 컨테이너가 있습니다. 컨테이너의 veth 인터페이스에서 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-eth010밀리초의 대기 시간 동안만 라우터에 대한 링크를 확인했습니다 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개의 네트워크를 의미합니다.스택실제인지 여부에 관계없이 가상 머신, 네트워크 네임스페이스(포함)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개의 네트워크 스택이 필요합니다.


사용신경망 로그

JenyaKh의 제안 이후, 다음을 사용하여 패킷을 캡처할 수 있다는 것이 밝혀졌습니다.TCP 덤프,앞으로종료 시(따라서 qdisc 이전) 종료 시(qdisc 이후): 다음을 사용하여iptables(또는nftables) 전체 패킷을 netlink 로깅 인프라에 기록하고 계속 사용하려면TCP 덤프, 그런 다음 다시 사용TCP 덤프송신 인터페이스에서. 이를 위해서는 S1에서만 설정이 필요하며 더 이상 라우터/브리지가 필요하지 않습니다.

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

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

아마도 수행된 테스트와 일치하도록 특정 필터를 추가해야 할 것입니다.TCP 덤프필터는 nflog 인터페이스로 제한됩니다(wireshark가 이를 더 잘 처리해야 함).

답변을 캡처해야 하는 경우(여기서는 다른 그룹에서 수행되므로 추가TCP 덤프):

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

원하는 경우 다음으로 이동할 수도 있습니다.원시/출력그리고원본/사전 라우팅대신에.

그리고TCP 덤프:

# 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

링크에서 네트워크 속도를 100Mbps로 설정했는데 r1---r2링크에 a1---r1속도 제한이 없습니다 . r1연결 중인 라우터의 전송 대기열이 1000개의 패킷이므로 에서 r2트래픽을 보낼 때 대기열 오버플로(일부 패킷이 삭제됨)의 영향을 경험하고 있습니다. 그것은 중요하지 않습니다. 이는 병목 링크가 발생할 때 라우터 대기열이 오버플로될 때 현실 세계에서 일어나는 일입니다.a1r2

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

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

따라서 내 솔루션의 문제점은 큐 오버플로가 이제 인터페이스의 전송 큐에 나타날 것으로 예상했다는 것입니다 a1-eth0. 즉, 위 그림 r1의 연결된 인터페이스 에서의 오버플로와 같습니다 r2. 비슷하게.

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

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

하지만 어제 Linux Bridge(위에 그려진 세 번째 토폴로지)를 사용하여 토폴로지를 다시 만들고 토폴로지 a1에서 트래픽을 시작했습니다 r2. a1-eth0500ms 간격으로 루프로 명령을 호출하는 전송 큐의 백로그(현재 큐에 있는 패킷 수)와 유사한 명령을 사용하여 전송 큐의 백로그를 확인했습니다 .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와 사이의 링크는 veth와 라우터 사이의 링크(veth 쌍 링크) a1-eth0와 다릅니다 . 왜 이렇게 되어야 하는지 모르겠습니다. 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)----- 

관련 정보