![tcpdump 기록에 Tc qdisc 지연이 표시되지 않음](https://linux55.com/image/155026/tcpdump%20%EA%B8%B0%EB%A1%9D%EC%97%90%20Tc%20qdisc%20%EC%A7%80%EC%97%B0%EC%9D%B4%20%ED%91%9C%EC%8B%9C%EB%90%98%EC%A7%80%20%EC%95%8A%EC%9D%8C.png)
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-eth0
10밀리초의 대기 시간 동안만 라우터에 대한 링크를 확인했습니다 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 ifb
modprobe 없이도 잘 작동합니다).
제대로 작동하려면 여전히 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
트래픽을 보낼 때 대기열 오버플로(일부 패킷이 삭제됨)의 영향을 경험하고 있습니다. 그것은 중요하지 않습니다. 이는 병목 링크가 발생할 때 라우터 대기열이 오버플로될 때 현실 세계에서 일어나는 일입니다.a1
r2
이제 나는 지연과 속도 제한을 추가하기 위해 이 모든 연구를 수행했습니다 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-eth0
500ms 간격으로 루프로 명령을 호출하는 전송 큐의 백로그(현재 큐에 있는 패킷 수)와 유사한 명령을 사용하여 전송 큐의 백로그를 확인했습니다 .tc -s qdisc show dev a1-eth0
a1-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 지연 설정을 다음으로 설정할 수 있는지 확인했기 때문에 이것은 이상합니다 . 따라서 일반 인터페이스와 같습니다.a1
r1
a1-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)-----