Wykrywanie różnych ramek Ethernet


12

Jak ktoś może rozróżnić różne pakiety w protokole Ethernet? Nie ma pola / obszaru „długości”, ponieważ używają tego protokoły wyższego poziomu.

Ponieważ ten protokół obsługuje zarówno zakresy fizyczne, jak i logiczne, zakładam, że rozróżnienie również jest oddzielone.

Czy separacja logiczna jest wykonywana przy użyciu pola protokołu „EtherType”? (tj. uzyskanie długości pakietu przy użyciu typu protokołu wyższego poziomu, który ma pole długości w nagłówkach).

Czy fizycznym rozróżnieniem jest po prostu brak transmisji sygnałów elektrycznych? (Według mojej wiedzy, wysokie / niskie sygnały elektryczne reprezentują bity 0/1).

Odpowiedzi:


14

Chociaż Ytti odpowiedział, istnieje kilka istotnych szczegółów, które mogą Cię zainteresować ...

Jak ktoś może rozróżnić różne pakiety w protokole Ethernet? Nie ma pola / obszaru „długości”, ponieważ używają tego protokoły wyższego poziomu.

W rzeczywistości sieć Ethernet ma wiele enkapsulacji:

  • Ethernet II (Zwykle używany do IP, jak określono w [RFC 894], jest najczęstszym enkapsulacją): Nie ma pola długości , zamiast tego używane jest pole typu ...
       +----+----+------+------+-----+
       | DA | SA | Type | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)
  • 802.2 LLC Ethernet: ma pole długości
       +----+----+------+------+------+------+-----+
       | DA | SA | Len  | LLC  | SNAP | Data | FCS |
       +----+----+------+------+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
       LLC     802.2 LLC Header        (3 bytes)
       SNAP                            (5 bytes)
       Data    Protocol Data           (46 - 1492 bytes)
       FCS     Frame Checksum          (4 bytes)

Niezależnie od istnienia pola długości 802.2, zawsze możesz wykryć koniec ramki ethernetowej na przewodzie, szukając 96-bitowej przerwy między ramkami .

Czy separacja logiczna jest wykonywana przy użyciu pola protokołu „EtherType”? (tj. uzyskanie długości pakietu przy użyciu typu protokołu wyższego poziomu, który ma pole długości w nagłówkach).

Przez logiczną separację zakładam, że masz na myśli separację między różnymi protokołami przenoszonymi wewnątrz Ethernetu, na przykład rozróżnianie IPv4, IPv6 lub być może ramek drzewa opinającego.

Czy fizycznym rozróżnieniem jest po prostu brak transmisji sygnałów elektrycznych? (Według mojej wiedzy wysokie / niskie sygnały elektryczne reprezentują bity 0/1)

Upraszczając, tak, istnieje 96-bitowa przerwa między ramkami Ethernet; należy jednak pamiętać, że sieć Ethernet używa kodowania 8b / 10b (FastEthernet) i 64b / 66b (GigabitEthernet), więc technicznie nie jest poprawne powiedzenie „brak transmisji sygnałów elektrycznych”, ponieważ 8b / 10b nie ma „ stan cichy.


Dla ciekawskich łączę się również z oryginalną specyfikacją Ethernet w wersji 2 .


7

Ethernet ma preambułę i ogranicznik początkowej ramki na początku, a na końcu ma „IFG” lub przerwę między ramkami. Służą one do określenia początku i końca ramki.


Czy jest to oddzielenie w zakresie fizycznym czy logicznym? Co jednak, jeśli pole danych protokołu będzie zawierało informacje / znaki / sygnały, które są takie same dla ograniczników początkowych / końcowych?
Refleksja

1
Luka jest dosłownie taka, że ​​nie ma ryzyka znalezienia jej w ładowności. Jednak w niektórych innych, nie ethernetowych kontekstach jest to problem i można to naprawić, upewniając się, że niektóre symbole nigdy nie są używane do kodowania danych, ale tylko do sygnalizowania, jednak zmniejszyłoby to wydajność marnowania niektórych symboli na „nieprzydatne” dane.
ytti
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.