Suốt nhiều thập kỷ, phản ứng mặc định của hạ tầng định tuyến Internet trước tình trạng quá tải đường truyền là loại bỏ gói tin (packet drop). Dưới cơ chế quản lý hàng đợi truyền thống Drop-Tail cùng các thuật toán kiểm soát tắc nghẽn cổ điển dựa trên mất gói như TCP Reno hay Cubic, router tại điểm nghẽn báo hiệu tắc nghẽn bằng cách để bộ nhớ đệm tràn khiến gói tin đến sau bị hủy. Phía gửi nhận diện việc thiếu gói xác nhận (ACK), suy luận đường truyền nghẽn, lập tức giảm một nửa cửa sổ tắc nghẽn (cwnd) và thực hiện truyền lại.

Vòng lặp phản hồi dựa trên mất gói này ngăn chặn sự cố sụp đổ toàn mạng nhưng mang lại tổn thất vận hành lớn. Đối với các ứng dụng tương tác thời gian thực—như đàm thoại thoại, hội nghị truyền hình, trò chơi trực tuyến đối kháng và giao dịch tần suất cao—gói tin bị hủy gây ra hiện tượng trễ tức thì, gián đoạn truyền tải và biến động độ trễ (jitter). Khi dữ liệu đi qua các đường hầm VPN mã hóa (như IPsec hay WireGuard), hiện tượng phình bộ đệm (bufferbloat) và mất gói còn nhân lên gấp bội do cấu trúc lồng ghép nhiều lớp giao vận.

Để tách biệt tín hiệu tắc nghẽn khỏi hành vi hủy gói tin, tổ chức IETF đã chuẩn hóa cơ chế Thông Báo Tắc Nghẽn Rõ Ràng (ECN - Explicit Congestion Notification) trong RFC 3168 và hoàn thiện quy tắc truyền dẫn qua đường hầm trong RFC 6040. Kế thừa nền tảng này, khung kiến trúc L4S (Độ trễ thấp, Mất gói thấp, Thông lượng co giãn - RFC 9330, RFC 9331, RFC 9332) giới thiệu cơ chế hàng đợi kép DualQ Coupled AQM, mở ra khả năng duy trì độ trễ xếp hàng dưới 1 mili-giây trên cả tuyến mạng thông thường lẫn hạ tầng VPN mã hóa.

Nghịch lý mất gói: Tại sao quản lý Drop-Tail thất bại trong mạng hiện đại

Trong kiến trúc mạng cổ điển, dung lượng chiếm dụng hàng đợi thường rơi vào hai thái cực bất lợi. Khi bộ đệm quá nhỏ, các đợt bùng nổ lưu lượng ngắn hạn không thể hấp thụ được, dẫn đến mất gói sớm và lãng phí băng thông đường truyền khả dụng. Ngược lại, khi các nhà sản xuất phần cứng và nhà mạng phân bổ bộ đệm quá lớn nhằm triệt tiêu mất gói, họ vô tình tạo ra thảm họa phình đệm (bufferbloat).

Khi xảy ra bufferbloat, router trung gian tích lũy hàng megabyte gói tin chờ xử lý trong các phiên truyền tải dữ liệu lớn. Gói tin nằm bất động trong bộ nhớ đệm vật lý suốt hàng trăm mili-giây để chờ đến lượt chuyển lên đường truyền vật lý. Đối với lưu lượng UDP tương tác cùng chia sẻ tuyến vật lý, khoảng thời gian chờ này phá vỡ tính liên tục của luồng dữ liệu. Thời gian khứ hồi thực tế ($RTT$) tăng vọt theo công thức:

$$RTT_{\text{actual}} = RTT_{\text{propagation}} + \frac{Q_{\text{bytes}}}{\text{Bandwidth}}$$

Khi hàng đợi cuối cùng bị tràn, việc loại bỏ hàng loạt gói tin gây ra hiện tượng đồng bộ giảm tốc (TCP global synchronization) trên toàn bộ các kết nối đồng thời. Đường truyền rơi vào vòng xoáy tuần hoàn: bơm đầy bộ đệm, dao động độ trễ, mất gói đột ngột và sụt giảm thông lượng nghiêm trọng. Việc coi mất gói là kênh đo lường tắc nghẽn biến suy giảm chất lượng mạng thành điều kiện tiên quyết để điều tiết luồng.

Kiến trúc ECN: Trường IP 2-bit và đàm phán bắt tay TCP (RFC 3168)

RFC 3168 loại bỏ nhu cầu hủy gói có chủ đích bằng cách thiết lập cờ ECN trực tiếp bên trong tiêu đề IP. Tiêu chuẩn này tái định nghĩa 2 bit có trọng số thấp nhất của trường Type of Service (ToS) trong IPv4 và trường Traffic Class trong IPv6:

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|      DSCP (6 bits)    |  ECN  |
+---+---+---+---+---+---+---+---+

Trường ECN 2-bit cung cấp 4 mã trạng thái hoạt động độc lập:

Mã nhị phân Ký hiệu Ý nghĩa giao thức
00 Non-ECT Không hỗ trợ ECN (xử lý hủy gói kiểu truyền thống)
01 ECT(1) Có hỗ trợ ECN (dành riêng cho luồng co giãn L4S)
10 ECT(0) Có hỗ trợ ECN (phản hồi chuẩn cổ điển RFC 3168)
11 CE Đã ghi nhận tắc nghẽn (Congestion Experienced, do router đánh dấu)

Trước khi kích hoạt ECN trên phiên TCP đầu-cuối, hai điểm mút phải đàm phán năng lực hỗ trợ trong quá trình bắt tay ba bước (three-way handshake):

  1. Gói SYN: Client bật cả hai cờ ECE (ECN-Echo) và CWR (Congestion Window Reduced) trong tiêu đề TCP để đề xuất hỗ trợ ECN.
  2. Gói SYN-ACK: Nếu server hỗ trợ ECN, máy chủ phản hồi với cờ ECE được bật và cờ CWR bị tắt.
  3. Gói ACK: Client hoàn tất bắt tay với cả hai cờ đều tắt, chính thức chuyển kết nối sang trạng thái truyền dữ liệu kích hoạt ECN.
Client                                                  Server
  |--- SYN [ECE=1, CWR=1] ------------------------------->| (Đề xuất hỗ trợ ECN)
  |<-- SYN-ACK [ECE=1, CWR=0] ----------------------------| (Chấp nhận hỗ trợ ECN)
  |--- ACK [ECE=0, CWR=0] ------------------------------->| (Kích hoạt phiên truyền)
  |                                                       |
  |=== Gói dữ liệu [IP: ECT(0)] =========================>| (Router trung gian gắn CE)
  |<== Phản hồi ACK [TCP: ECE=1] =========================| (Báo ngược sự kiện nghẽn)
  |--- Gói dữ liệu [TCP: CWR=1, IP: ECT(0)] ------------->| (Xác nhận giảm cửa sổ)

Khi đường truyền bắt đầu tích tụ hàng đợi, router trung gian sẽ ghi đè trường IP từ ECT(0) hoặc ECT(1) thành CE (11) thay vì hủy gói tin. Khi nhận được gói có dấu CE, phía nhận sẽ bật cờ ECE trong các gói TCP ACK kế tiếp. Phía gửi nhận thấy cờ ECE sẽ lập tức điều chỉnh giảm cửa sổ truyền tải và bật cờ CWR để xác nhận đã xử lý cảnh báo.

Thế tiến thoái lưỡng nan của đóng gói tunnel: Mất nhãn và lỗi lỗ đen

Mặc dù RFC 3168 đã định hình chuẩn xác hành vi cho các tuyến IP điểm-tới-điểm thông thường, tiêu chuẩn này để lại khoảng trống lớn khi áp dụng vào các giao thức đóng gói đường hầm (tunneling). Đóng gói là nền tảng cốt lõi của mạng riêng ảo, nơi một gói tin IP nội bộ được bọc bên trong một gói vận chuyển bên ngoài (như IPsec ESP, WireGuard UDP, GRE hoặc GENEVE).

Khi một gói tin đã bọc đường hầm đi qua router ISP trung gian đang bị nghẽn, router này sẽ đánh dấu CE (11) lên tiêu đề IP bên ngoài. Tuy nhiên, khi gói tin đến thiết bị đầu cuối giải mã đường hầm, quá trình bóc tách trong lịch sử thường gặp phải hai lỗi kiến trúc nghiêm trọng:

  1. Mù tín hiệu ECN (Đánh rơi dấu CE): Cổng giải mã bóc bỏ tiêu đề IP bên ngoài và chuyển tiếp gói IP bên trong với cờ ECN nguyên bản ban đầu (ECT(0) hoặc Not-ECT). Tín hiệu cảnh báo CE hoàn toàn biến mất sau khi tháo vỏ bọc. Tắc nghẽn trung gian tiếp tục gia tăng cho đến khi hàng đợi tràn và gây mất gói vật lý.
  2. Sao chép nhãn vô điều kiện (Lỗ đen ECN): Router đóng gói sao chép cơ học các bit ECN bên trong ra vỏ ngoài mà không kiểm tra xem luồng bên trong có hỗ trợ ECN hay không. Nếu một gói không hỗ trợ ECN (00) bị gói bên ngoài mang dấu CE, cổng giải mã sao chép ngược cờ CE vào bên trong sẽ khiến các máy trạm cũ không hiểu được và dẫn đến lỗi kết nối.

Những sai sót này từng khiến ECN bị vô hiệu hóa rộng rãi trên nhiều môi trường VPN doanh nghiệp trước đây.

Đặc tả chuẩn RFC 6040: Chế độ Normal, Compatibility và giải mã Egress

RFC 6040 đã xử lý triệt để bài toán đóng gói bằng cách thiết lập các quy tắc rõ ràng, độc lập với giao thức đóng gói cụ thể cho cả hai đầu đóng vỏ (ingress) và tháo vỏ (egress).

Quy tắc đóng gói Ingress: Ánh xạ ECT bên trong ra tiêu đề ngoài

Tại đầu vào đường hầm, thiết bị đóng gói xác định giá trị ECN cho tiêu đề IP bên ngoài dựa trên trạng thái tiêu đề bên trong và chế độ hoạt động:

  • Chế độ bình thường (Normal Mode - Mặc định RFC 6040): Nếu tiêu đề bên trong là Not-ECT (00), tiêu đề bên ngoài BẮT BUỘC phải đặt là Not-ECT (00). Điều này đảm bảo rằng các router trung gian sẽ hủy gói nếu xảy ra tắc nghẽn nghiêm trọng, vì điểm nhận cuối không có khả năng đọc dấu CE. Nếu tiêu đề bên trong là ECT(0), ECT(1) hoặc CE, tiêu đề ngoài sẽ sao chép tương ứng mã trạng thái đó.
  • Chế độ tương thích (Compatibility Mode): Sử dụng khi không thể xác minh cổng giải mã phía đối diện có tuân thủ RFC 6040 hay không. Tiêu đề ngoài luôn được gán cứng là Not-ECT (00) cho mọi gói, buộc các router trên tuyến phụ thuộc vào cơ chế hủy gói truyền thống thay vì phát sinh rủi ro sai lệch tín hiệu.

Bảng chân lý giải mã Egress: Kết hợp nhãn CE ngoài với trạng thái trong

Tại cổng giải mã đường hầm, thiết bị phải kết hợp trường ECN của vỏ ngoài với tiêu đề bên trong trước khi loại bỏ lớp vỏ. RFC 6040 quy định bảng chân lý kết hợp như sau:

Tiêu đề trong Tiêu đề ngoài Tiêu đề sau giải mã Hành động / Đánh giá vận hành
Not-ECT (00) Not-ECT (00) Not-ECT (00) Chuyển tiếp bình thường
Not-ECT (00) ECT(0) / ECT(1) Not-ECT (00) Điều kiện lỗi: Tiêu đề ngoài bị gán cờ ECT sai quy chuẩn
Not-ECT (00) CE (11) HỦY GÓI TIN Bắt buộc hủy: Tuyến ngoài bị nghẽn nhưng bên trong không đọc được CE
ECT(0) (10) Not-ECT (00) ECT(0) (10) Chuyển tiếp bình thường: Tuyến ngoài thông thoáng
ECT(0) (10) ECT(0) (10) ECT(0) (10) Tuyến truyền dẫn thông suốt không nghẽn
ECT(0) (10) CE (11) CE (11) Truyền tiếp tín hiệu nghẽn vào luồng dữ liệu bên trong
ECT(1) (01) CE (11) CE (11) Truyền tiếp tín hiệu nghẽn vào luồng dữ liệu bên trong
CE (11) Not-ECT (00) CE (11) Giữ nguyên dấu nghẽn đã có sẵn bên trong
CE (11) CE (11) CE (11) Giữ nguyên dấu nghẽn

Điểm cốt lõi bảo đảm tính toàn vẹn của RFC 6040 nằm ở dòng thứ 3: nếu gói tin bên trong vốn không hỗ trợ ECN nhưng vỏ ngoài ghi nhận tắc nghẽn (CE), thiết bị giải mã bắt buộc phải chủ động hủy gói tin. Việc hủy gói này kích hoạt cơ chế nhận biết mất gói chuẩn của máy gửi cũ, ngăn chặn việc âm thầm phình đệm trên đường truyền.

Bước tiến hóa L4S: Độ trễ thấp, mất gói thấp và thông lượng co giãn (RFC 9330)

Mặc dù ECN cổ điển theo RFC 3168 giải quyết được tình trạng mất gói không cần thiết, nó chưa thể xử lý triệt để độ trễ hàng đợi. Các thuật toán TCP truyền thống coi mỗi tín hiệu CE nghiêm trọng tương đương một lần mất gói: giảm một nửa cửa sổ truyền tải. Vì hình phạt quá nặng, router buộc phải đặt ngưỡng đánh dấu CE khá cao để tránh làm sụt giảm băng thông, chấp nhận độ trễ hàng đợi dao động từ 10 đến 50 mili-giây.

Kiến trúc L4S chuẩn hóa trong RFC 9330 khắc phục hoàn toàn sự đánh đổi này thông qua ba trụ cột phối hợp:

  1. Thuật toán kiểm soát tắc nghẽn co giãn (TCP Prague / QUIC L4S): Phía gửi điều chỉnh tốc độ liên tục dựa trên tín hiệu phản hồi tỷ lệ tần suất cao. Thay vì cắt giảm một nửa cửa sổ, Prague phản ứng với các dấu CE bằng các bước điều chỉnh rất nhỏ (tỷ lệ $O(1)$), giữ dung lượng hàng đợi luôn tiệm cận mức 0.
  2. Mã định danh luồng (RFC 9331): L4S sử dụng mã ECT(1) (01) trong tiêu đề IP. Các router trên đường truyền căn cứ vào mã này để phân loại gói tin L4S co giãn tách biệt khỏi lưu lượng cổ điển ECT(0) hoặc Not-ECT.
  3. Quản lý hàng đợi kép kết hợp DualQ Coupled AQM (RFC 9332): Thiết bị trung gian phân tách luồng dữ liệu thành hai hàng đợi logic song song, cô lập hoàn toàn lưu lượng yêu cầu độ trễ thấp khỏi các luồng chiếm đệm lớn nhưng vẫn bảo đảm phân chia băng thông công bằng.
Luồng gói tin IP đến
       |
       v
+-----------------------+
|  Phân loại (RFC 9331) |
+-----------------------+
       |               |
       | [ECT(1)]      | [Not-ECT, ECT(0)]
       v               v
+-------------+ +---------------+
| Hàng đợi L  | |  Hàng đợi C   |
| (Nông, gắn  | | (Đệm sâu,     |
| nhãn Step)  | |  AQM cổ điển) |
+-------------+ +---------------+
       \               /
        \             /
         v           v
+-------------------------------+
| Bộ điều phối ghép (RFC 9332)  |
+-------------------------------+
                |
                v  Chuyển tiếp tức thì (<1ms độ trễ)

Cơ chế DualQ Coupled AQM: Tách biệt luồng Classic và Prague (RFC 9332)

RFC 9332 định nghĩa cơ chế DualQ Coupled Active Queue Management, cho phép các ứng dụng thời gian thực độ trễ thấp cùng chia sẻ tuyến nghẽn vật lý với các luồng tải tệp dung lượng lớn mà không làm suy giảm chất lượng lẫn nhau.

Hàng đợi Classic nguyên bản: Sự kết hợp giữa FQ-CoDel và PIE

Hàng đợi cổ điển (C-Queue) tiếp nhận các gói Not-ECT và ECT(0). Hàng đợi này vận hành các thuật toán AQM tiêu chuẩn đã được kiểm chứng như PIE (Proportional Integral controller Enhanced) hoặc FQ-CoDel.

Hàng đợi C duy trì độ trễ mục tiêu trong khoảng 10 ms đến 20 ms. Khi phát sinh tắc nghẽn, nó thực hiện hủy gói Not-ECT hoặc đánh dấu CE lên gói ECT(0) với xác suất tỷ lệ thuận với căn bậc hai của hàm tắc nghẽn ($p_C$).

Hàng đợi độ trễ thấp: Đánh dấu bước nhảy và bộ đệm dưới 1 mili-giây

Hàng đợi độ trễ thấp (L-Queue) xử lý chuyên biệt các gói mang nhãn ECT(1). Do thuật toán Prague phản hồi tức thì với tín hiệu nhỏ nhất, hàng đợi L không cần dung lượng đệm sâu.

Thay vào đó, hàng đợi L áp dụng ngưỡng đánh dấu bước nhảy (step marking): nếu thời gian xếp hàng vượt ngưỡng tối thiểu (thường từ 500 micro-giây đến 1 mili-giây), các gói mới đến sẽ lập tức được gắn dấu CE. Tuyệt đối không có gói tin nào bị hủy trừ khi bộ nhớ phần cứng cạn kiệt hoàn toàn.

Để duy trì phân bổ băng thông công bằng giữa hai hàng đợi mà không để luồng cổ điển bị lấn át, RFC 9332 liên kết xác suất đánh dấu:

$$p_L = k \times p_C^2$$

Xác suất đánh dấu trong hàng đợi L ($p_L$) được ghép nối động với bình phương xác suất tắc nghẽn của hàng đợi C ($p_C$), đảm bảo luồng L4S và các luồng TCP Cubic nhận được dung lượng truyền tải tương đương nhau theo thời gian.

Tác động hiệu năng thực tế: Gaming, gọi video và đường hầm VPN mã hóa

Hiệu quả thực tế của việc kết hợp đóng gói ECN chuẩn RFC 6040 với kiến trúc DualQ AQM tạo ra bước nhảy vọt cho các ứng dụng mạng tương tác.

Trong các nền tảng điện toán đám mây cho game, tương tác thực tế ảo mở rộng (XR) và truyền số liệu tài chính, sự biến động độ trễ (jitter) làm suy giảm trải nghiệm người dùng nghiêm trọng hơn nhiều so với độ trễ trung bình. Dưới các đường hầm VPN kiểu Drop-Tail thông thường, việc kích hoạt một phiên tải dữ liệu nền 500 Mbps sẽ khiến ping của game thủ vọt từ 25 ms lên hơn 200 ms do bộ đệm đường truyền bị bão hòa.

Khi kích hoạt đóng gói ECN RFC 6040 cùng hàng đợi kép L4S DualQ AQM:

  • Độ trễ hàng đợi: Giảm từ mức 80–250 ms xuống dưới 1 mili-giây.
  • Tỷ lệ mất gói: Tiệm cận mức 0,00% ngay cả khi đường truyền đầy tải vì tắc nghẽn được giải tỏa qua cờ CE thay vì hủy khung truyền.
  • Tắc nghẽn đầu dòng (Head-of-Line Blocking): Được triệt tiêu hoàn toàn, bảo đảm các khung hình đàm thoại và tín hiệu điều khiển tương tác truyền thông suốt.

Đồng thời, việc tích hợp ECN vào mạng riêng ảo bổ trợ chặt chẽ cho các kỹ thuật bảo vệ giao vận chuyên sâu, bao gồm giải pháp xử lý sự cố TCP SACK, giữ cho bộ nhớ socket luôn trong trạng thái ổn định.

Kiến trúc RiceGuard: Đóng gói ECN chuẩn RFC 6040 và điều phối DualQ

Hạ tầng VPNRice tích hợp trực tiếp các nguyên lý RFC 6040 và RFC 9330 vào tầng chuyển tiếp dữ liệu độc quyền RiceGuard.

Các kiến trúc VPN truyền thống thường bỏ qua tiêu đề IP ngoài trong quá trình mã hóa chuyển đổi. Khi nhân hệ điều hành Linux đóng gói một gói tin vào WireGuard UDP hoặc IPsec ESP, cấu hình mặc định có thể không truyền ngược cờ CE từ vỏ ngoài về socket của ứng dụng khi giải mã.

[ Không gian người dùng máy khách: TCP Prague / QUIC ]
       |
       | (Tiêu đề IP trong: Mã trạng thái ECT(1))
       v
[ Động cơ đường hầm RiceGuard Client ]
       |
       | Đóng gói đầu vào Ingress (RFC 6040 Chế độ Normal)
       | Sao chép nguyên vẹn ECT(1) ra tiêu đề UDP/IP ngoài
       v
[ Tuyến truyền dẫn ISP công cộng gặp nghẽn DualQ ]
       |
       | Điểm nghẽn ghi nhận: Router trung gian đánh dấu CE (11)
       v
[ Cổng biên giải mã RiceGuard Gateway ]
       |
       | Bảng kết hợp Egress RFC 6040:
       | Vỏ ngoài: CE + Gói trong: ECT(1) ---> Chuyển tiếp gói trong mang dấu CE (11)
       v
[ Máy chủ đích / Hạ tầng đám mây ]
       |
       | Điều chỉnh tốc độ truyền mượt mà: Độ trễ đệm phát sinh = 0 ms

Bên trong lõi vận hành RiceGuard:

  • Xử lý Ingress/Egress chuẩn RFC 6040: Đường ống mã hóa kiểm tra và đồng bộ tiêu đề trong/ngoài ở tốc độ phần cứng danh định. Khi phát hiện gói tin mã hóa mang dấu CE, RiceGuard cập nhật ngay tiêu đề IP bên trong trước khi chuyển tiếp.
  • Tăng tốc phần cứng DualQ: Tại các node biên của VPNRice, lưu lượng vào được phân luồng vào các hàng đợi phần cứng DualQ thông qua bộ lọc eBPF/XDP. Gói tin UDP tương tác, luồng đàm thoại và gói tin L4S đi qua tuyến điều phối chuyên biệt, tách biệt khỏi hàng đợi dữ liệu lớn.
  • Tích hợp Path MTU: Vỏ bọc đường hầm được thiết lập cơ chế kẹp MSS động, ngăn chặn phân mảnh làm xáo trộn các bit ECN trên ranh giới mạng.

Danh mục kiểm tra kỹ thuật: Cấu hình ECN và L4S trên Linux và VPN Gateway

Để triển khai và kiểm thử năng lực hỗ trợ RFC 6040 và L4S trên hệ thống Linux cùng các cổng tập trung VPN, quản trị viên có thể thực hiện theo các bước sau:

  • Kích hoạt ECN toàn hệ thống: Thiết lập net.ipv4.tcp_ecn = 1 trong /etc/sysctl.conf để hỗ trợ đàm phán ECN cho cả chiều đi và chiều đến.
  • Kiểm tra phiên bản nhân hỗ trợ L4S: Bảo đảm hạt nhân Linux từ phiên bản 6.4 trở lên để có sẵn mã nguồn TCP Prague và bộ lập lịch DualQ AQM (sch_dualpi2).
  • Thiết lập thuật toán hàng đợi DualQ: Gắn bộ lập lịch DualQ vào giao diện mạng vật lý và giao diện đường hầm:
    tc qdisc add dev eth0 root dualpi2
  • Thực thi chuẩn RFC 6040 trên giao diện WireGuard/IPsec: Đảm bảo phần mềm đóng gói không cắt bỏ bit ECN. Với WireGuard, kiểm tra sysctl -w net.ipv4.conf.all.rp_filter=2 hoặc xác minh bảng định tuyến giao diện.
  • Giám sát bắt tay ECN: Sử dụng tcpdump bắt gói tin để xác thực chuỗi SYN, SYN-ACK và ACK đàm phán thành công cờ ECE và CWR:
    tcpdump -i any 'tcp[13] & 0xc0 != 0' -n -vv
  • Kiểm thử bảng chân lý giải mã: Truyền các gói tin thử nghiệm để xác nhận nhãn CE từ vỏ ngoài được phản ánh chính xác vào tiêu đề bên trong khi rời giao diện tunnel.
  • Theo dõi bộ đếm nhãn CE và tỷ lệ hủy gói: Giám sát thông số giao diện để đảm bảo các sự kiện nghẽn được xử lý bằng đánh dấu CE thay vì làm mất gói tin:
    tc -s qdisc show dev eth0