Point to Point Protocol (ppp) ppp được xây dựng dựa trên nền tảng giao thức điều khiển truyền dữ liệu lớp cao (High-Level Data link Control (hdlc)) nó định ra các chuẩn cho việc truyền dữ liệu các giao diện dte và dce của mạng wan như V

PPP cung cấp cơ chế chuyển tải dữ liệu của nhiều giao thức trên một đường truyền, cơ chế sửa lỗi nén header, nén dữ liệu và multilink. PPP có hai thành phần:

• 
  Link Control Protocol (LCP): (được đề cập đến trong RFC 1570) thiết lập, điều chỉnh cấu hình, và hủy bỏ một liên kết. Hơn thế nữa LCP còn có cơ chế Link Quality Monitoring (LQM) có thể được cấu hình kết hợp với một trong hai cơ chế chứng thực Password Authentication Protocol (PAP) hay Challenge Handshake Authentication Protocol (CHAP).
  
• 
  Network Control Protocol (NCP): NCP làm nhiệm vụ thiết lập, điều chỉnh cấu hình và hủy bỏ việc truyền dữ liệu của các giao thức của lớp network như: IP, IPX, AppleTalk and DECnet.
  

Chi tiết về định dạng khung của PPP như sau:

• 
  Dead: kết nối chưa họat động
  
• 
  Establish: khởi tạo LCP và sau khi đã nhận được bản tin Configure ACK liên kết sẽ chuyển sang pha sau: authentication
  
• 
  Authenticate: có thể lựa chọn một trong hai cơ chế PAP hay CHAP.
  
• 
  Network: trong pha này, cơ chế truyền dữ liệu cho các giao thức lớp Network được hỗ trợ sẽ được thiết lập và việc truyền dữ liệu sẽ bắt đầu.
  
• 
  Terminate: Hủy kết nối
  

Trong gói LCP (được chứa trong trường Information của gói tin PPP), trường Code sẽ định ra các gói tin Configure Request (1), Configure Ack (2), Configure Nak (3) nghĩa là không chấp nhận và Configure Reject (4).

Mỗi giao thức lớp 3 đều có NCP code xác định cho nó, và giá trị mã này được đặt trong trường protocol của gói tin NCP, một số giá trị ví dụ như sau:

Code..............................Protocol
8021..................................... IP
8029 ....................................AT
8025 ......................XNS, Vines
8027 ............................DECnet
8031 ..............................Bridge
8023 .................................OSI

Tham khảo thêm RFC 1662 và RFC 1549 mô tả cơ chế đóng khung cụ thể.

CHAP được sử dụng phổ biến hơn PAP, do nó có khả năng mã hóa mật khẩu cũng như dữ liệu.

• 
  Giả sử một user A quay số truy cập vào access server B.
  
• 
  Access server sẽ gửi qua đường truyền một gói tin khởi tạo chứng thực Type 1 gọi là gói tin Challenge. Gói tin Challenge này chứa một số được sinh ngẫu nhiên, một số ID sequence number để xác định challenge và tên chứng thực của challenager
  
• 
  Bên gọi sẽ lấy ra chuỗi authentication name, và tìm trong dữ liệu của mình chuỗi mã mật CHAP ứng với user name nhận được.
  
• 
  Caller sẽ nhập mã mật của CHAP, số ID sequence number và một giá trị số được sinh ngẫu nhiên vào thuật toán băm Message Digest 5 (MD5).
  
• 
  Giá trị kết quả sau khi tính toán hàm băm được gửi trả lại cho Challenger (Access server) trong một gói CHAP Response (Type 2) chứa chuỗi băm, tên chứng thực của caller và cuối cùng là ID (Sequence Number) được lấy từ gói Challenge.
  
• 
  Khi nhận được gói Response Type 2, Challenger sẽ sử dụng ID để tìm gói Challenge nguyên thủy.
  
• 
  username của caller (A) được sử dụng để tìm kiếm mã mật CHAP từ một local database, hay một RADIUS server hoặc một TACACS+ server.
  
• 
  ID, giá trị Challande gốc được sinh ngẫn nhiên và giá trị CHAP ngẫu nhiên ban đầu và mã mật của được đưa vào xử lỷ bởi hàm băm MD5.
  
• 
  Chuỗi băm kết quả sau khi tính toán sau đó được so sánh với giá trị nhận được trong gói Response.
  
• 
  Nếu 2 chuỗi là giống nhau thì quá trình chứng thực CHAP đã thành công và các gói Type 3 được gửi đến caller chứa ID. Điều này có nghĩa là kết nối đã được chứng thực hợp lệ.
  
• 
  Nếu chứng thực CHAP thất bại, một gói tin Type 4 sẽ được gửi đến caller trong đó chứa original ID, xác nhận quá trình chứng thực là không thành công.
  

Callback là một tính năng của PPP rất có ích trong việc giảm thiểu chi phí truyền dữ liệu đồng thời cung cấp cơ chế bảo mật thông tin. Quá trình Callback diễn ra như sau.

1. 
   Client khởi tạo cuộc gọi. Đồng thời client request dịch vụ callback cùng với các lựa chọn thông số khác của kết nối trong pha LCP negotiation (cấu trúc trường Callback Option Message trong PPP được định nghĩa chi tiết trong RFC 1570).
   
2. 
   Callback request được acknowledgement bởi server và server sau đó sẽ kiểm tra thông số cấu hình của nó xem việc kích hoạt dịch vụ này là có được phép hay không.
   
3. 
   Việc chứng thực người dùng diễn ra và client username được sử dụng trong dialer map để xác định dial string sử dụng trong cuộc gọi ngược lại.
   
4. 
   Nếu chứng thực thành công nhưng lựa chọn dịch vụ callback là không được phép thì cuộc gọi vẫn tiếp tục và client sẽ là người trả tiền cho cuộc gọi, nếu chứng thực không thành công server sẽ hủy cuộc gọi.
   
5. 
   Client được gọi bởi server bằng chuỗi dial string được cấu hình cho cuộc gọi đảo chiều.
   
6. 
   Thực hiện chứng thực lần nữa.
   
7. 
   Kết nối tiếp tục.
   

Tính năng này chỉ được thực hiện trên các liên kết synchronous chuẩn. Chất lượng đường truyền được giám sát dựa trên phần trăm thông tin được truyền và nhận thành công trong một khoảng thời gian nhất định. Các Link Quality Reports (LQR) chứa các bộ đếm cho phép xác định chất lượng dữ liệu inbound và outbound. Echo Requests cũng được gửi định kỳ, nếu , sau một số echo requests nhất định, không nhận được echo replies, phiên truyền của các NCP sẽ bị hủy.

Việc nén dữ liệu có thể là nén mềm sử dụng một số tiện ích như Wellfleet Compression Protocol (WCP) (giao thức này được sử dụng trong các router của Nortel) và cho hiệu quả tốt nhất trên những đường truyền tốc độ chậm (128Kb/s or less).

Các cơ chế nén trên chỉ được áp dụng cho dữ liệu của các giao thức lớp 3 (IPCP và IPXCP), mà không ảnh hưởng đến traffic của các giao thức LCP và NCP lớp 2. Cơ chế nén theo giao thức WCP chỉ chạy giữa 2 router của Nortel vì WCP gán một giá trị protocol vào trường protocol a protocol value in the protocol field that is proprietory to Nortel Networks.

Bộ đệm dữ liệu history hoạt động ở cả 2 đầu, các chuỗi data đã truyền và nhận sẽ được lưu ở đó. Khi thực hiện một lượt truyền mới, các chuỗi mới sẽ được so sánh với các chuỗi đã truyền lưu trong bộ đệm, nếu trùng khớp toàn bộ hoặc một phần thì dữ liệu sẽ không được gửi đi toàn bộ mà chỉ phần sai khác được gửi đi. Bên nhận cũng thực hiện việc so khớp tương tự với bộ đệm history của mình để lấy ra được dữ liệu phiên trước để ghép với dữ liệu mới tạo thành thông tin hoàn chỉnh.

Nortel cung cấp hai chế độ nén:

• 
  Continuous Packet Compression: The history buffer spans multiple packets, which means more memory is used up, but produces greater compression ratio.
  
• 
  Packet-by-Packet Compression: The history buffer is reset with each packet, which means less memory is used but the compression ratio is not as great.
  

• 
  Stacker - which examines the data and only sends each data type once and sends information indicating to the other end where each type occurs within the data stream. The other end reassembles the data into the various data types from the data stream. Stacker tends to be more CPU intensive and less memory intensive.
  
• 
  Predictor – phân tích dữ liệu để kiểm tra xem nó đã được nén chưa và chỉ truyền đi các thông tin đã được nén, như vậy sẽ không mất thời gian nén lại các dữ liệu đã được nén Predictor tốn nhiều memory hơn và tốn ít CPU hơn.
  

Có một số lựa chọn cho LCP, một trong số đó là multilink với interleaving. Để multilink PPP hoạt động, PPP packets được chia cắt và đánh số sequence numbers để các packets lớn có thể chia được trên một số đường PPP links. Các số liệu của cơ chế này đã được chuẩn hóa và đưa vào RFC 1717 phục vụ cho việc truyền các luồng data thời gian thực như voice ngay cả khi PPP được sử dụng để truyền dữ liệu trên 1 link.

Một frame được chia thành nhiểu mảnh nhỏ có các trường header thu gọn và sequence number cho riêng nó. Các gói dữ liệu Real time nhỏ thì không được chia nữa và được để ở nguyên dạng PPP. Bên nhận sẽ phải thiết lập một hàng đợi đủ lớn để lưu, xử lý và sắp xếp các mảnh nhỏ để tái tạo lại các frame dữ liệu lớn. Một hàng đợi riêng sẽ được thiết lập để dành riêng cho việc xử lý các traffic dữ liệu real time. Hàng đợi này sẽ cần được xử lý với tốc độ nhanh hơn các hàng đợi thông thường khác.

Multilink PPP (MPPP or MP)

MPPP cung cấp cơ chế phân tải trên một số giao diện thuộc các loại khác nhau như synchronous, asychronous và ISDN.

Multilink PPP sử dụng Bandwidth Allocation Protocol (BAP & BACP) (RFC 2125) để thay đổi động số kênh mang dữ liệu (của các loại đường truyền khác nhau) tùy thuộc vào yêu cầu truyền. Các kênh riêng biệt này được coi như một kênh logic duy nhất hay một bó và các PDU của lớp trên sẽ được cắt và ghép để truyền trên đường logic này.

Khung PPP có 4 byte header sequence cho PPP multilink được dùng khi cho việc chia và đánh thứ tự cho các datagrams khi truyền trên nhiều link. Trong quá trình LCP negotiation một peer muốn thiết lập multilink, sẽ gửi đi một Maximum Received Reconstructed Unit (MRRU) khi thực hiện LCP negotiation, định ra kích thước của pipe hay bundle multilink. Username sẽ được dùng để xác định bundle nào để thêm các link vào.

Frame relay vẫn là công nghệ WAN được triển khai nhiều nhất có dùng router. Đã có một sự chuyển đổi dần dần từ FR sang các công nghệ như VPN dựa trên nền IP và MPLS-VPN. Tuy nhiên Frame relay sẽ vẫn đóng một vai trò lớn trong các mạng doanh nghiệp trong một tương lai trước mắt.

Chuẩn FR được phát triển bởi nhiều nhóm nghiên cứu. Ban đầu, Cisco và các công ty khác (còn được gọi là gang of four) phát triển một chuẩn giúp cho tính tương thích của FR và phát triển sản phẩm. Sau đó một diễn đàn về Frame relay Framerelay Forum được thành lập nhằm phát triển FR. IETF hiện định nghĩa vài RFC liên quan đến việc dùng FR như là giao thức lớp 2 trong mạng IP.

Tài liệu Cisco IOS thường mô tả các chuẩn của FR thông qua các thoả hiệp hiện thực FRF, ví dụ FRF.12 liên quan đến đặc tả cho tiến trình phân mảnh. Cuối cùng, ANSI và ITU xây dựng trên các chuẩn này để chuẩn hóa FR theo chuẩn quốc gia của Mỹ và quốc tế.

Công nghệ Frame Relay thường chuyển các frame từ nguồn đến đích trên những đường dẫn kết nối ảo. Các đường đi ảo này có thể là các mạch ảo thường trực (permanent virtual circuits - PVCs) hoặc các mạch ảo chuyển mạch (switched virtual circuits - SVCs).

Một PVC thường được thiết lập bởi các nhà cung cấp dịch vụ khi họ lập trình các tổng đài Frame Relay Switch. Tùy thuộc vào thoả thuận với nhà cung cấp, một khách hàng hoặc một PVC của người dùng có thể được cấu hình để mang lưu lượng đến một tốc độ nào đó được gọi là tốc độ thông tin cam kết (committed information rate - CIR).

CIR là tốc độ truyền mà mạng Frame Relay hoặc nhà cung cấp đồng ý truyền trong tình trạng bình thường, đây cũng là tốc độ trung bình trong một khoảng thời gian nào đó. Đơn vị của CIR là bits trên giây.

Mỗi kết nối PVC ở cuối mỗi thiết bị đầu cuối được xác định bằng một địa chỉ có chiều dài 10 bit trong phần header đầu của frame, còn được gọi là DLCI. DLCI thường được dùng để ánh xạ đến địa chỉ lớp mạng của đích đến, tức địa chỉ của router ở đầu xa của mạch PVC. Sau đó dữ liệu cần được truyền trên hạ tầng Frame relay sẽ được đóng gói trong các header này.

Mỗi header trong Frame Relay được chèn vào giá trị DLCI tương ứng đến địa chỉ lớp mạng của đích đến. Các frame sau đó sẽ được gửi đến tổng đài với giá trị DLCI ban đầu. Các frame này tiếp tục được trung chuyển về phía mạng đích thông qua các tổng đài của các nhà cung cấp dịch vụ FR. Các tổng đài FR có thể thay đổi giá trị DLCI sang các PVC khác trên đường đi về đích. Kết quả là, giá trị DLCI của một frame không nhất thiết phải là giống như giá trị ban đầu khi frame đi vào mạng Frame Relay. Vì vậy, giá trị DLCI chỉ có ý nghĩa cục bộ. Ngoài ra, cả hai đầu của PVC có thể dùng cùng giá trị DLCI, ví dụ DLCI 200. Tuy nhiên, ở cuối một kết nối, một DLCI không thể tượng trưng cho nhiều hơn một PVC.

Để kết nối hai thuê bao Frame Relay DTE, nhà cung cấp dịch vụ FR sẽ dùng một mạch ảo giữa hai router đầu cuối. Một router có thể gửi ra một frame Frame Relay, trong đó có một trường có chiều dài 10-bit để nhận dạng từng VC, gọi là Data Link Connection Identifier (DLCI).

Các tổng đài trung gian FR chuyển các frame dựa trên thông tin trên giá trị DLCI của frame, cho đến khi frame thực sự thoát ra khỏi tổng đài để đến router trên đầu kia của kết nối. Các giá trị FR DLCI chỉ có ý nghĩa cục bộ, nghĩa là một giá trị DLCI nào đó chỉ có ý nghĩa trên một kết nối đơn. Kết quả là giá trị DLCI của một frame có thể thay đổi khi frame đi qua một mạng. Năm bước dưới đây hiển thị các giá trị DLCI cục bộ cho một mạch ảo trong hình vẽ.

Router A gửi ra một frame với giá trị DLCI 41.

Trong thực tế, một vài nhà cung cấp dịch vụ dùng địa chỉ DLCI toàn cục. Qui ước DLCI truyền thống cho phép ta suy nghĩ router có một địa chỉ đơn duy nhất, cũng tương tự như vai trò của địa chỉ MAC. Tuy nhiên các địa chỉ vẫn là cục bộ và một giá trị DLCI của một mạch ảo VC vẫn có thể bị thay đổi giá trị khi nó đi qua một hệ thống mạng. Ví dụ, cho cùng một VC từ routerA đến RouterB, chỉ ra routerA có DLCI là 40 và routerB có DLCI là 41.

Ý tưởng của địa chỉ toàn cục thì cũng giống như trong LAN. Ví dụ, khi router A gửi một frame đến Router B, router A sẽ gửi frame đến địa chỉ toàn cục của router B (41). Tương tự, routerB sẽ gửi một frame đến địa chỉ toàn cục của router A (40).

Các thông điệp quản lý trạng thái cổng nội bộ (Local Management Interface – LMI)

Các thông điệp LMI trong FrameRelay giúp ta quản lý trạng thái đường truyền giữa router thuê bao và tổng đài FR. Một router thuê bao dịch vụ FR có thể gửi các thông điệp truy vấn về trạng thái đến tổng đài và tổng đài sẽ trả lời bằng thông điệp trạng thái LMI Status để thông báo cho router về giá trị DLCI của mạch ảo VC cũng như là trạng thái của từng mạch VC này.

Ở chế độ mặc định, thông điệp LMI được gửi mỗi 10 giây. Cứ mỗi thông điệp thứ sáu sẽ mang đầy đủ thông tin về trạng thái, trong đó bao gồm thông tin đầy đủ hơn về từng VC.

Các thông điệp truy vấn LMI Status enquiry (từ router) và Status (từ tổng đài) cũng hoạt động như cơ chế keepalive. Một router sẽ xem các cổng của nó là bị hỏng nếu router không thể nhận thông điệp từ tổng đài trong ba chu kỳ (mỗi chu kỳ là 10 giây). Kết quả là, cơ chế LMI trong Frame Relay thực sự được cho phép hoặc không được cho phép bằng cách dùng lệnh keepalive/no keepalive trên cổng Frame Relay của router. Nói cách khác, lệnh no keepalive sẽ tắt các thông điệp LMI.

Có ba loại thông điệp LMI tồn tại, chủ yếu là do có nhiều nhà cung cấp thiết bị và các chuẩn khác nhau để phát triển FR. Kiểu được định nghĩa sớm nhất, được gọi là Cisco LMI thì hơi khác với các kiểu ANSI và ITU được định nghĩa sau đó. Sự khác nhau ở điểm:

Cisco LMI cho dùng các giá trị DLCI được phép, tức dãy số DLCI cho phép.

Nói một cách thực tế, các vấn đề này ít quan trọng. Mặc định router sẽ tự động dò tìm loại LMI. Nếu cần thiết, lệnh frame-relay lmi-type có thể được dùng để chỉ ra kiểu LMI được dùng trên đường truyền Frame Relay.

Bảng dưới đây liệt kê ba kiểu LMI, từ khóa type cùng với vài điểm so sánh liên quan đến LMI và các giá trị DLCI cho phép. Ví dụ kiểu LMI của Cisco cho phép dùng các giá trị DLCI từ 16 cho đến 1007. Kiểu LMI của ANSI cho phép dùng DLCI từ 16 đến 991. Giá trị DLCI được dùng để bởi chính LMI để truyền và nhận các thông điệp cũng khác nhau. Cisco LMI dùng DLCI 1023, còn ANSI LMI dùng DLCI 0.


Frame Relay Headers và quá trình đóng gói FR

Router tạo ra các frame bằng cách dùng các header liên tiếp khác nhau. Header đầu tiên là ITU Link Access Procedure for Frame-Mode Bearer Services (LAPF). Header LAPF bao gồm tất cả các trường được dùng bởi tổng đài FR để phân phối các frame trên đám mây FR, các trường này bao gồm DLCI, DE, BECN và FECN.

Các trường theo sau phần LAPF sẽ chứa các thông tin quan trọng cho các router thuê bao trên đầu cuối của VC. Đối với đoạn header đóng gói, có hai tùy chọn tồn tại:

Các loại header do Cisco định nghĩa ban đầu.

Nếu ta dùng Cisco router ở cuối mỗi VC, tuỳ chọn cisco là phù hợp và làm việc tốt. Trong khi, tùy chọn ietf là cần thiết trong trường hợp dùng nhiều sản phẩm của các hãng khác nhau. Cả hai header đều có một trường có tên là protocol để hỗ trợ nhiều giao thức lớp 3 trên một VC. Trường được dùng nhiều nhất là trường xác định giao thức lớp mạng Network Layer Protocol ID, được mô tả trong RFC2427. Hình dưới đây mô tả cấu trúc của header và trailer.

Mỗi VC mặc định đều dùng header của Cisco trừ phi được cấu hình để dùng header kiểu IETF. Có ba phương thức được dùng để cấu hình một VC dùng kiểu header IETF:

Dùng lệnh encapsulation frame-relay ietf. Lệnh này sẽ thay đổi trạng thái mặc định của cổng đó sang IETF thay vì dùng cisco.
Dùng lệnh frame-relay interface-dlci number ietf, bỏ qua trạng thái mặc định cho VC này.
Dùng lệnh frame-relay map dlci….ietf. Lênh này cũng sẽ thay đổi trạng thái mặc định của VC.

Ví dụ, trên một cổng có 10 VC, trong đó có bảy VC cần phải dùng kiểu đóng gói IETF, cổng có thể chuyển sang IETF bằng lệnh encapsulation frame-relay ietf. Sau đó, lệnh frame-relay interface-dlci number cisco có thể được dùng cho ba VC cần chạy theo kiểu đóng gói Cisco.

Mạng FR, cũng giống như các mạng đa truy cập khác, có thể tạo ra nghẽn do vấn đề tốc độ không đồng bộ. Ví dụ một mạng Frame Relay có 20 thuê bao với các đường 256 kbps và một văn phòng chính có băng thông mức T1. Nếu cả 20 site gửi các frame liên tục về văn phòng chính ở cùng một thời điểm, ta sẽ có khoảng 5Mbps dữ liệu cần đi ra khỏi đường T1 1.5Mbps, làm cho hàng đợi của tổng đài FRSwitch tăng nhanh.

Tương tự, khi văn phòng chính cần gửi dữ liệu đến bất kỳ chi nhánh nào, router sẽ gửi ở tốc độ T1. Điều này là nguyên nhân tiềm tàng gây nghẽn đầu ra, các hàng đợi cũng có thể tăng nhanh chóng bên trong mạng FrameRelay.

Do đó, FR cung cấp hai phương thức để phản ứng với vấn đề nghẽn.

Adaptive Shaping, FECN và BECN

Ở chương 16, “shaping và policing” đã mô tả khái niệm định hình lưu lượng theo chế độ thích ứng, trong đó router sẽ thay đổi tốc độ định hình tùy thuộc vào mạng có nghẽn hay không. Để phản ứng với nghẽn xảy ra trong mạng FR, router phải nhận được vài dạng thông báo từ tổng đài FRSwitch rằng nghẽn đã xảy ra. Vì vậy phần header của FR sẽ bao gồm các bit Forward Explicit Congestion Notification (FECN) và bit Backward Explicit Congestion Notification (BECN) bits để báo hiệu nghẽn xảy ra trên một VC nào đó.

Để thực hiện việc này, khi một tổng đài FRSwitch nhận thấy có nghẽn gây ra bởi một VC, tổng đài sẽ gán bit FECN trong một frame của VC đó. Tổng đài cũng theo dõi các VC đang bị nghẽn sao cho nó có thể tìm ra frame kế tiếp đang được gửi trên VC đó nhưng đi theo chiều đối diện như trong bước 4 của hình. Tổng đài sau đó sẽ đánh dấu bit BECN trong frame đang truyền theo chiều ngược lại này. Router nhận được frame có bit BECN biết rằng một frame do router gửi ra đã chịu tình trạng nghẽn, vì vậy router có thể giảm tốc độ gửi dữ liệu của nó xuống. Hình dưới đây mô tả một ví dụ của tiến trình.

Bit FECN có thể được gán bởi tổng đài FR nhưng không thể được gán bởi bất kỳ router nào bởi vì router không cần truyền tín hiệu nghẽn. Ví dụ, nếu R1 nghĩ rằng nghẽn xảy ra từ trái sang phải, R1 có thể chỉ cần giảm tốc độ truyền xuống. Ở đầu kia của kết nối, R2 là đích đến của frame, vì vậy nó sẽ không bao giờ lưu ý về nghẽn xảy ra cho những frame đi từ trái sang phải. Vì vậy, chỉ có tổng đài cần phải thiết lập giá trị bit FECN.

BECN thì có thể được gán bởi tổng đài và bởi router. Hình trên mô tả một tổng đài gán giá trị BECN trên frame kế tiếp của người dùng. Nó cũng có thể gửi các frame kiểm tra Q.922. Động thái này giúp loại bỏ sự cần thiết phải chờ cho có lưu lượng của người dùng gửi trên VC và gán giá trị BECN trên frame đó. Cuối cùng, các router có thể được cấu hình để xem xét các frame có bit FECN, phản ứng lại bằng cách gửi ra các frame kiểm tra Q.922 trên VC đó với bit BECN được thiết lập. Đặc tính này, thỉnh thoảng còn được gọi là phản hồi FECN. Tính năng này được cấu hình bằng lệnh shape fecn-adapt (CB Shaping) hoặc lệnh traffic-shape fecn-adapt (FRTS).

Bit chỉ ra khả năng loại bỏ frame DE

Khi có nghẽn xảy ra, các hàng đợi trong tổng đài FRSwitch bắt đầu lấp đầy. Trong vài trường hợp, frame có thể bị loại bỏ ra khỏi hàng đợi. Tổng đài có thể (nhưng không yêu cầu) phải kiểm tra bit chỉ ra khả năng loại bỏ của frame Discard Eligibility (DE) khi frame cần phải bị loại bỏ. Tổng đài FR sẽ chủ động loại bỏ các frame có bit DE thay vì loại bỏ các frame không có bit DE.

Cả router và tổng đài FR có thể gán bit DE. Thông thường, một router sẽ ra quyết định về việc gán bit DE trong vài frame nào đó, bởi vì người quản trị có khả năng biết các lưu lượng nào là quan trọng hơn lưu lượng nào, thường là chiều inbound.

Đánh dấu các bit DE có thể được thực hiện thông qua cơ chế CB Marking, dùng lệnh set fr-de của MQC. Mặc dù router thường thực hiện việc đánh dấu bit DE, các tổng đài FR cũng có thể đánh dấu bit DE. Đối với tổng đài, động tác đánh dấu thường được thực hiên khi tổng đài khống chế lưu lượng, nhưng thay vì loại bỏ các lưu lượng vượt quá giới hạn, tổng đài sẽ đánh dấu bit DE. Bằng cách này, các tổng đài bên dưới sẽ có khả năng loại bỏ các frame đã đánh dấu và gây ra nghẽn.

Bảng dưới đây tóm tắt các điểm mấu chốt về FECN, BECN và bit DE



Cấu hình Frame Relay

Phần này mô tả các cấu hình cơ bản và các lệnh hoạt động, cùng với các cơ chế nén tải trên FR và cơ chế chèn LFI trong FR.

Hai chi tiết quan trọng nhất liên quan đến cấu hình Frame Relay là việc kết hợp các giá trị DLCI với các cổng hoặc subinterface và việc ánh xạ địa chỉ lớp 3 đến các giá trị này. Một điều thú vị là cả hai đặc điểm này có thể được cấu hình với cùng hai lệnh: frame-relay map và lệnh frame-relay interface-dlci.

Mặc dù một router có thể học các giá trị DLCI trên đường truyền FR thông qua các thông điệp LMI, các thông điệp này không có chức năng ngầm định rằng DLCI sẽ dùng cho cổng nào. Để cấu hình FR dùng các subinterface, các thông số DLCI phải được kết hợp với các subinterface. Bất kỳ DLCI nào được học với LMI mà không kết hợp với một cổng subinterface thì sẽ được giả sử là dùng cho cổng vật lý.

Một phương thức phổ biến hơn để thực hiện việc kết hợp này là dùng lệnh frame-relay interface-dlci trong dấu nhắc lệnh sub interface. Trên các subinterface dạng điểm-nối-điểm point-to-point, chỉ có một lệnh frame-relay interface dlci là được phép dùng, trong khi nếu cổng là dạng đa điểm multipoint, có thể nhiều lệnh được dùng.

Một phương thức thay thế là dùng lệnh frame-relay map. Lệnh này vẫn ánh xạ địa chỉ lớp 3 sang giá trị DLCI nhưng cũng ngầm định chỉ ra rằng DLCI thuộc về cổng mà lệnh này được cấu hình. Trên các cổng subinterface dạng đa điểm, nhiều lệnh có thể được cho phép đối với từng giao thức lớp 3.

Ví dụ dưới đây mô tả các tùy chọn cấu hình của FR, dùng lệnh frame-relay interface-dlci và các lệnh show liên quan. Ví dụ này hiện thực các yêu cầu sau đây:

Bắt đầu bằng cấu hình của R1. Cổng subinterface s0/0.14 hiển thị tùy chọn IETF được dùng trên lệnh frame-relay interface-dlci. Cổng subinterface s0/0.123 có hai DLCI thuộc về nó, là VC kết nối đến R2 và R3.

Code:

interface Serial0/0/0

!

interface Serial0/0.14 point-to-point

frame-rely interface-dlci 104 IETF

!

interface Serial0/0/0.123 multipoint

frame-relay interface-dlci 102

frame-relay interface-dlci 103

Tiếp theo là cấu hình R2. R2 gán giá trị DLCI cho VC từ R1 và R3 đến cổng subinterface .123. Chú ý rằng số của subinterface của router không cần phải đúng bằng giá trị DLCI.

Code:

interface Serial0/0/0

!

interfacce Serial0/0/0.123 multipoint

frame-relay interface-dlci 101

frame-relay interface-dlci 103

Tiếp theo là cấu hình R4, trong đó đóng gói bằng lệnh frame-relay ietf. Lệnh này sẽ thiết lập kiểu đóng gói cho tất cả các VC trên cổng S0/0/0. Cũng lưu ý rằng tần suất gửi các thông điệp đã thay đổi từ giá trị mặc định (10) thành 8 thông qua lệnh keepalive 8.

Code:

interface Serial0/0/0

keepalive 8

!

interface Serial0/0/0.1 point-to-point

frame-relay interface-dlci 101

Lệnh show frame-relay pvc hiển thị các thông tin thống kê và trạng thái của từng VC. Lệnh kế tiếp trên R1 đã bỏ qua một số đoạn, chỉ để lại những dòng có trạng thái PVC.

Code:

DLCI = 100, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0/0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.123

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.123

DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.14

DLCI = 105, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0

DLCI = 106, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0/0

DLCI = 107, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0

DLCI = 108, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0

DLCI = 109, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/0/0

Code:

R1# show frame-relay pvc 102

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0.123

input pkts 41 output pkts 54 in bytes 4615

out bytes 5491 dropped pkts 0 in pkts dropped 0

out pkts dropped 0 out bytes dropped 0

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 0 out DE pkts 0

out bcast pkts 27 out bcast bytes 1587

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

pvc create time 00:29:37, last time pvc status changed 00:13:47

Kết quả lệnh dưới đây xác nhận rằng đường truyền của R1 đang dùng Cisco LMI. Các thông điệp trạng thái LMI sẽ xuất hiện mỗi phút trong đó thông điệp Full Status message được liệt kê sau cùng. Chú ý rằng router gửi các thông điệp truy vấn trạng thái đến tổng đài. Khi tổng đài gửi các thông điệp trạng thái, các bộ đếm này sẽ cùng tăng.

Code:

R1# show frame-relay lmi

Invalid Unnumbered info 0 Invalid Prot Disc 0

Invalid dummy Call Ref 0 Invalid Msg Type 0

Invalid Status Message 0 Invalid Lock Shift 0

Invalid Information ID 0 Invalid Report IE Len 0

Invalid Report Request 0 Invalid Keep IE Len 0

Num Status Enq. Sent 183 Num Status msgs Rcvd 183

Num Update Status Rcvd 0 Num Status Timeouts 0

Last Full Status Req 00:00:35 Last Full Status Rcvd 00:00:35

Lệnh show interface liệt kê vài chi tiết, bao gồm các khoảng thời gian để gửi các thông điệp LMI, LMI stats, LMI DLCI và các trạng thái trong hàng đợi FR. Hàng đợi broadcast giữ các broadcast FR mà những broadcast này sẽ được nhân bản và gửi trên VC. Ví dụ như các OSPF LSAs.

Code:

R1# show int s 0/0/0

! lines omitted for brevity

Encapsulation FRAME-RELAY, loopback not set

Keepalive set (10 sec)

LMI enq sent 185, LMI stat recvd 185, LMI upd recvd 0, DTE LMI up

LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0

LMI DLCI 1023 LMI type is CISCO frame relay DTE

FR SVC disabled, LAPF state down

Broadcast queue 0/64, broadcasts sent/dropped 274/0, interface broadcasts 228

! Lines omitted for brevity

Code:

R3# sh frame lmi |include LMITYPE

R3# sh int s 0/0/0 | include LMI DLCI

LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE

Chú ý là R3 đang dùng kiểu ANSI LMI. R3 có thể cấu hình LMI tĩnh bằng câu lệnh frame-relay lmi-type {ansi | cisco | q933a} trong cổng vật lý. Tuy nhiên R3 đã bỏ qua lệnh này, làm cho R3 có hành động mặc định là tự động tìm ra loại LMI.

IP ARP được biết đến như một giao thức phổ thông và tương đối đơn giản. Đối với kỳ thi CCIE cũng vậy. Đa số các câu hỏi trong phần IP ARP là những câu hỏi đơn giản. Do đó, những câu hỏi khó về chủ đề xây dựng CEF adjacency table sẽ tập trung vào Frame Relay Inverse ARP, cũng chính vì vậy mà phương thức Frame Relay Inverse ARP sẽ được trình bày cụ thể và chi tiết hơn.

Tương tự như IP ARP, nhiệm vụ của InARP là phân giải giữa địa chỉ L3 và địa chỉ L2. Địa chỉ L3 chính là địa chỉ IP, còn địa chỉ L2 ở đây chính là số DLCI (tương tự như địa chỉ MAC trong IP ARP). Tuy nhiên, trong phương thức InARP, router đã biết được địa chỉ L2 (DLCI), và cần phân giải ra địa chỉ L3 (IP) tương ứng.

Hình sau là một ví dụ về chức năng của InARP.

Trong môi trường LAN, đòi hỏi phải có một gói tin (ARP request) đến host và kích hoạt giao thức IP ARP trên host (trả về ARP reply). Tuy nhiên , trong môi trường WAN, không cần một gói tin nào đến router để kích hoạt InARP trên router này, thay vào đó là một thông điệp về tình trạng LMI (Local Management Interface) sẽ được dùng.

Sau khi nhận được thông điệp trạng thái LMI là LMI PVC Up, router sẽ loan báo địa chỉ IP của nó ra mạch liên kết ảo (VC - Virtual Circuit) tương ứng thông qua thông điệp InARP (định nghĩa trong RFC1293). Như vậy, một khi LMI không được thực thi thì InARP cũng không hoạt động bởi vì không có thông điệp nào nói cho router biết để gửi thông điệp InARP.

Trong mạng Frame Relay, những cấu hình chi tiết được chon lựa với mục đích tránh một số tình trạng không mong muốn, những tình trạng này sẽ được mô tả chi tiết trong những trang kế tiếp của chương này. Ví dụ khi sử dụng point-to-point subinterface, với mỗi VC thuộc một subnet riêng, tất cả những vấn đề gặp phải trong cấu hình này sẽ được mô tả rõ ràng để có thể phòng tránh.

Bản thân giao thức InARP tương đối đơn giản. Tuy nhiên, khi triển khai InARP trên những mô hình mạng khác nhau, dựa trên những kiểu cổng khác nhau (cổng vật lý, cổng point-to-point subinterface và multipoint subinterface) thì cách thức hoạt động của InARP sẽ trở nên phức tạp hơn rất nhiều.

Sau đây là một ví dụ về hệ thống mạng Frame Relay được thiết kế theo mô hình mạng lưới không đầy đủ (partial mesh) trên cùng một subnet trong khi mỗi router sử dụng một kiểu cổng khác nhau.

Sơ đồ mạng trên chỉ mang tính chất là một ví dụ, nó chỉ sử dụng trong môi trường học tập để hiểu chi tiết hơn về cách thức hoạt động của InARP. Sơ đồ này không nên được áp dụng trong môi trường mạng thực tế bới thiết kế yếu kém với nhiều hạn chế khi triển khai giao thức định tuyến bên trên.

Thông tin của một số lệnh show và debug liên quan đến Frame Relay InARP và một trong số những điều kỳ quặc về InARP liên quan đến point-to-point subinterface được mô tả trong ví dụ 1.1.

Đầu tiên cấu hình frame relay trên cổng multipoint của R1.

Code:

Router1# sh run

interface Serial0/0

encapsulation frame-relay

interface Serial0/0.11 multipoint

ip address 172.31.134.1 255.255.255.0

frame-relay interface-dlci 300

frame-relay interface-dlci 400

! Lines omitted for brevity

Kế tiếp, cổng serial được tắt và bật và các hàng trong InARP trước đó bị xóa vì vậy ta có thể quan sát tiến trình InARP.

Code:

Enter configuration commands, one per line. End with CNTL/Z.

Router1(config)# int s 0/0

Router1(config-if)# do clear frame-relay inarp

Router1(config-if)# shut

Router1(config-if)# no shut

Router1(config-if)# ^Z

Các thông điệp từ lệnh debug frame-relay event hiển thị các thông điệp nhận được InARP trên R1. Chú ý các giá trị hex 0xAC1F8603 và 0xAC1F8604, với các giá trị thập phân tương ứng là 172.31.134.3 and 172.31.134.4 (tương ứng với Router3 và Router4).

Code:

Router1# debug frame-relay events

*Mar 1 00:09:45.334: datagramstart = 0x392BA0E, datagramsize = 34

*Mar 1 00:09:45.334: FR encap = 0x48C10300

*Mar 1 00:09:45.334: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00

*Mar 1 00:09:45.334: AC 1F 86 03 48 C1 AC 1F 86 01 01 02 00 00

*Mar 1 00:09:45.334:

*Mar 1 00:09:45.334: Serial0/0.11: FR ARP input

*Mar 1 00:09:45.334: datagramstart = 0x392B8CE, datagramsize = 34

*Mar 1 00:09:45.338: FR encap = 0x64010300

*Mar 1 00:09:45.338: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00

*Mar 1 00:09:45.338: AC 1F 86 04 64 01 AC 1F 86 01 01 02 00 00

Kế tiếp, chú ý lệnh show frame-relay map có bao gồm từ khóa dynamic, nghĩa là các hàng được học thông qua InARP.

Code:

Router1# show frame-relay map

broadcast, status defined, active

Serial0/0.11 (up): ip 172.31.134.4 dlci 400(0x190,0x6400), dynamic,

broadcast, status defined, active

Trên R3, lệnh show frame-relay map chỉ liệt kê một hàng duy nhất nhưng định dạng thì khác. Bởi vì R3 dùng point-to-point subinterface, hàng này không được học thông qua InARP và kết quả lệnh không bao gồm từ khóa Dynamic. Cũng chú ý là kết quả không cho thấy địa chỉ Layer 3 nào.

Code:

Serial0/0.3333 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast

status defined, active

Chú ý: Trong ví dụ trên ta thấy xuất hiện lệnh “do” trong chế độ cấu hình. Lệnh do cho phép cấu hình trong configuration mode nhưng để thực hiện chức năng ở exec mode mà không phải thoát khỏi mode configuration. Ví dụ lệnh do clear frame-relay inarp thực hiện ở configuration mode tương đương với việc ta thực hiện lệnh clear frame-relay inarp ở chế độ toàn cục.

Trong ví dụ trên, lệnh show cho thấy Router R1 đã nhận và sử dụng thông tin InARP; tuy nhiên Router R3 thì không sử dụng thông tin InARP đã nhận vào. Hệ điều hành Cisco IOS hiểu rằng chỉ một VC được thiết lập với một subinterface point-to-point; mỗi một địa chỉ IP đầu cuối khác trên cùng môt subnet chỉ có thể tham chiếu đến duy nhất một số DLCI. Vì vậy, mỗi thông tin InARP nhận được liên kết đến số DLCI đó là không cần thiết.

Lấy ví dụ, khi nào Router R3 cần gửi một gói tin đến Router R1(172.31.134.1), hay đến mỗi đầu cuối khác trong subnet 172.31.134.0/24. Từ chính cấu hình của mình, Router R3 biết rằng phải gửi qua số DLCI trên point-to-point subinterface đó, nghĩa là qua DLCI 100. Vì vậy, mặc dù cả ba kiểu cổng được dùng cho cấu hình Frame Relay hỗ trợ InARP một cách mặc định, point-to-point subinterface sẽ bỏ qua thông tin InARP nhận được.

Cấu hình ánh xạ địa chỉ tĩnh trong Frame Relay

Trong hình 1.3, R3 đã biết cách đẩy gói tin đến R4, nhưng ngược lại R4 chưa biết cách để đẩy gói tin ngược trở lại Router3. Theo ý nghiã logic R3 sẽ hiểu như sau “Để những gói tin đến được next-hop router trên subnet 172.31.124.0/24, R3 sẽ gửi chúng ra theo một số DLCI trên point-to-point subinterface, ở đây chính là DLCI 100 ”. Những gói tin này sẽ được chuyển đến R1 và nhờ R1 chuyển đến R4.

Trong cách thiết kế yếu kém trong hình 1.3, mặc dù R4 và R3 sử dụng hai kiểu cổng khác nhau, R3 sử dụng point-to-point subinterface trong khi R4 sử dụng cổng vật lý. Để đến được R3, R4 cần gửi frame qua DLCI 100 đến R1 và nhờ R1 chuyển tiếp đến R3. Trong trường hợp này InARP sẽ không giúp được gì, bởi vì thông điệp InARP chỉ cho phép qua một VC, mà không cho phép chuyển tiếp; một chú thích rằng không có VC nào tồn tại giữa R4 và R3.

Để giải quyết vấn đề này, trong cấu hình của R4 được thêm vào câu lệnh frame-relay map. Ví dụ 1.2 mô tả chi tiết thông tin trước và sau khi sử dụng lệnh frame-relay map.

Router 4 chỉ liệt kê một hàng trong lệnh show frame-relay map bởi vì Router4 chỉ có một VC duy nhất kết nối về Router1. Chỉ với một VC, Router 4 có thể học về một router khác thông qua InARP.

Code:

! lines omitted for brevity

interface Serial0/0

ip address 172.31.134.4 255.255.255.0

encapsulation frame-relay

Router4# show frame-relay map

Serial0/0 (up): ip 172.31.134.1 dlci 100(0x64,0x1840), dynamic,

broadcast,, status defined, active

! Next, proof that Router4 cannot send packets to Router3’s Frame Relay IP address.

Router4# ping 172.31.134.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.31.134.3, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Code:

Enter configuration commands, one per line. End with CNTL/Z.

Router4(config)# int s0/0

Router4(config-if)# frame-relay map ip 172.31.134.3 100 broadcast

Router4(config-if)# ^Z

Router4# ping 172.31.134.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.31.134.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms

Trong trường hợp khi bạn sử dụng mô hình như hình 1.3, bạn có thể sử dụng cấu hình ở trên. Một sự lựa chon khác là nếu như bạn sử dụng multipoint subinterface trên cả R3 và R4, cả hai router đều phải sử dụng câu lệnh frame-relay map, bởi vì cả hai router đều không thể nghe được thông điệp InARP từ router khác. Tuy nhiên, nếu cả hai router R3 và R4 đều sử dụng point-to-point subinterface, không router nào đòi hỏi phải có câu lệnh frame-relay map, bởi vì theo nghĩa logic cả hai router đều hiểu là: “dùng một VC của nó để đến tất cả các địa chỉ trong subnet”.

Trong hầu hết những mô hình mạng được đưa ra, việc sử dụng InARP là hợp lý. Tuy nhiên, ta có thể tắt InARP trên interface vật lý hay multipoint interface đi bằng cách sử dụng lệnh no frame-relay inverse-arp trên interface subcommand. Có thể ngừng hoạt động InARP trên tất cả các VC của interface/subinterface, tất cả các VC của interface/subinterface ứng với một giao thức L3 riêng biệt, hay đơn thuần là trên mỗi DLCI cụ thể.

Câu lệnh no frame-relay inverse-arp không chỉ làm cho router ngừng việc gửi thông điệp InARP ra ngoài, mà còn làm cho router không nhận thông điệp InARP. Lấy ví dụ, câu lệnh no frame-relay inverse-arp ip 400 ở mode subinterface trên Router R1 trong ví dụ 1.2 không chỉ ngăn R1 ngừng gửi thông điệp InARP ra DLCI400 tới R4 mà còn làm cho R1 bỏ đi thông điệp InARP đã nhận trên DLCI400.


(*) Interface point-to-point luôn luôn bỏ qua thông điệp InARP, bởi vì đối với point-to-point interface, chỉ dùng một số DLCI để gửi đến tất cả địa chỉ trong cùng một subnet
Bài 3:

SPANNING TREE PROTOCOL - STP


1. Tổng quan về IEEE 802.1D:

Một mạng mạnh mẽ được thiết kế không chỉ đem lại tính hiệu quả cho việc truyền các gói hoặc frame, mà còn phải xem xét làm thế nào để khôi phục hoạt động của mạng một cách nhanh chóng khi mạng xảy ra lỗi. Trong môi trường lớp 3, các giao thức định tuyến sử dụng con đường dự phòng đến mạng đích để khi con đường chính bị lỗi thì sẽ nhanh chóng tận dụng con đường thứ 2. Định tuyến lớp 3 cho phép nhiều con đường đến đích để giữ nguyên tình trạng hoạt động của mạng và cũng cho phép cân bằng tải qua nhiều con đường.

Trong môi trường lớp 2 (switching hoặc bridging), không sử dụng giao thức định tuyến và cũng không cho phép các con đường dự phòng, thay vì bridge cung cấp việc truyền dữ liệu giữa các mạng hoặc các port của switch. Giao thức Spanning Tree cung cấp liên kết dự phòng để mạng chuyển mạch lớp 2 có thể khôi phục từ lỗi mà không cần có sự can thiệp kịp thời. STP được định nghĩa trong chuẩn IEEE 802.1D.

1.1. Spanning Tree là gì và tại sao phải sử dụng nó?

Spanning Tree Protocol (STP) là một giao thức ngăn chặn sự lặp vòng, cho phép các bridge truyền thông với nhau để phát hiện vòng lặp vật lý trong mạng. Sau đó giao thức này sẽ định rõ một thuật toán mà bridge có thể tạo ra một topology luận lý chứa loop-free. Nói cách khác STP sẽ tạo một cấu trúc cây của free-loop gồm các lá và các nhánh nối toàn bộ mạng lớp 2.

Vòng lặp xảy ra trong mạng với nhiều nguyên nhân. Hầu hết các nguyên nhân thông thường là kết quả của việc cố gắng tính toán để cung cấp khả năng dự phòng, trong trường hợp này, một link hoặc switch bị hỏng, các link hoặc switch khác vẫn tiếp tục hoạt động, tuy nhiên các vòng lặp cũng có thể xảy ra do lỗi. Hình 3.1 biểu diễn một mạng switch điển hình và các vòng lặp cố ý được dùng để cung cấp khả năng dự phòng như thế nào.



Hai nguyên nhân chính gây ra sự lặp vòng tai hại trong mạng chuyển mạch là do broadcast và sự sai lệch của bảng bridge.

Broadcast Loop
Broadcast Loop và vòng lặp lớp 2 là một sự kết hợp nguy hiểm. Hình 3.2 biểu diễn broadcast tạo ra vòng lặp phản hồi (feedback loop).

Giả sử rằng, không có switch nào chạy STP:

DIXv2 Ethernet Frame chỉ chứa 2 địa chỉ MAC, một trường Type và một CRC. Trong IP header chứa trường time-to-live (TTL) được thiết lập tại host gốc và nó sẽ được giảm bớt mỗi khi qua một router. Gói sẽ bị loại bỏ nếu TTL = 0, điều này cho phép các router ngăn chặn các datagram bị “run-away”. Không giống như IP, Ethernet không có trường TTL, vì vậy sau khi một frame bắt đầu bị loop trong mạng thì nó vẫn tiếp tục cho đến khi ai đó ngắt một trong các bridge hoặc ngắt một kiên kết.

Trong một mạng phức tạp hơn mạng được mô tả trong hình 3.1, 3.2 thì có thể gây ra feedback loop rất nhanh theo tỉ lệ số mũ. Vì cứ mỗi frame tràn qua nhiều port của switch, thì tổng số frame tăng nhanh rất nhiều.

Ngoài ra cần phải chú ý đến broadcast storm trên các user của host A và B trong hình 3.2. Broadcast được xử lý bởi CPU trong tất cả các thiết bị trên mạng. Trong trường hợp này, các PC đều cố xử lý broadcast storm. Nếu ta ngắt kết nối một trong số các host từ LAN, thì nó hoạt động trở lại bình thường. Tuy nhiên, ngay khi ta kết nối nó trở lại LAN thì broadcast sẽ sử dụng 100% CPU. Nếu ta không xử lý điều này mà vẫn tiếp tục sử dụng mạng, thì sẽ tạo ra vòng lặp vật lý trong VLAN.

o Cat-2 chú ý rằng, nó chỉ nhận một frame trên port 1/2 với địa chỉ MAC là AA-AA-AA-AA-AA-AA. Nó thay đổi địa chỉ MAC của host A trong bảng bridge dẫn đến sai port.

Vì frame bị lặp theo hướng ngược lại, nên ta thấy địa chỉ MAC của host A bị lẫn giữa port 1/1 và 1/2. Điều này không chỉ làm mạng bị tràn với các gói unicast mà còn sửa sai bảng bridge. Như vậy không chỉ có broadcast mới làm hư hại mạng.