IP network optimization by software defined networks


Cite item

Full Text

Abstract

Nowadays IP network optimization is one of the main priorities of service provider, and here Software Defined Networks (SDN) integration together with corporate network infrastructure is a very promising approach. This work is concerned with a problem of ARP protocol using under 2nd layer IP network operation and optimization of those networks by solutions based on SDNs. We demonstrated ability of ARP server integration under particular network infrastructure based on SDN. This ARP server may to reduce risks of ARP message spoofing, and therefore it improves network infrastructure security and fault tolerance. Optimization of broadcast messages mailing also affects to access control and segmentation over one broadcast domain. It is an additional tool for network management. In addition, we considered a positive trend of ARP server using with SDN solutions.

Full Text

Введение С постоянным ростом объемов передаваемого трафика в сети провайдера оптимизация инфраструктуры сети имеет важное значение. Зачастую, при наличии всех необходимых ресурсов сеть не может обеспечить должную функциональность и отказоустойчивость. Даже небольшая сеть, имеющая выход в глобальную сеть с точки зрения эксплуатации и выявления проблем может представлять весьма серьезные задачи. На данный момент реализация программно-конфигурируемые сетей на определенных уровнях сети может способствовать существенной оптимизации сетевой инфраструктуры и обеспечить более рациональное использование сетевых возможностей. Одной из важных характеристик сети является использование ARP протокола. При наличии даже небольшой сетевой инфраструктуры чрезмерное количество ARP запросов может отрицательно влиять на производительность сети, к тому же ARP является одним из слабых мест с точки зрения организации безопасности сети и использования различных механизмов может привести к утечке информации или выходу из строя отдельного сетевого элемента или целой сети. При росте количества ARP запросов в определенном сегменте сети дополнительно будет увеличиваться и нагрузка на активные сетевые элементы, обрабатывающие данные запросы. Что так же скажется весьма отрицательно на качество работы сетевой инфраструктуры. Протокол определения адреса (ARP) Протокол ARP (Address Resolution Protocol) предназначен для взаимодействия уровня 2 с уровнем 3. Существуют следующие типы сообщений ARP: запрос ARP (ARP request) и ответ ARP (ARP reply). Отправитель при помощи запроса ARP запрашивает физический адрес получателя, в свою очередь ответ от получателя приходит в виде ответа ARP. В случае IP сети ARP протокол позволяет определить MAC адрес устройства по известному IP адресу. Все элементы сети, прослушивающие сообщения ARP должны обрабатывать данные пакеты со своей стороны, что приводит к дополнительной нагрузке на производительность оборудования. Описание протокола было опубликовано в ноябре 1982 года в рекомендации IETF - RFC 826 [3]. Пример распространения широковещательного запроса в пределах одного широковещательного домена показан на рис. 1. Широковещательный ARP запрос генерируется сетевым элементом с IP адресом 10.0.0.1, т.к. ему требуется определить MAC адрес, принадлежащий сетевому элементу 10.0.0.2. В свою очередь ARP запрос представляет пакет с указанным MAC адресом назначения FFFF:FFFF:FFFF, который характеризует данный ARP запрос как широковещательный. Данный пакет поступая на сетевой элемент SW4 будет принят коммутатором и разослан во все порты, кроме того из которого поступил. Соответственно, количество широковещательных запросов будет соответствовать количеству активных сетевых соединений между активным оборудованием: , где (broadcast paket) - количество широковещательных запросов; (Ethernet Link) - количество активных сетевых соединений. В данном случае число широковещательных запросов, инициированных с одного сетевого элемента, составляет 7 шт. При росте количества сетевых элементов и возрастанию активных сетевых соединений, будет расти и число широковещательных запросов. Процентное соотношение широковещательного трафика от всего остального в рамках одного домена может составлять 12-15% от общего количества трафика. ARP в программно-конфигурируемых сетях Одной из основных задач SDN сети является отделение служебного трафика от пользовательского. Под служебным трафиком понимается вся активная пакетная нагрузка, используемая для обслуживания сетевых протоколов в рамках конкретной сетевой инфраструктуры. В качестве пользовательского трафика выступает пакетная нагрузка, инициированная конкретным пользователем. В рамках использования SDN основным отличием от традиционной сети является тот факт, что контроллер самостоятельно отправляет ARP ответ активным сетевым устройствам, направившим ARP запрос. Соответственно, при рассмотрении использования подхода SDN совместно с определенной сетевой инфраструктурой применение протокола ARP остается актуальным. Схема распространения ARP запросов в SDN сети показана на рис. 2. Рис. 1. Пример распространения ARP запроса без участия SDN решений Соответственно, широковещательный ARP запрос генерируется сетевым элементом с IP адресом 10.0.0.1 с задачей найти определить MAC адрес, принадлежащий сетевому элементу 10.0.0.2. В свою очередь, аналогично распространению в сети без SDN - ARP запрос представляет пакет с указанным MAC адресом назначения FFFF:FFFF:FFFF, который и характеризует данный ARP запрос как широковещательный. Далее пакет поступает на коммутатор OVS S1, который в свою очередь данный запрос направляет к контроллеру SDN. Далее SDN контроллер определяет соответствие IP и MAC адресов и формирует ARP ответ с указанным MAC адресом сетевого элемента 10.0.0.2. Затем контроллер направляет ARP ответ на коммутатор OVS S1, а тот в свою очередь пересылает на сетевой элемент 10.0.0.1. После данной процедуры сетевой элемент 10.0.0.1 запоминает в собственной ARP таблице MAC адрес сетевого элемента 10.0.0.2 и может формировать пакеты уже непосредственно до сетевого элемента 10.0.0.2. Для повышения контроля за ARP запросами, локализации избыточных запросов, повышения качества и надежности сети возможно использование ARP сервера в рамках сетевой инфраструктуры. Использование ARP-сервера подразумевает интеграцию в сеть сервера с постоянно обновляющейся базой данных по IP ARP TABLE, собираемой со всех активных устройств в сети. Использование данного сервера позволит: - полностью контролировать количество ARP запросов со всех сетевых устройств, в рамках одного сетвого элемента (ARP сервера); - ARP запросов со всех сетевых устройств, в рамках одного сетевого элемента (ARP сервера); - обеспечить выявление лишних или отсутствие обязательных ARP записей в IP ARP TABLE, что существенно повысит надежность и безопасность сетевой инфраструктуры; - записывать и хранить все процессы, касающиеся появлению и активности всех ARP запросов в конкретной сетевой инфраструктуре. Обеспечить ограничение и расширение прав в доступе для конкретных сетевых узлов. Сегментировать IP ARP TABLE, тем самым разделяя один широковещательный домен на требуемое количество. Рис. 2. Схема распространения ARP запроса в пределах SDN сети На рис. 3 представлена схема распространения ARP запроса в пределах SDN сети с использованием ARP сервера. По аналогии со схемой распространения ARP запросов в пределах SDN сети, ARP запрос генерируется сетевым элементом 10.0.0.1 и отправляет данный запрос на коммутатор OVS S1. Таким образом, основной задачей при использовании ARP сервера заключается необходимости, при поступлении на любой из коммутаторов SDN пакета с Ethertype=0x0806, подменить в пакете поле Destination MAC на MAC адрес ARP сервера. Далее данный пакет преобразуется в однонаправленный (unicast) и уже с измененным полем Destination MAC поступает на ARP сервер. ARP сервер проверяет соответствие в локальной IP ARP TABLE и отправляет ARP ответ на сетевой элемент 10.0.0.1. После этого сетевой элемент 10.0.0.1 запоминает в собственной ARP таблице MAC адрес сетевого элемента 10.0.0.2 и может формировать пакеты уже непосредственно до сетевого элемента 10.0.0.2. При условии того, что в базе ARP сервера отсутствуют запрашиваемые данные, то поле Source MAC в ARP можно заполнить любым сетевым MAC адресом, вследствие чего, можно создать отдельное хранилище для не найденных запросов. Тем самым обезопасить и разгрузить сетевую инфраструктуру отсутствием лишних широковещательных пакетов и найти источник, по изученным сетевым атрибутам данных запросов. Алгоритм управления ARP запросами с использованием ARP сервера в SDN сети представлен на рис. 4. Рис. 3. Схема распространения ARP запроса в пределах SDN сети с использованием ARP сервера Таким образом использование ARP сервера может существенно уменьшить количество «лишних» ARP запросов в сети. Использование SDN в определенном сегменте сетевой инфраструктуры может существенно снизить нагрузку, как на активное сетевое оборудование, так и на каналы связи существенным снижением количества широковещательных запросов. Также при использовании данной концепции существенно снизится вероятность подмены MAC адреса на сети с точки зрения сетевой безопасности. Заключение Использование ARP сервера возможно, как в рамках SDN сети, так и без участия SDN решений. К основным примерам реализации инфраструктуры с использованием ARP сервера в SDN сети относятся: - реализации закрытого ведомственного сегмента сети, с заранее известным количеством сетевых элементов. Тем самым использование ARP сервера может положительно сказаться на организации безопасности внутри сетевой инфраструктуры, а именно, обнаружением и выявлением «лишних» сетевых элементов, полным контролем внутрисетевого трафика в пределах одного широковещательного домена; Рис. 4. Алгоритм управления ARP запросами с использованием ARP сервера в SDN сети - использование ARP сервера в рамках сети FTTB. С точки зрения использования SDN на сети провайдера связи для реализации широкополосного доступа существует ряд плюсов: - отсутствие в необходимости локальной настройки активного сетевого оборудования, используемого в рамках реализации сети. Всю настройку сети необходимо будет проводить локально через SDN контроллер. Тем самым возможно существенное снижение затрат на эксплуатацию сетевой инфраструктуры; - возможность интеграции абонентских устройств с фиксированными MAC адресами. При реализации ARP сервера и так же при условии того, что у абонентов будут реализованы устройства провайдера связи с фиксированной МАC-адресацией, возможен перевод ряда функционала с AAA/Radius серверов на ARP сервер. В данном случае, при заранее известной MAC адресации у клиента и при дополнительной реализации функционала PORT SECURITY на активном сетевом оборудовании уровня доступа возможен полный контроль доступа ШПД абонента. Так же при реализации взаимодействия ARP сервера с системой биллинга провайдера связи, возможно, полностью отказаться от использования AAA/Radius серверов и функционал контроля доступа абонентов будет полностью выполнять ARP сервер.
×

About the authors

Evgeny Sergeevich Semenov

Volgograd State University

Email: essemenov@mail.ru

Mikhail Sergeevich Deogenov

Volgograd State University

Email: deogenov.ms@gmail.com

Sergey Vladimirovich Galich

Volgograd State University

Email: sergeygali4@gmail.com

Dmitry Alexandrovich Tyukhtyaev

Volgograd State University

Email: tyukhtyaevml@mail.ru

Alexey Olegovich Pasuk

Volgograd State University

Email: alexey_pas@rambler.ru

References

  1. H. Kim, N. Feamster. Improiving Network Management with Software Defined Networking IEEE Network Magazine, 51(2), Feb. 2013 //http://www.cc.gatech.edu/~hkim368/publication/SDN_ieeemagazine_Kim.pdf (д.о. 22.06.2015).
  2. N. Feamster et al. The Case for Separating Routing from Routers,” ACM SIGCOMM Wksp. Future Directions in Network Architecture, Portland, OR, Sept. 2004 //https://www.cs. princeton.edu/~jrex/papers/rcp.pdf (д.о. 19.06.2015).
  3. IP Addressing: ARP Configuration Guide, Cisco IOS Release 15M&T // [http://www.cisco.com/ c/en/us/td/docs/ios-xml/ios/ipaddrarp/ configuration /15-mt/arp-15-mt-book.pdf (д.о. 02.06.2015).
  4. R. Chua. SDN and NFV Market Size Report and Forecast Predicts $105B Impact by 2020 //https://www.sdxcentral.com/articles/announcements/nfv-sdn-market-sizing-forecast-report-2015-download/2015/05/ (д.о. 30.06.2015).
  5. X. Pan, W. Sun. Internet-Draft Address Resolution Delay in SDN // https://tools.ietf.org/html/draft-pan-ippm-sdn-addr-resolv-perf-00 (д.о. 30.06.2015).
  6. OpenFlow Swtich Specification, Version 1.1.0 Implemented // www.archive.openflow.org/ documents/openflow-wp-latest.pdf (д.о. 12.06.2015).
  7. The OpenFlow Switch Specification // http://OpenFlowSwitch.org (д.о. 03.07.2015).
  8. NetFGPA: Programmable Networking Hardware // http://netfpga.org (д.о. 24.06.2015).
  9. Global Environment for Network Innovations // http://geno.net (д.о. 12.06.2015).
  10. OpenFlow white paper // www.archive. openflow.org/documents/openflow-wp-latest.pdf (д. о. 27.05.2015).

Supplementary files

Supplementary Files
Action
1. JATS XML

Copyright (c) 2015 Semenov E.S., Deogenov M.S., Galich S.V., Tyukhtyaev D.A., Pasuk A.O.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

This website uses cookies

You consent to our cookies if you continue to use our website.

About Cookies