BGP - запрещаем прием дефолта

  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '2:e8aef290131bdca68501e8cf0a30f336' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p class=\"rtejustify\">Довольно часто, если уж используется <strong>BGP</strong>, имеем в наличии несколько аплинков. И&nbsp;уже в зависимости от топологии сети строим маршрутизацию.</p>\n<p class=\"rtejustify\">Как в таком случае поступать с дефолтом? Оптимальное решение всегда будет зависеть от той же топологии. Довольно часто также возникает необходимость в запрете приема дефолта от какого-то из нейборов. Кстати,&nbsp;к написанию статьи подтолкнула ситуация,&nbsp;возникшая вследствии того, что на роутере моей локалки,&nbsp;прием дефолта не фильтровался. И в один прекрасный момент один из нейборов прислал на этот роутер маршрут к этой самой <strong>0.0.0.0/0</strong>.&nbsp;А поскольку я дефолт как раз и получал по <strong>BGP </strong>(правда от нейбора с меньшим <strong>Weight</strong>), то в результате дефолт перенаправился на другого нейбора (что есть не очень хорошо,&nbsp;в моем случае).</p>\n<p class=\"rtejustify\">Итак,&nbsp;пора заняться фильтрацией дефолта, чтобы избежать подобных ситуаций в будущем. Согласно таблицы маршрутизации,&nbsp;дефолт сейчас приходит по&nbsp;<strong>BGP&nbsp;</strong>от <strong>192.168.157.85</strong>:</p>\n<table border=\"1\" cellspacing=\"1\" cellpadding=\"1\" width=\"100%\">\n<tbody>\n<tr>\n<td>\n<div>router# <strong>show ip route<br />\n </strong>Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,<br />\n &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I - ISIS, B - BGP, &gt; - selected route, * - FIB route</div>\n<div>&nbsp;</div>\n<p> B&gt;* 0.0.0.0/0 [20/0] via 192.168.157.85, vlan684, 01:52:18</p></td>\n</tr>\n</tbody>\n</table>\n<p class=\"rtejustify\">Для сравнения пропишем дефолт еще и&nbsp;статическим маршрутом на этот же IP:</p>\n<table border=\"1\" cellspacing=\"1\" cellpadding=\"1\" width=\"100%\">\n<tbody>\n<tr>\n<td>router(config)# ip route 0.0.0.0/0 192.168.157.85</td>\n</tr>\n</tbody>\n</table>\n<p class=\"rtejustify\">Проверяем:</p>\n<table border=\"1\" cellspacing=\"1\" cellpadding=\"1\" width=\"100%\">\n<tbody>\n<tr>\n<td>\n<div>router# <strong>show ip route<br />\n </strong>Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,<br />\n &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I - ISIS, B - BGP, &gt; - selected route, * - FIB route</div>\n<div>&nbsp;</div>\n<div class=\"rtejustify\">S&gt;* 0.0.0.0/0 [1/0] via 192.168.157.85, vlan684<br />\n B&nbsp;&nbsp; 0.0.0.0/0 [20/0] via 192.168.157.85, vlan684, 02:01:17</div>\n</td>\n</tr>\n</tbody>\n</table>\n<p class=\"rtejustify\">А теперь уже можно играться с запрещением дефолта по BGP. Создаем префикс-лист с названием <strong>DENY-DEFAULT-IN</strong>:</p>\n<p class=\"rtejustify\">\n<table border=\"1\" cellspacing=\"1\" cellpadding=\"1\" width=\"100%\">\n<tbody>\n<tr>\n<td>router(config)# <strong>ip prefix-list DENY-DEFAULT-IN seq 5 deny 0.0.0.0/0 le 1</strong><br />\n router(config)# <strong>ip prefix-list DENY-DEFAULT-IN seq 10 permit 0.0.0.0/0 ge 2</strong></td>\n</tr>\n</tbody>\n</table>\n</p>\n<p>Теперь применим этот фильтр к нейбору,&nbsp;от которого нет необходимости получать дефолт:</p>\n<p><table border=\"1\" cellspacing=\"1\" cellpadding=\"1\" width=\"100%\">\n<tbody>\n<tr>\n<td>router(config-router)# <strong>neighbor 192.168.157.85 prefix-list DENY-DEFAULT-IN in</strong></td>\n</tr>\n</tbody>\n</table>\n</p>\n<p>Обновляем список принимаемых от <strong>192.168.157.85</strong> префиксов:</p>\n<p><table border=\"1\" cellspacing=\"1\" cellpadding=\"1\" width=\"100%\">\n<tbody>\n<tr>\n<td>router# <strong>clear ip bgp 192.168.157.85 soft in</strong></td>\n</tr>\n</tbody>\n</table>\n</p>\n<p>Проверяем:</p>\n<p><table border=\"1\" cellspacing=\"1\" cellpadding=\"1\" width=\"100%\">\n<tbody>\n<tr>\n<td>\n<div>router0-zebra#<strong> show ip route<br />\n </strong>Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,<br />\n &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I - ISIS, B - BGP, &gt; - selected route, * - FIB route</div>\n<div>&nbsp;</div>\n<div>S&gt;* 0.0.0.0/0 [1/0] via 192.168.157.85, vlan684</div>\n</td>\n</tr>\n</tbody>\n</table>\n</p>\n<p class=\"rtejustify\">Вуаля. Имеем в наличии только статически прописанный дефолт. По <strong>BGP</strong> он уже&nbsp;не приходит. Теперь дело за малым - применить префикс-лист <strong>DENY-DEFAULT-IN</strong> к определенным нейборам. А в моем случае еще и убрать этот префикс-лист с нейбора <strong>192.168.157.85</strong> (поскольку на момент тестирования дефолт приходил только от него) и статический маршрут, созданный в начале статьи.</p>\n<p class=\"rtejustify\">&nbsp;</p>\n', created = 1767395959, expire = 1767482359, headers = '', serialized = 0 WHERE cid = '2:e8aef290131bdca68501e8cf0a30f336' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 112.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '2:07243fc0252056071eaa62af8c18d662' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p class=\"rtecenter\"><a class=\"thickbox\" href=\"/files/imagepicker/1/wake_up_ua.png\"><img alt=\"Вставай, Україно!\" class=\"imgp_img\" src=\"/files/imagepicker/1/thumbs/wake_up_ua.png\" style=\"height:200px; width:150px\" /></a></p>\n', created = 1767395959, expire = 1767482359, headers = '', serialized = 0 WHERE cid = '2:07243fc0252056071eaa62af8c18d662' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 112.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '3:cc913d232116f0426090404133377d88' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '2:d9a86123bfcbc57878743027b584400b' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p class=\"rtecenter\"><a href=\"http://muff.kiev.ua/rss.xml\"><img alt=\"RSS\" width=\"160\" height=\"60\" src=\"http://muff.kiev.ua/files/muf-rss.png\" /></a></p>\n', created = 1767395959, expire = 1767482359, headers = '', serialized = 0 WHERE cid = '2:d9a86123bfcbc57878743027b584400b' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 112.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '3:39649256b636e3d5ded656bc52bd8c01' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
Версия для печатиОтправить другуPDF version

Довольно часто, если уж используется BGP, имеем в наличии несколько аплинков. И уже в зависимости от топологии сети строим маршрутизацию.

Как в таком случае поступать с дефолтом? Оптимальное решение всегда будет зависеть от той же топологии. Довольно часто также возникает необходимость в запрете приема дефолта от какого-то из нейборов. Кстати, к написанию статьи подтолкнула ситуация, возникшая вследствии того, что на роутере моей локалки, прием дефолта не фильтровался. И в один прекрасный момент один из нейборов прислал на этот роутер маршрут к этой самой 0.0.0.0/0. А поскольку я дефолт как раз и получал по BGP (правда от нейбора с меньшим Weight), то в результате дефолт перенаправился на другого нейбора (что есть не очень хорошо, в моем случае).

Итак, пора заняться фильтрацией дефолта, чтобы избежать подобных ситуаций в будущем. Согласно таблицы маршрутизации, дефолт сейчас приходит по BGP от 192.168.157.85:

router# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route
 

B>* 0.0.0.0/0 [20/0] via 192.168.157.85, vlan684, 01:52:18

Для сравнения пропишем дефолт еще и статическим маршрутом на этот же IP:

router(config)# ip route 0.0.0.0/0 192.168.157.85

Проверяем:

router# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route
 
S>* 0.0.0.0/0 [1/0] via 192.168.157.85, vlan684
B   0.0.0.0/0 [20/0] via 192.168.157.85, vlan684, 02:01:17

А теперь уже можно играться с запрещением дефолта по BGP. Создаем префикс-лист с названием DENY-DEFAULT-IN:

router(config)# ip prefix-list DENY-DEFAULT-IN seq 5 deny 0.0.0.0/0 le 1
router(config)# ip prefix-list DENY-DEFAULT-IN seq 10 permit 0.0.0.0/0 ge 2

Теперь применим этот фильтр к нейбору, от которого нет необходимости получать дефолт:

router(config-router)# neighbor 192.168.157.85 prefix-list DENY-DEFAULT-IN in

Обновляем список принимаемых от 192.168.157.85 префиксов:

router# clear ip bgp 192.168.157.85 soft in

Проверяем:

router0-zebra# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route
 
S>* 0.0.0.0/0 [1/0] via 192.168.157.85, vlan684

Вуаля. Имеем в наличии только статически прописанный дефолт. По BGP он уже не приходит. Теперь дело за малым - применить префикс-лист DENY-DEFAULT-IN к определенным нейборам. А в моем случае еще и убрать этот префикс-лист с нейбора 192.168.157.85 (поскольку на момент тестирования дефолт приходил только от него) и статический маршрут, созданный в начале статьи.

 

Ваша оценка: Нет Средняя: 4.4 (5 голосов)

Вставай, Україно!

Литература

Windows не виснет сразу, сначала она позволяет нажать кнопку "ОК".