Різниця між списком доступу та списком префіксів?


21

Чи може хтось пояснити на прикладі, яка різниця між списком доступу та списком префіксів.

Відповіді:


25

Ось історія того, як вони виникли (і чому вони такі, якими вони є):

  • У перші дні Інтернету люди почали просити фільтри пакетів (ака. Списки доступу).
  • Cisco спершу запровадив прості списки доступу (фільтрація за адресами хостів призначення, доповнені масками підстановки), але, звичайно, вони були недостатньо хорошими для блокування (наприклад) SMTP, тому вони створили розширені списки доступу, які можуть відповідати джерелам та пунктам призначення IP-адреси (з бітковими кодами на обох - ці біти дозволяють вам зіставляти цілі префікси), протоколи, номери портів ...

Отже: список доступу = пакетний фільтр.

Пізніше (але все ще десятиліття тому) люди почали запускати кілька протоколів маршрутизації в одне поле і хотіли перерозподілити інформацію між ними. Не проблема, але ви б не хотіли ВСІХ інформації, яку ви поширили в інший протокол маршрутизації - вам потрібні ФІЛЬТРИ МАРШЕТУ. Як завжди, все виглядає як цвях, якщо у вас трапляється молот, і тому інженери Cisco реалізували маршрутні фільтри з об'єктом, який вони вже мали - списки доступу.

На даний момент: список доступу = фільтр пакетів (а іноді і фільтр маршрутів)

З появою безкласової маршрутизації (так, це вже давно - чи пам'ятає хтось ще дні класів A, класу B та класу C), люди хотіли перерозподілити префікси певного розміру між протоколами маршрутизації. Наприклад: рекламуйте всі / 24 з OSPF в BGP, але не / 32. Неможливо зробити зі списками доступу. Час нового помилки: давайте скористаємося розширеним списком доступу та зробимо вигляд, що вихідна IP-адреса в фільтрі пакетів представляє мережеву адресу (фактично префіксну адресу), а адреса призначення в тому ж рядку фільтра пакетів представляє маску підмережі.

Це далеко: списки доступу = фільтри пакетів. Прості списки доступу також виконують роль фільтрів маршрутів (збігаються лише за мережевими адресами), а розширені списки доступу служать фільтрами маршрутів, що відповідають адресам та маскам підмережі.

На щастя, хтось тоді захопив розум розуму і почав цікавитись, який саме геніальний розум, який вирішив повторно використовувати розширені ACL для маршрутних фільтрів, має сенс курити, коли їм приснилася ця геніальна ідея.

Кінцевий результат: Cisco IOS отримав списки префіксів, які (майже) ідентичні за функціоналом спискам розширеного доступу, що діють як маршрутні фільтри, але відображаються у форматі, який звичайна людина має шанс зрозуміти.

Сьогодні: використовуйте списки доступу для фільтрів пакетів та списки префіксів для фільтрів маршрутів. Ви все ще можете використовувати списки доступу як фільтри маршрутів, але цього не робите .

Має сенс?


"Наприклад: рекламуйте всі / 24 з OSPF в BGP, але не / 32s. Не можна робити зі списками доступу" - не неможливо, але нудно
MiniMe

Неможливо зробити зі стандартними списками доступу, якщо ви дійсно хочете співставити маску підмережі. Так, ви можете зробити вигляд, що відповідність нульовому вузлу поля однакова;)
ioshints

10

Не цілу партію.

Вони обидва надають засоби для фільтрації за мережевими адресами, але є кілька ключових відмінностей:

  • Розширені ACL можуть фільтрувати на основі інформації "вищого рівня", тобто TCP / UDP-порту. Список префіксів не може.
  • Розширені / стандартні ACL можуть використовувати маски підстановки, які дозволяють задавати довільні адреси або діапазони адрес. Списки префіксів не можуть цього зробити.
  • Списки префіксів можуть збігатися за довжиною префікса - мінімальною або максимальною довжиною відповідно до ключових слів "ge" та "le".

Для політики маршрутизації люди, як правило, віддають перевагу використанню списків префіксів, оскільки деякі вважають, що вони більш "виразні", але не дуже багато обмежує вас в тому, щоб використовувати те чи інше - це буде залежати від ситуації / вимог.


2
Списки префіксів часто зустрічаються при вхідній та вихідній фільтрах BGP, наприклад, заперечення будь-яких отриманих префіксів, що є ge / 24, або створення списку локальних префіксів AS, які будуть рекламовані (щоб не рекламувати більше, ніж слід, і стати транзитом ).
загальна мережева оператор

6

Список префіксів використовується для фільтрування маршрутів та перерозподілу маршруту, оскільки він відповідає префіксам, що надсилаються, отримуються або присутні в таблиці маршрутизації або таблиці BGP. Вони співпадають по бітах у префіксі, але також і по довжині префікса. ACL можна використовувати для набагато більше функцій, таких як: фільтрація трафіку, узгодження трафіку для QoS, відповідність трафіку для NAT, VPN, маршрутизація на основі політики тощо. Вони також можуть використовуватися для маршрутних фільтрів та перерозподілу, але їх синтаксиси відрізняються від коли вони використовуються для інших цілей.


2

На додаток до того, що сказав Джон Дженсен, я додам, що ACL також використовуються в цілях безпеки (наприклад, обмеження віддаленого доступу), тоді як список префіксів не може мати цю функцію самостійно.

Списки префіксів дотримуються L3, тоді як ACL може йти на один шар вгору, приносячи додаткову функціональність.

Для візуального порівняння дивіться це посилання: http://mellowd.co.uk/ccie/?p=447


0

Списки префіксів працюють аналогічно спискам доступу; список префіксів містить один або більше упорядкованих записів, які обробляються послідовно.


Привіт і дякую за вашу відповідь. Чи мали намір додати дві різні відповіді? Хоча обмін стеками не проти двох різних відповідей на одне і те ж питання, більшість людей відповідають лише одним. Якщо ви дійсно мали намір це змінити оригінальну відповідь, скопіюйте цей текст і відредагуйте його у своїй іншій відповіді . Потім видаліть цю відповідь.
Майк Пеннінгтон

-2

Списки префіксів використовуються для вказівки адреси або діапазону адреси, яку можна дозволити або заборонити в оновленнях маршруту ...


-3

Список доступу призначений для фільтрації трафіку, а список префіксів - для фільтрації маршрутів

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.