<?xml version="1.0" encoding="utf-8"?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. https://www.livejournal.com/bots/ -->
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:lj="https://www.livejournal.com">
  <id>urn:lj:livejournal.com:atom1:bgp</id>
  <title>Border Gateway Protocol</title>
  <subtitle>BGP - Border Gateway Protocol</subtitle>
  <author>
    <name>BGP - Border Gateway Protocol</name>
  </author>
  <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/"/>
  <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom"/>
  <updated>2010-09-08T11:47:24Z</updated>
  <lj:journal userid="2033044" username="bgp" type="community"/>
  <link rel="service.feed" type="application/x.atom+xml" href="https://bgp.livejournal.com/data/atom" title="Border Gateway Protocol"/>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:15629</id>
    <author>
      <name>tupoy</name>
    </author>
    <lj:poster user="tupoy" userid="2832869"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/15629.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=15629"/>
    <title>фильтрация исходящего трафика</title>
    <published>2010-09-08T11:47:24Z</published>
    <updated>2010-09-08T11:47:24Z</updated>
    <content type="html">подскажите каким способом лучше решить задачу.&lt;br /&gt;&lt;br /&gt;имеется AS со своей сеткой /22&lt;br /&gt;&lt;br /&gt;и есть 3 бгп пира со своими AS, с которых мы получаем дефолт c локальной фильтрацией сабнетов с префиксом больше /14. всем трем апстримам мы анонсим свою сеть.&lt;br /&gt;&lt;br /&gt;теперь встала задача основной трафик отдавать только двум апстримам, а третьему отдавать только маленький /27 кусочек из нашей сети(за исключением 2х адресов из этой самой /27 сети).&lt;br /&gt;&lt;br /&gt;причем, если вдруг оба основные апстрима упадут, то весь трафик заворачивался бы в третий, и наоборот.&lt;br /&gt;&lt;br /&gt;каким образом построить такую фильтрацию?&lt;br /&gt;&lt;br /&gt;--&lt;br /&gt;crossposted to &lt;span  class="ljuser  i-ljuser  i-ljuser-type-C     "  data-ljuser="ru_cisco" lj:user="ru_cisco" &gt;&lt;a href="https://ru-cisco.livejournal.com/profile/"  target="_self"  class="i-ljuser-profile" &gt;&lt;img  class="i-ljuser-userhead"  src="https://l-stat.livejournal.net/img/community.png?v=556&amp;v=926" /&gt;&lt;/a&gt;&lt;a href="https://ru-cisco.livejournal.com/" class="i-ljuser-username"   target="_self"   &gt;&lt;b&gt;ru_cisco&lt;/b&gt;&lt;/a&gt;&lt;/span&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:15601</id>
    <author>
      <name>Pavel Gulchouck</name>
    </author>
    <lj:poster user="gul_kiev" userid="14417329"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/15601.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=15601"/>
    <title>Разный origin</title>
    <published>2010-02-17T20:00:33Z</published>
    <updated>2010-02-17T20:00:33Z</updated>
    <content type="html">Как может получиться, что у одного префикса, полученного разными путями, разные origin? Кто-то из Tier1 (Tata, Level3, Cogent, Savvis) может в каких-то случаях менять origin транзитных сетей?&lt;br /&gt;Это я не словил момент, когда апдейт одним путём уже пришёл, а другим ещё нет, оно давно так висит, можно и через looking glass на эту сетку смотреть.&lt;br /&gt;&lt;pre&gt;
gul@quoll&amp;gt; show route protocol bgp 74.33.0.0/20 table inet terse 

inet.0: 311658 destinations, 1356659 routes (307693 active, 23 holddown, 602746 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 74.33.0.0/20       B 170        100        250 &amp;gt;195.219.188.57  6453 3356 5650 7011 I
                     B 170        100        210 &amp;gt;130.117.24.17   174 3561 5650 7011 ?
&lt;/pre&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:14909</id>
    <author>
      <name>sha90w</name>
    </author>
    <lj:poster user="sha90w" userid="1714641"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/14909.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=14909"/>
    <title>Борьба с route leak</title>
    <published>2009-11-17T09:14:27Z</published>
    <updated>2009-11-17T09:14:27Z</updated>
    <content type="html">Полезный псто моего колеги о борьбе с route leak: &lt;a target='_blank' href='http://gul-tech.livejournal.com/3349.html'&gt;http://gul-tech.livejournal.com/3349.html&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:12275</id>
    <author>
      <name>baspr</name>
    </author>
    <lj:poster user="baspr" userid="4097948"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/12275.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=12275"/>
    <title>Распределение входящего трафика по двум каналам</title>
    <published>2009-09-04T05:58:39Z</published>
    <updated>2009-09-04T05:58:39Z</updated>
    <content type="html">Есть блок адресов с маской /23&lt;br /&gt;Мне бы хотелось анонсировть для одного провайдера одну из подсетей /24 + весб блок, для другого, соответственно, вторую сеть /24 + весь блок.&lt;br /&gt;Я правильно понимаю, что необходима регистрация route для каждой из сетей /24 в базе RIPE?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:11489</id>
    <author>
      <name>один по тундре еду я</name>
    </author>
    <lj:poster user="ovcehuev" userid="4715801"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/11489.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=11489"/>
    <title>Вопрос по bgp (способы контроля входящего трафика)</title>
    <published>2009-07-25T14:12:06Z</published>
    <updated>2009-07-25T14:12:35Z</updated>
    <content type="html">Добрый день! У меня чисто академический вопрос.&lt;br /&gt;&lt;br /&gt;У AS-100 Есть два провайдера: основной AS-200 и запасной AS-300.&lt;br /&gt;У AS-100 есть единственный пограничный маршрутизатор, и он осуществляет BGP маршутизацию для основного и запасного канала. Существуют 4 способа контроля входящего трафика таким образом, чтобы трафик проходил через AS-200:&lt;br /&gt;1.AS-100 не анонсирует AS-300 информацию о его сетях пока не прервана связь с AS-200.&lt;br /&gt;2.Манипуляции с AS Path&lt;br /&gt;3.AS-300 знает, что резервный и не распространяет информацию, что у него есть путь к AS-100 кроме случая, когда мы анонсировали о пути в сеть, прошло n секунд и мы до сих пор не анонсировали другой путь, который не проходит через него&lt;br /&gt;4.Изменение политики AS-300 таким образом, чтобы она поменяла Local_Pref канала, соединяющего его с AS-100 на более низкий по сравнению с другими&lt;br /&gt;&lt;br /&gt;Собственно нужно узнать про каждый из способов поподробнее, а точнее их недостатки. Перерыл весь интернет, прочитал кучу английских и русских источников. Везде подробно описываются способы контроля исходящего трафика, а на счет входящего только пишут, что это сложнее и описывают способ манипуляции с AS Path. Может быть, кто-нибудь может посоветовать, что почитать по теме?&lt;br /&gt;П.С. Извиняюсь за кривой перевод вопроса... Я не силен в терминологии :)</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:10889</id>
    <author>
      <name>Denis Alaev</name>
    </author>
    <lj:poster user="dei_os" userid="395767"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/10889.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=10889"/>
    <title>автоматическая генерация префикс-листов</title>
    <published>2009-06-15T12:24:31Z</published>
    <updated>2009-06-15T12:24:31Z</updated>
    <content type="html">а подскажите чем нынче префикс-листы генерируют, скажем, по номеру AS?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:10715</id>
    <author>
      <name>Зайнудда-апа</name>
    </author>
    <lj:poster user="l2tp" userid="9596547"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/10715.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=10715"/>
    <title>Неправильный какой-то роут пришел</title>
    <published>2009-05-13T08:19:17Z</published>
    <updated>2009-05-13T08:19:34Z</updated>
    <content type="html">Чем чревато наличие вот такого:&lt;br /&gt;&lt;code&gt;&lt;br /&gt;*&amp;gt;i195.88.112.0/23  [neighborIP]                  110      0 [AS1] [AS2] [AS3] 196705 97 97 97 97 97 97 97 97 97 97 97 97 97 97 i&lt;br /&gt;&lt;/code&gt;&lt;br /&gt;&lt;br /&gt;Для меня лично, для умельца, подсунувшего в препенды AS из ARIN-овского диапазона, и вообще для всех?&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;ARIN search result:&lt;br /&gt;&lt;code&gt;&lt;br /&gt;ReferralServer: rwhois://rwhois.gin.ntt.net:4321/&lt;br /&gt;&lt;br /&gt;ASNumber:   97  &lt;br /&gt;ASName:     NTTA-97 &lt;br /&gt;ASHandle:   AS97 &lt;br /&gt;Comment:     &lt;br /&gt;RegDate:    1999-12-06&lt;br /&gt;Updated:    2005-12-30&lt;br /&gt;&lt;br /&gt;&lt;/code&gt;&lt;br /&gt;RIPE search result:&lt;br /&gt;&lt;code&gt;&lt;br /&gt;% Information related to '195.88.112.0/23AS196705'&lt;br /&gt;&lt;br /&gt;route:          195.88.112.0/23&lt;br /&gt;descr:          Ardinvest&lt;br /&gt;origin:         AS196705&lt;br /&gt;mnt-by:         ARDINVEST-MNT&lt;br /&gt;source:         RIPE # Filtered&lt;br /&gt;remarks:        asdot to asplain conversion&lt;br /&gt;&lt;/code&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:10255</id>
    <author>
      <name>Mustat Kengat</name>
    </author>
    <lj:poster user="azerole" userid="5087462"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/10255.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=10255"/>
    <title>route deaggregation</title>
    <published>2009-04-22T10:12:17Z</published>
    <updated>2009-04-22T10:12:17Z</updated>
    <content type="html">Есть ли какой-то способ узнать, что присланный peer-ом маршрут получен в результате деагрегации? Я так понимаю, деагрегация может произойти только если администратором явным образом сконфигурированы условные инъекции?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:9987</id>
    <author>
      <name>Mustat Kengat</name>
    </author>
    <lj:poster user="azerole" userid="5087462"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/9987.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=9987"/>
    <title>bgp @ 2009-03-17T23:28:00</title>
    <published>2009-03-17T20:40:47Z</published>
    <updated>2009-03-17T20:40:47Z</updated>
    <content type="html">Такой вопрос. Допустим мы анонсируем некий маршрут для CIDR-префикса, более специфичного, чем уже присутствующий в Loc-RIB (и с другим next hop'ом, конечно). Например уже есть маршрут для 192.168.17.0/24, а мы анонсируем для 192.168.17.0/25. Что при этом произойдет? С одной стороны, если читать секцию 9 RFC4271 с самого начала, то ответ вроде бы будет такой, что все будет как обычно - сначала weight, потом LOCAL_PREF, ну и т.п. Если что-то из этого у имеющегося маршрута лучше, то новый никуда не попадет. С другой стороны, есть секция 9.1.4, в которой сказано:&lt;br /&gt;&lt;pre&gt;
   If a BGP speaker receives overlapping routes, the Decision Process
   MUST consider both routes based on the configured acceptance policy.
   If both a less and a more specific route are accepted, then the
   Decision Process MUST install, in Loc-RIB, either both the less and
   the more specific routes or aggregate the two routes and install, in
   Loc-RIB, the aggregated route, provided that both routes have the
   same value of the NEXT_HOP attribute.&lt;/pre&gt;То есть это можно понять так, что в Loc-RIB попадут оба маршрута - как более, так и менее специфичный - что, видимо, означает, что для 192.168.17.0/25 будет всегда использоваться новый маршрут, а для 192.168.17.128/25 - всегда старый. &lt;br /&gt;Как же правильно?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:9967</id>
    <author>
      <name>Mustat Kengat</name>
    </author>
    <lj:poster user="azerole" userid="5087462"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/9967.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=9967"/>
    <title>bgp @ 2009-03-03T12:08:00</title>
    <published>2009-03-03T09:08:25Z</published>
    <updated>2009-03-03T09:08:25Z</updated>
    <content type="html">Вопрос про &lt;a href="http://tools.ietf.org/html/rfc4760" target="_blank" rel="nofollow"&gt;RFC-4760&lt;/a&gt;. Может ли такое продвинутое BGP-сообщение включать несколько MP_REACH_NLRI атрибутов? Я так понимаю, что обычный NLRI в UPDATE может быть только один (просто формат сообщения такой), но атрибутов вроде можно включить сколько угодно?&lt;br /&gt;Поясню откуда вопрос: в &lt;a href="http://tools.ietf.org/html/draft-ietf-idr-flow-spec-05" target="_blank" rel="nofollow"&gt;BGP flowspec&lt;/a&gt; эта штука используется для передачи ACL, так вот в один атрибут MP_REACH_NLRI влезает только одно определение flow, а хотелось бы несколько.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:9522</id>
    <author>
      <name>Mustat Kengat</name>
    </author>
    <lj:poster user="azerole" userid="5087462"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/9522.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=9522"/>
    <title>bgp @ 2009-01-15T18:17:00</title>
    <published>2009-01-15T15:17:56Z</published>
    <updated>2009-01-15T15:17:56Z</updated>
    <content type="html">Добрый день,&lt;br /&gt;&lt;br /&gt;Вопрос в продолжение &lt;a href="http://community.livejournal.com/bgp/9388.html" target="_blank"&gt;моих прошлогодних изысканий&lt;/a&gt;. Есть BGP peered роутеры A и B. В какой-то момент рвется BGP-соединение, и B пропадает из виду. A удаляет все его маршруты и перестает слать на него трафик. Через некоторое время роутер B поднимается, посылает OPEN, но не посылает UPDATE. Что произойдет в это случае? Будут ли все равно восстановлены маршруты на B в Loc-RIB? Или надо обязательно перепосылать их явно в UPDATE?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:9388</id>
    <author>
      <name>Mustat Kengat</name>
    </author>
    <lj:poster user="azerole" userid="5087462"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/9388.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=9388"/>
    <title>bgp @ 2008-12-22T22:33:00</title>
    <published>2008-12-22T19:43:45Z</published>
    <updated>2008-12-22T19:43:45Z</updated>
    <content type="html">Добрый день,&lt;br /&gt;&lt;br /&gt;Несколько немного очевидных, наверное, вопросов про функционирование BGP-роутеров. Представим себе два BGP-peered роутера. Как я понимаю, пиринговые отношения подразумевают постоянно открытое TCP-соединение между ними, и маршруты полученные от peer'а считаются валидными только пока это соединение установлено. Далее, в RFC 1771 написано, что BGP decision process функционирует таким образом, что на каждое направление в Loc-RIB должен включаться только один маршрут (хотя в Adj-RIB-In подходящих маршрутов может быть несколько). Теперь представим себе, что в какой-то момент один из роутеров становится недоступен, TCP-соединение рвется, и все маршруты, которые с него получены, помечаются как невалидные. В этой ситуации:&lt;br /&gt;- можем ли мы считать, что в Loc-RIB не осталось маршрутов с next hop=упавшему роутеру? Разве не могли такие маршруты быть получены из других источников?&lt;br /&gt;- раз для каждого направления в Loc-RIB возможен только один маршрут, и этот маршрут удален в результате потери пиринговых отношений, чем будет руководствоваться роутер при маршрутизации пакетов? Будет снова запущен decision process для нахождения другого маршрута на данное направление?&lt;br /&gt;- допустим я route reflector в этой конфигурации. Получу ли я от оставшегося роутера BGP update, в котором все маршруты, удаленные из Loc-RIB в связи с недоступностью peer'а, будут помечены как withdrawn?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:9199</id>
    <author>
      <name>Kaa</name>
    </author>
    <lj:poster user="kaa" userid="727011"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/9199.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=9199"/>
    <title>bgp @ 2008-11-14T18:35:00</title>
    <published>2008-11-14T17:38:33Z</published>
    <updated>2008-11-14T17:38:33Z</updated>
    <content type="html">А вот скажите, правильно ли выпускать в IPv6 анонсы размером /44-/48?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:8231</id>
    <author>
      <name>Егор</name>
    </author>
    <lj:poster user="lesnix" userid="4742246"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/8231.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=8231"/>
    <title>Маршрутизация в Интернет. "Разорванная" AS.</title>
    <published>2008-06-23T19:30:21Z</published>
    <updated>2008-06-23T19:30:21Z</updated>
    <content type="html">Доброе время суток, уважаемые.&lt;br /&gt;Вопрос чисто академический, интересно понять.&lt;br /&gt;А возможно ли(и применяется ли ?) разбиение AS на две независимых части и анонсирование двум разным апстримам разных префиксов ?&lt;br /&gt;У меня есть, пожалуй, мысли, почему так не делается, связано это наверняка с агрегацией маршрутов некоторыми апстримами, но полноценного ответа на вопрос "почему" у меня нет.&lt;br /&gt;Иными словами, почему не делают так:&lt;br /&gt;&lt;br /&gt;Допустим, есть блок ALLOCATED PA 80.0.48.0/20. Почему нельзя разместить "две части одной AS" в разных точках и анонсировать отдельные префиксы соответствующим апстримам ? А может, всё-таки можно ?&lt;br /&gt;&lt;img src="https://img-fotki.yandex.ru/get/54/lesnix.0/0_12f9b_f34ed7b1_orig" alt="" fetchpriority="high" /&gt;&lt;a name='cutid1-end'&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;crosspost cisco_ru</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:7997</id>
    <author>
      <name>AMIGO</name>
    </author>
    <lj:poster user="mikhajjlovskijj" userid="13819307"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/7997.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=7997"/>
    <title>Mikrotik rb-1000, routeros 3.3 / BGP / AS / 2 ISP</title>
    <published>2008-05-27T11:24:38Z</published>
    <updated>2008-05-27T11:24:38Z</updated>
    <content type="html">Есть микротик RB-1000,роутерос 3.3.&lt;br /&gt;Столкнулся с проблемой:&lt;br /&gt;Есть 2 провайдера, которые выделили свои реквизиты, ип,днс,шлюз, default bgp.&lt;br /&gt;Есть своя автономная система.&lt;br /&gt;&lt;br /&gt;Нужно: настроить так, что бы инет работал одновременно с балансировкой по двум каналам.&lt;br /&gt;Тут &lt;a target='_blank' href='http://www.mikrotik.com/testdocs/ros/2.9/routing/bgp.php' rel='nofollow'&gt;http://www.mikrotik.com/testdocs/ros/2.9/routing/bgp.php&lt;/a&gt; нашёл, но не совсем понятно, может кто-то натолкнуть на путь?&lt;br /&gt;Принцип заключается в том, что бы я на ether1 и ether2 прописал IPы уже из своей АС,прописал маршруты до провайдеров, затем попросил своих ISP, что бы те прописали мою АС на своём оборудовании? Я так мыслю?&lt;br /&gt;&lt;br /&gt;Спасибо.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:7786</id>
    <author>
      <name>Егор</name>
    </author>
    <lj:poster user="lesnix" userid="4742246"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/7786.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=7786"/>
    <title>bgp @ 2008-04-23T01:47:00</title>
    <published>2008-04-22T21:56:49Z</published>
    <updated>2008-04-22T21:56:49Z</updated>
    <content type="html">Добрый день, уважаемые. &lt;br /&gt;Интересно было бы послушать Ваши мнения о причинах следующей ситуации. &lt;br /&gt;Есть автономная система, два граничных маршрутизатора, соединенных напрямую. Каждый граничный маршрутизатор принимает  fullview - первый от одного провайдера(AS100), второй - от другого(AS300).&lt;br /&gt;Между бордерами поднята iBGP-сессия. Чтобы автономка не стала тразитной - исходящие к провайдерам анонсы ограничены соответствующими списками префиксов.&lt;br /&gt;Ожидал, что в результате на каждом из бордеров будет два fullview, однако, получил какую-то не вполне понятную ситуацию, когда на один из бордеров приходит только часть префиксов из второго fullview. &lt;br /&gt;Интересно было бы разобраться, в чем дело.&lt;br /&gt;Топология и конфиги - ниже, &lt;br /&gt;&lt;img src="https://imgprx.livejournal.net/dc33f0bbf1265e9148a1ed478182e1f795eab9ef0e91df364417b2c76f4e4a7d/P2WlxyVijxKvgGBm8MhRWUMdsf-ah7h0y0uOQqFDltTW4VbGgI6sBU1pEFVhCgJzsVJqjC_RYQ9AEBwGjR954g:xQoAMhNvl221HrRmfWKRcg" alt="" fetchpriority="high" /&gt;&lt;br /&gt;&lt;a name='cutid1-end'&gt;&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:7679</id>
    <author>
      <name>trias</name>
    </author>
    <lj:poster user="trias" userid="2793950"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/7679.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=7679"/>
    <title>foundry bgp</title>
    <published>2007-12-02T10:20:57Z</published>
    <updated>2007-12-02T10:20:57Z</updated>
    <content type="html">интересный факт что "Foundry Bundle Bigiron Fiber 100" не желает конектиться с кошками 65xx (остальные не проверял). Один уважаемый человек сказал поставить ebgp-multihop 2 дабы повысить ttl, и сие заводится.&lt;br /&gt;с чем бы это молгло было быть связанно?&lt;br /&gt;&lt;br /&gt;ps. прошивку менял на последнюю, до этого даже с juniper не хотел вникакую дружить.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:7407</id>
    <author>
      <name>Nemo me impune  lacessit</name>
    </author>
    <lj:poster user="ex_callmepli228" userid="13303906"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/7407.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=7407"/>
    <title>bgp @ 2007-11-20T13:22:00</title>
    <published>2007-11-20T10:24:36Z</published>
    <updated>2007-11-20T10:30:59Z</updated>
    <content type="html">Добрый день.&lt;br /&gt;&lt;br /&gt;Есть автономная система и блок провайдернонезависимых адресов (2 сетки /24). &lt;br /&gt;Есть Cisco 7206. Есть 2 провайдера, к которым подключена AS. От обоих &lt;br /&gt;приходит FULL VIEW. Нужно сделать одного провайдера основным, а другого - &lt;br /&gt;бакапным. Как назло без дополнительных настроек входящий трафик идёт не через &lt;br /&gt;того провайдера, который нужен. Пытался делать препенды и аннонсировать сетки &lt;br /&gt;с ними через бакапнгого провайдера, но они не помогают. Результат проверяю на &lt;br /&gt;looking glass в Релкоме &lt;a target='_blank' href='http://relcom.net/INFO/NOC-IP/lg/lg0.html' rel='nofollow'&gt;http://relcom.net/INFO/NOC-IP/lg/lg0.html&lt;/a&gt;. &lt;br /&gt;Теперь хочу бакапному провыйдеру анонсировать одну более крупную  сеть с &lt;br /&gt;длиной префикса /23, а основному - две сети с префиксами по /24. &lt;br /&gt;Предварительно в RIPE создали объект route на нашу сеть /23. Раньше были &lt;br /&gt;только объекты route c префиксами /24.&lt;br /&gt;Сделал &lt;br /&gt;ip prefix-list backup-list seq 5 permit x.x.x.0/23&lt;br /&gt;ip prefix-list backup-list seq 15 deny 0.0.0.0/0 le 32&lt;br /&gt;!&lt;br /&gt;ip prefix-list main-list seq 5 permit x.x.x.0/23 le 24&lt;br /&gt;ip prefix-list main-list seq 15 deny 0.0.0.0/0 le 32&lt;br /&gt;&lt;br /&gt;и применил эти prefix-list  к соответствующим пирам в настройках bgp.&lt;br /&gt;&lt;br /&gt;В результате получил то, что через основного прова отдаются в инет анонсы &lt;br /&gt;сеток с more specific route, а через бакапного - менее specific. И весь &lt;br /&gt;входящий трафик полился через основного. Смотрел на Looking glass - в &lt;br /&gt;интернете появился анонс нашей сетки с сумарным адресом x.x.x.0/23  и он &lt;br /&gt;анонсируется через бакапного провайдера. Фильтры у провайдеров на наши анонсы &lt;br /&gt;настроены правильно - т.е. принимаются сети и с префиксом /24 и с /23.&lt;br /&gt;&lt;br /&gt;Решил потом проделать эксперимент - в BGP положил основного провайдера, для &lt;br /&gt;того, чтобы убедиться, что будет работать бакапный. Но он не работает. &lt;br /&gt;Почему-то не всплывает в интернете адрес нашей сети с префиксом /23.&lt;br /&gt;Может быть ещё какие-нибудь объекты в RIPE нужно создавать? Кто знает, &lt;br /&gt;помогите...&lt;br /&gt;&lt;br /&gt;&lt;a href="http://community.livejournal.com/ru_cisco/36015.html#comments" target="_blank"&gt;Кросcпост ru_cisco&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:6962</id>
    <author>
      <name>Making more possible</name>
    </author>
    <lj:poster user="shurskiy" userid="4679347"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/6962.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=6962"/>
    <title>neighbor allow-as</title>
    <published>2007-11-12T10:30:26Z</published>
    <updated>2007-11-12T10:30:26Z</updated>
    <content type="html">Добрый день!&lt;br /&gt;Есть несколько филиалов в различных городах России. Все они ходят в интернет, через локальных операторов.&lt;br /&gt;У всех филиалов, один номер автономной системы.&lt;br /&gt;Задача: обеспечить связность филиалов.&lt;br /&gt;На ум приходят три варианта:&lt;br /&gt;1) Фича neighbor allow-as&lt;br /&gt;2) Тунели&lt;br /&gt;3) Перевод каждого региона на собственную АС(это будет сделано несколько позже).&lt;br /&gt;&lt;br /&gt;Кто-нить пользовал фичу neighbor allow-as?&lt;br /&gt;Какие подводные камни тут могут быть?&lt;br /&gt;Спасибо!&lt;br /&gt;&lt;br /&gt;Кросспосты в ru_cisco, cisco_ru</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:6711</id>
    <author>
      <name>Pfka MU</name>
    </author>
    <lj:poster user="pfka_mu" userid="8226482"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/6711.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=6711"/>
    <title>Анонсирование куска AS</title>
    <published>2007-10-05T06:02:09Z</published>
    <updated>2007-10-05T10:47:37Z</updated>
    <content type="html">Доброго времени суток!&lt;br /&gt;&lt;br /&gt;Возникла необходимость отделить часть автономной системы для использования в другом городе.&lt;br /&gt;Вроде всё понятно, но что-то не заводится iBGP с полпинка. Сам neighbour (роутер D) поднимается, но анонсов от него никаких не приходит. Префикс-листов и as-path-фильтров никаких не настроено.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Заработало после доведения до ума роутера D&lt;/b&gt;. Всем спасибо, особенно анонимусам ))&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;img src="https://imgprx.livejournal.net/672315eea6c85ecce0d4c2ce8dc4a58e130b8034597b923600ec756f822aff85/P2WlxyVijxKvgGBm8MhRWUMdsf-ah7h0yFmVCbFanNPcvRvbmI6wBkMwBVV0GgJ4uk5Aj3KPLFsRUgNeykBjqwgFm3CNJQ:vMTGsPViCoNDkDoo_uZ6JA" fetchpriority="high"&gt; &lt;br /&gt;Схема похожа вот на эту, только между роутерами B и D не EIGRP, а статика (через VPN MPLS). &lt;br /&gt;Конфиг роутера B:&lt;br /&gt;router bgp 45000&lt;br /&gt; bgp log-neighbor-changes&lt;br /&gt; timers bgp 20 60&lt;br /&gt; neighbor 192.168.1.2 remote-as 40000&lt;br /&gt; neighbor 192.168.1.2 update-source Loopback0&lt;br /&gt; neighbor 172.22.1.2 remote-as 45000&lt;br /&gt; neighbor 172.22.1.2 description iBGP Peer&lt;br /&gt; neighbor 172.22.1.2 update-source Loopback0&lt;br /&gt; !&lt;br /&gt; address-family ipv4&lt;br /&gt; neighbor 192.168.1.2 activate&lt;br /&gt; neighbor 192.168.1.2 weight 10000&lt;br /&gt; neighbor 172.22.1.2 activate&lt;br /&gt; neighbor 172.22.1.2 weight 10000&lt;br /&gt; default-information originate&lt;br /&gt; distance bgp 20 150 200&lt;br /&gt; no auto-summary&lt;br /&gt; synchronization&lt;br /&gt; network 172.16.0.0 mask 255.255.0.0&lt;br /&gt; exit-address-family&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;Роутер D:&lt;br /&gt;&lt;br /&gt;router bgp 45000&lt;br /&gt; bgp log-neighbor-changes&lt;br /&gt; timers bgp 20 60&lt;br /&gt; neighbor 172.16.1.1 remote-as 45000&lt;br /&gt; neighbor 172.16.1.1 description iBGP peer&lt;br /&gt; !&lt;br /&gt; address-family ipv4&lt;br /&gt; neighbor 172.16.1.1 activate&lt;br /&gt; distance bgp 20 150 200&lt;br /&gt; no auto-summary&lt;br /&gt; synchronization&lt;br /&gt; network 172.18.0.0 mask 255.255.0.0&lt;br /&gt; exit-address-family&lt;br /&gt;&lt;a name='cutid1-end'&gt;&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:6525</id>
    <author>
      <name>Making more possible</name>
    </author>
    <lj:poster user="shurskiy" userid="4679347"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/6525.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=6525"/>
    <title>Балансинг(Шаирнг)</title>
    <published>2007-09-20T11:57:01Z</published>
    <updated>2007-09-20T11:57:01Z</updated>
    <content type="html">День добрый!&lt;br /&gt;&lt;br /&gt;Есть 2 провайдера. С каждым по 2 сессии. Одна - канал по трафику. Вторая - Безлимитный.&lt;br /&gt;С каналами по трафику все здорово и понятно.&lt;br /&gt;Там мне не надо балансировать ничего.&lt;br /&gt;С безлимитными ситуация такая:&lt;br /&gt;Канал А&amp;nbsp;10 мегабит, канал Б 50 мегабит. Очень хочется распределить между ними нагрузку. Чтобы небыло такого, что А - загружен на 100%, а Б - 1%.&lt;br /&gt;Чтобы загрузка распределялась.&lt;br /&gt;Нашел такое решение:&lt;br /&gt;bgp dmzlink-bw&lt;br /&gt;neighbor&amp;nbsp;А dmzlink-bw&lt;br /&gt;neighbor&amp;nbsp;Б dmzlink-bw&lt;br /&gt;maximum-path 2&lt;br /&gt;&lt;br /&gt;Вводные: каналы А и Б - от разных провайдеров(разные автономные системы соответственно), при этом у всех(и каналов по трафику и безлимитных&amp;nbsp;каналов) одинаковые парамерты: вес, стоимость, локалпреф, мед.&lt;br /&gt;Если я так сделаю, как поведут себя каналы щпо трафику?&lt;br /&gt;Какие могут возникнуть проблемы?&lt;br /&gt;И если это решение не подходит(является в корне не верным) какие еще можно рассмотреть решения?&lt;br /&gt;У меня все крутить на роутере цыска 7301.&lt;br /&gt;Спасибо.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:6350</id>
    <author>
      <name>Making more possible</name>
    </author>
    <lj:poster user="shurskiy" userid="4679347"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/6350.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=6350"/>
    <title>Вопрос про ip sla monitor</title>
    <published>2007-08-24T11:23:11Z</published>
    <updated>2007-08-24T11:23:11Z</updated>
    <content type="html">&lt;p&gt;Пришлось отказаться от идеи VRF ввиду непрозрачности и некоторого гемора в обслуживании(потому что отдаем потом местным региональным парням).&lt;br /&gt;Настраиваю ip sla monitor.&lt;br /&gt;Вот, что получилось:&lt;br /&gt;ip sla monitor 168&lt;br /&gt;&amp;nbsp;type tcpConnect dest-ipaddr&amp;nbsp;x.x.x.x dest-port 179 source-ipaddr&amp;nbsp;x.x.x.y control disable&lt;br /&gt;&amp;nbsp;timeout 2000&lt;br /&gt;&amp;nbsp;tag RT_LIMIT_OUT&lt;br /&gt;ip sla monitor schedule 168 life forever start-time now&lt;br /&gt;track 168 rtr 168&lt;br /&gt;&amp;nbsp;delay down 10 up 20&lt;br /&gt;&lt;br /&gt;или&lt;br /&gt;&lt;br /&gt;ip sla monitor 168&lt;br /&gt;&amp;nbsp;type echo protocol ipIcmpEcho&amp;nbsp;x.x.x.x source-ipaddr x.x.x.y&lt;br /&gt;&amp;nbsp;timeout 2000&lt;br /&gt;&amp;nbsp;tag RT_LIMIT_OUT&lt;br /&gt;ip sla monitor schedule 168 life forever start-time now&lt;br /&gt;track 168 rtr 168&lt;br /&gt;&amp;nbsp;delay down 10 up 20&lt;br /&gt;&lt;br /&gt;На мой взгляд, правильнее конечно мониторить 179 порт, потому как у нас есть BGP. Тут возникает вопрос, когда настраиваешь route-map.&lt;br /&gt;Есть там такая строчка: set ip next-hop verify-availability&amp;nbsp;x.x.x.x track 168&lt;br /&gt;verify-availability&amp;nbsp;- смотрит лишь изменения состояния в track&amp;nbsp; и по стейту переключает на тот или иной хоп трафик?&lt;br /&gt;Или эта фича работает только тогда, когда у нас в мониторе писано: type echo protocol ipIcmpEcho&amp;nbsp;?&lt;br /&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:5876</id>
    <author>
      <name>Making more possible</name>
    </author>
    <lj:poster user="shurskiy" userid="4679347"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/5876.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=5876"/>
    <title>Одна сеть два провайдера</title>
    <published>2007-08-13T11:57:59Z</published>
    <updated>2007-08-13T11:57:59Z</updated>
    <content type="html">Добрый день!&lt;br /&gt;Есть задача реализовать следующую схему:&lt;br /&gt;&amp;lt;ISP1&amp;gt;-----BGP-----&amp;lt;MY_BGW&amp;gt;-----BGP-----&amp;lt;ISP2&amp;gt;&lt;br /&gt;С каждым ISP есть по два канала: Один безлимитный и один, который считается по трафику.&lt;br /&gt;Есть два типа клиентов: &lt;br /&gt;1)С тарифами, где считается трафик&amp;nbsp;- отправляются в канал по трафику(там качество обслуживания лучше).&lt;br /&gt;2)С безлимитными тарифами - отправляются в безлимитный канал.&lt;br /&gt;Мне выделены сети x.y.z.0/22.&lt;br /&gt;Сейчас разбито так:&lt;br /&gt;x.y.1.0/24 - нат для клиентов по трафику&lt;br /&gt;x.y.2.0/24 - нат для безлимитных клиентов.&lt;br /&gt;Остальное под служебное пользование и резерв.&lt;br /&gt;&lt;br /&gt;С такой схемой включения надо реализовать балансировку каналов: по трафику отдельно, безлимитных отдельно.&lt;br /&gt;Как сделать?</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:4417</id>
    <author>
      <name>vovka_on_ip</name>
    </author>
    <lj:poster user="vovka_on_ip" userid="11556892"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/4417.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=4417"/>
    <title>path-mtu-discovery</title>
    <published>2006-12-12T09:43:59Z</published>
    <updated>2006-12-12T09:43:59Z</updated>
    <content type="html">&amp;nbsp;Всем привет!&lt;br /&gt;Может кто-нибудь пояснить про path-mtu-discovery? На всех ibgp-х нейборах у меня в сети почему-то максимальный размер датаграмм 536 байт, хотя везде присутствует глобальная команда &lt;br /&gt;ip tcp path-mtu-discovery. Маршрутизаторы воткнуты в каталисты, в одном влане. Не знаю, куда копать, потому как на стенде, где три рутера воткнуты в один каталист, для всех bgp- сессий максимальный размер 1460 байт.&lt;br /&gt;&amp;nbsp;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:bgp:4126</id>
    <author>
      <name>Мррр! aka Woland the Illusive Cat</name>
    </author>
    <lj:poster user="mrrr" userid="779687"/>
    <link rel="alternate" type="text/html" href="https://bgp.livejournal.com/4126.html"/>
    <link rel="self" type="text/xml" href="https://bgp.livejournal.com/data/atom/?itemid=4126"/>
    <title>BGP Community Question!</title>
    <published>2006-09-26T17:53:09Z</published>
    <updated>2006-09-26T18:08:00Z</updated>
    <lj:music>Аквариум - Лилит</lj:music>
    <content type="html">Есть такая ситуация. Я - провайдер, имеющий автономную систему и двух аплинков, тоже с автономными системами. Так же, у меня есть клиент, тоже с автономной системой. Он просит предоствить ему bgp-coommunity, для балансировки _его_ трафика между двумя _моими_ аплинками, путем аннонсирования различным аплинкам своих различных префиксов, с различным числом препендов. Собственно вопрос - как это реализовать ? О всяких ip community-list и match community в route-map'ах я знаю, но как-то все это в голове не складывается вместе... По этому поводу - help\снимите_с_ручного_тормоза :)</content>
  </entry>
</feed>
