В чем разница между коммутаторами Layer 2 и Layer 3?

Рассматриваем особенности работы и отличия коммутаторов Layer-2 и Layer-3

March 15, 2013, 5 p.m. | 4210

Коммутатор уровня 2 (Layer2 или L2) предназначен для соединения нескольких устройств локальной вычислительной сети (LAN) или нескольких сегментов данной сети. Коммутатор уровня 2 обрабатывает и регистрирует МАС–адреса поступающих фреймов, осуществляет физическую адресацию и управления потоком данных (VLAN, мультикаст фильтрация, QoS).

Коммутаторы уровня 3 (Layer 3 илиL3) фактически являются маршрутизаторами, которые реализуют механизмы маршрутизации (логическая адресация и выбор пути доставки данных (маршрута) с использованием протоколов маршрутизации (RIP v.1 и v.2, OSPF, BGP, проприетарные протоколы маршрутизации и др.)) не в программном обеспечении устройства, а с помощью специализированных аппаратных средств (микросхем). В результате устройство становиться менее гибким, поскольку для модернизации средств реализации применяемых протоколов маршрутизации требуется замена аппаратного обеспечения, а не просто обновление программного обеспечения. Примером может служить устройства, в которых поддержка различных протоколов маршрутизации осуществляется в разных моделях. Традиционно коммутаторы уровня 3 (L3) использовались в локальных и территориальных сетях для обеспечения быстродействующей передачи данных в интересах большого количества подключенных к ним устройств в отличии от маршрутизаторов, традиционно осуществляющих низкоскоростной доступ к распределенной сети (WAN). Как правило, сегодня маршрутизаторы применяются при организации внешней связи энергообъекта совместно с мультиплексорами (MUX) с другими энергообъектами, центрами управления сетями (ЦУС) и диспетчерскими центрами (ДЦ).

Latest blog posts

Transmission of data structures in a GOOSE message
Transmission of data structures in a GOOSE message

GOOSE-messaging has been covered a lot in many technical papers and to add anything valuable to the subject is rather difficult. But we will try. And functional constrained data will help us with that.

Quality Assurance requirements and experiences for GOOSE/SV configuration

The paper describes our experiences in applying quality assurance principles during the off-line SCL engineering phase independent of the engineering tool or Excel files used. These principles include requirements for inspection, visualisation and detailed analysis of the configuration of the GOOSE and SV communication all directly from the SCL files. The results of these processes are presented in regards to optimised data flow, identification of unpublished or unsubscribed GOOSE/SV, restriction of use of generic Logical Nodes and generic signal names ensuring better overall performance and reliability.

Software Based Centralized Protection: commissioning experience
Software Based Centralized Protection: commissioning experience

In 2018 Tekvel signed several contracts to commission centralized protection system based on servers and independent software. In this article we would like to share our experience and discuss some of the problems, that might require special attention from utilities on the way to mass deployment of centralized PAC systems.