Preface Since introducing DDTS CSCus57232 XR software reporting following message:   LC/0/0/CPU0:Oct 31 15:54:03.752 GMT: vic_1[372]: %L2-ETHERNET-6-MTU_NEAR_HW_LIMIT : The MTU of 9220 on TenGigE0_0_1_3 is over the H/W limit, and hence large frames may be dropped as oversized frames   Typical scenario   Let's consider scenario when this message can appear and how to fix it.   Here is the typical configuration which leads to this message.   RP/0/RSP0/CPU0:adum#sh run int GigabitEthernet0/1/1/9* Fri Dec  2 16:04:06.728 CET interface GigabitEthernet0/1/1/9  cdp  mtu 9216  ipv4 address 63.1.1.2 255.255.255.0 ! interface GigabitEthernet0/1/1/9.111  description ---ankomaro HWLIMITTEST  ipv4 address 10.10.10.1 255.255.255.252  encapsulation dot1q 111 ! interface GigabitEthernet0/1/1/9.200 l2transport  encapsulation dot1ad 200 dot1q any   Here is the parent interface with MTU 9216 configured and subinterface (which frequently can be configured later and operator just missed the fact of MTU configuration on the parent interface).   Let's send some pings through parent and sub interfaces with df-bit set and not:   RP/0/RSP0/CPU0:adum#ping 63.1.1.1 size 9202 df-bit Fri Dec  2 16:03:08.743 CET Type escape sequence to abort. Sending 5, 9202-byte ICMP Echos to 63.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms RP/0/RSP0/CPU0:adum#ping 10.10.10.2 size 9202 df-bit Fri Dec  2 16:03:23.361 CET Type escape sequence to abort. Sending 5, 9202-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)   RP/0/RSP0/CPU0:adum#ping 10.10.10.2 size 9202 Fri Dec  2 16:03:41.610 CET Type escape sequence to abort. Sending 5, 9202-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)   RP/0/RSP0/CPU0:adum#ping 10.10.10.2 size 9198 Fri Dec  2 16:03:56.364 CET Type escape sequence to abort. Sending 5, 9198-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/3 ms   As it can be observed router drops the oversized packets regardless of the df-bit until 4 bytes are subtracted and this causes the issue which can be hard to troubleshoot.   The Max MTU size is limited by the interface driver and can be derived from this command output:    RP/0/RSP0/CPU0:adum#sh controllers GigabitEthernet0/1/1/9 control | i Max MTU Fri Dec  2 16:05:09.085 CET     Max MTU: 9216 bytes   What happens with MTU size reported on the interface after MTU configuration (Typhoon LC will show MTU + 4 FCS bytes):   RP/0/RSP0/CPU0:adum#sh controllers GigabitEthernet0/1/1/9 | i MTU Fri Dec  2 16:05:15.070 CET     MTU: 9216 RP/0/RSP0/CPU0:adum#sh int GigabitEthernet0/1/1/9.111 | i MTU Fri Dec  2 16:06:43.522 CET   MTU 9220 bytes, BW 1000000 Kbit (Max: 1000000 Kbit)   Here under subinterface you can see MTU 9220 = 9216 + 4 (vlan tag) and hense frame size of 9216 + VLAN tag (4 bytes) will be dropped as driver has no room space for it.   How to fix it?   On the parent interface lower MTU by the number of bytes needed for the vlan (depends on how many tags will be in the frame).   After reconfiguring MTU on the parent interface to 9212:   RP/0/RSP0/CPU0:adum#sh int g0/1/1/9 | i MTU Fri Dec  2 16:10:31.904 CET   MTU 9212 bytes, BW 1000000 Kbit (Max: 1000000 Kbit) RP/0/RSP0/CPU0:adum#sh int g0/1/1/9.111 | i MTU Fri Dec  2 16:10:47.864 CET   MTU 9216 bytes, BW 1000000 Kbit (Max: 1000000 Kbit)   Pings with 9216 frame size run smoothly: RP/0/RSP0/CPU0:adum#ping 10.10.10.2 size 9202 Fri Dec  2 16:09:47.464 CET Type escape sequence to abort. Sending 5, 9202-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/6 ms   ... View more

Предисловие Когда один из RSP или один из ASR9001 в nV Edge кластере выходит из строя, сразу возникает вопрос, как его правильно заменить, чтобы минимизоровать влияние на предоставляемый сервис. Как сделать все правильно и ничего не разломать окончательно. Эта инструкция даст пошаговый план замены. Общий план работ Если RSP, который планируется заменить, является активным, то необходимо сделать switchover на RSP, который находится в режиме ожидания. Это же действие необходимо сделать, в случае ASR9001, с одной оговоркой. Switchover выполняется на ASR9001, который является бэкапом в кластере. Так же важно, чтобы версия ПО у RSP/ASR9001 в nV Edge кластере совпадали, вплоть до установленных SMU. Для ASR9001 необходимо записать серийный номер шасси, чтобы позднее прописать его на мастере кластера. Подготовительные работы Перед началом основных работ необходимо скачать нужную версию ПО (+ все необходимые SMU) и разместить ее в доступном для скачивания с маршрутизатора месте, например на ftp/tftp сервере. Детальный план работ Для ясности обозначу RSP1 - как неисправный и активный RSP, RSP0 - как исправный в режиме ожидания и RSP1* - исправный RSP на замену. Так же для ASR9001 обозначу rack1 - как неисправный и мастер кластера, rack0 - как исправный и бэкап кластера и rack1* - исправный на замену. 1. Переключитесь с RSP1 на RSP0. Если неисправный неактивен, то этот шаг не выполняется. redundancy switchover location <RSP0/rack0> Redundancy information for node 0/RSP0/CPU0: ========================================== Node 0/RSP0/CPU0 is in ACTIVE role                                <---- активный мастер Node Redundancy Partner (0/RSP1/CPU0) is in STANDBY role        <---- резервный мастер Standby node in 0/RSP1/CPU0 is ready Standby node in 0/RSP1/CPU0 is NSR-ready Node 0/RSP0/CPU0 is in process group PRIMARY role Process Redundancy Partner (1/RSP0/CPU0) is in BACKUP role        <----- активный бэкап Backup node in 1/RSP0/CPU0 is ready Backup node in 1/RSP0/CPU0 is NSR-ready Group            Primary         Backup          Status ---------        ---------       ---------       --------- dsc              0/RSP0/CPU0     1/RSP0/CPU0     Ready dlrsc            0/RSP0/CPU0     1/RSP0/CPU0     Ready central-services 0/RSP0/CPU0     1/RSP0/CPU0     Ready v4-routing       0/RSP0/CPU0     1/RSP0/CPU0     Ready netmgmt          0/RSP0/CPU0     1/RSP0/CPU0     Ready mcast-routing    0/RSP0/CPU0     1/RSP0/CPU0     Ready v6-routing       0/RSP0/CPU0     1/RSP0/CPU0     Ready show platform Node            Type                      State            Config State ----------------------------------------------------------------------------- 0/RSP0/CPU0     A9K-RSP440-TR(Active)     IOS XR RUN       PWR,NSHUT,MON 0/RSP1/CPU0     A9K-RSP440-TR(Standby)    IOS XR RUN       PWR,NSHUT,MON 0/0/CPU0        A9K-24x10GE-TR            IOS XR RUN       PWR,NSHUT,MON 0/1/CPU0        A9K-MOD160-SE             IOS XR RUN       PWR,NSHUT,MON 0/1/1           A9K-MPA-20X1GE            OK               PWR,NSHUT,MON 0/3/CPU0        A9K-VSM-500               IOS XR RUN       PWR,NSHUT,MON 1/RSP0/CPU0     A9K-RSP440-TR(Active)     IOS XR RUN       PWR,NSHUT,MON 1/1/CPU0        A9K-MOD160-TR             IOS XR RUN       PWR,NSHUT,MON 1/1/0           A9K-MPA-8X10GE            OK               PWR,NSHUT,MON 1/1/1           A9K-MPA-1X40GE            OK               PWR,NSHUT,MON 1/3/CPU0        A9K-VSM-500               IOS XR RUN       PWR,NSHUT,MON 2. Отключите RSP1 от электропитания слегка вынув из шасси. 2a. В случае ASR9001 отключите электропитание на rack1. 3. Отключите от RSP1/rack1 кабели, необходимые от сборки кластера. 4. Полностью извлеките RSP1 из шасси. 5. Установите в шасси RSP1*. 6. Подключите консольные и сетевые кабели для управления. Кабели необходимые для сборки кластера на этом шаге не подключаются. 6а. Если выполняется замена ASR9001, то необходимо обновить ПО до версии ПО на rack0, включая SMU и версии прошивок FPD. 7. RSP1* синхронизует ПО с активного RSP0 и перезагрузится, дождитесь его загрузки. 8. Убедитесь, что RSP1* перешел в состояние  "IOS XR RUN". admin show platform 9. Проверьте установленные пакеты. admin show install summary 10. Если выполняется замена ASR9001, запишите серийный номер его шасси. admin show inventory chassis NAME: "chassis ASR-9006-AC", DESCR: "ASR 9006 4 Line Card Slot Chassis with V1 AC PEM" PID: ASR-9006-AC, VID: V01, SN: FOX1318G5WL        <---- серийный номер 11. Загрузите RSP1* в ROMMON. admin config-register 0x0 admin reload location RSP1* 12. Очистите загрузочные переменные. unset CLUSTER_RACK_ID unset CLUSTER_NO_BOOT unset BOOT sync 13. Отключите электропитание от RSP1* и подключите кабели, необходимые для сборки кластера (IRL). 14. Если выполняется замена ASR9001, то на rack0 сконфигурируйте серийный номер rack1*. admin config nv edge control serial RACK1CHASSISSERIALNUMBER rack 1 15. Подключите электропитание к RSP1*/rack1*. 16. Проверьте, что RSP1*/rack1* собрались в кластер. show nv edge control control-link-protocols location <RSP1*/rack1*> ... Priority lPort             Remote_lPort      UDLD STP ======== =====             ============      ==== ======== 0        1/RSP0/CPU0/0     0/RSP0/CPU0/0     UP   Forwarding        <--- убедитесь что состояние Forwarding 1        1/RSP0/CPU0/1     0/RSP0/CPU0/1     UP   Blocking 2        Unknown           Unknown           DOWN On Partner RSP 3        Unknown           Unknown           DOWN On Partner RSP Active Priority is 0 Active switch is   RSP0 CLM Table version is 2 admin show dsc ---------------------------------------------------------            Node  (     Seq)     Role       Serial State ---------------------------------------------------------     0/RSP0/CPU0  (       0)   ACTIVE  FOX1318G5WL PRIMARY-DSC     0/RSP1/CPU0  (14077680)  STANDBY  FOX1318G5WL NON-DSC     1/RSP0/CPU0  (14078415)   ACTIVE  FOX1308G97E BACKUP-DSC 17. Проверьте общее состояние платформы. show redundancy show platform 18. Для проверки работоспособности RSP1* выполните переключение на RSP1*/rack1*. redundancy switchover location RSP1*/rack1* 19. Проверьте общее состояние платформы после переключения. show redundancy show platform Дополнительные материалы Справочная информация по каблированию NV cluster. - https://supportforums.cisco.com/document/145436/asr9k-nv-edge-deployment-guide Turboboot, зачем он нужен? - https://supportforums.cisco.com/ru/document/13077901 ... View more

  Введение. В этой статье я расскажу зачем и в каких случаях нужна процедура Turboboot. Turboboot - это не что иное, как установка ПО на маршрутизатор из окружения ROMmon. Здесь можно провести аналогию с загрузкой домашнего компьютера с CDROM-а с последующей установкой свежей операционной системы. Самым распространенным, но не единственным, случаем, когда Turboboot может быть нужен - это случай, когда вы получаете RSP модуль по RMA. В подавляющем большинстве модули, пришедшие по RMA, не содержат програмного обеспечения , и это ожидаемое состояние. Поэтому, получая модуль на замену, нужно держать в голове две опции для его прошивки ПО.   Опция 1, установка ПО на RSP в рабочем шасси. Первая опция, самая простая и рекомендованная Cisco - опция установки ПО на модуль, пришедший на замену, в шасси с рабочим RSP (подразумевается, что в шасси есть куда вставить этот RSP). По шагам, как это происходит: 1. RSP пришедший на замену плотно вставьте в свободный слот шасси с рабочим RSP. 2. Ждите пока RSP загрузится, образ операционной системы будет автоматически синхронизован с образом активного рабочего RSP. 3. После того, как все пакеты ПО будут синхронизованы, RSP автоматически перезагрузится и начнет загрузку уже с своего диска. 4. Скопируйте нужную конфигурацию в файл на disk0: или harddisk: RSP, пришедшего на замену. 5. Установите конфигурационный регистр RSP для остановки в ROMmon во время загрузки: admin config-register boot-mode rom-monitor location <replacement_RSP_slot 6. Вытащите RSP из шасси. 7. Плотно вставьте RSP в то шасси, где он должен быть установлен, RSP загрузиться в ROMmon. 8. Подключите к RSP консольный кабель. 9. Сконфигурируйте в ROMMon переменную IOX_CONFIG_FILE, чтобы игнорировать стартовую конфигурацию: rommon 3> IOX_CONFIG_FILE=disk0:/dummy.txt 10. Загрузите RSP: rommon 4> boot 11. Когда RSP загрузится, загрузите и сохраните конфигурацию, которую вы сохранили на диске (шаг 4):     RP/0/RSP0/CPU0:9K#configure     RP/0/RSP0/CPU0:9K(config)#load harddisk:<filename>     RP/0/RSP0/CPU0:9K(config)#commit replace Опция 2, Turboboot. Не всегда под рукой может оказаться шасси с рабочим RSP, или, если первая опция не возможна, например, была замена ASR9001. В этом случае есть вторая опция - Turboboot. Итак, чтобы начать загрузку по процедуре Turboboot, необходимо скачать архив с ключевым словом Turboboot, для ASR9K, например, это будет ASR9K-iosxr-px-<VERSION>-Turboboot.tar. Файл mini.vm должен быть размещён на TFTP сервере, или может быть залит на USB флэш-карту, если версия ROMmon и модель RSP позволяет загрузку с USB. В случае с ASR9001 возможность загрузки с USB появилась в версии ROMmon 2.03 (5.1.1 SW). Более ранние RSP, такие как RSP2, физически не поддерживают загрузку с USB, поэтому для них остается только опция с TFTP. Turboboot, шаг за шагом: 1. Вставьте RSP в шасси, RSP загрузиться в ROMmon. 2. Очистите переменные BOOT и TFTP_FILE     unset BOOT     unset TFTP_FILE     sync Примечание: команда sync сохраняет значения переменных в постоянную память. 3. Очистите переменные зеркалирования диска:     unset BOOT_DEV_SEQ_OPER     unset MIRROR_ENABLE     sync Примечание: по умолчанию, зеркалирование включено между двумя внутренними партициями (disk0: и disk1:), если вы отключите зеркалирование, то Turboboot запишет данные только на тот диск, который выбран в качестве диска для записи нового ПО, и у вас останется резервная копия на другом диске. Это имеет смысл в случаях, если процедура Turboboot выполняется для обновления ПО, которое не могло быть обновлено стандартным способом (например, дефект не позволяющий выполнить обновление) и необходимо иметь рабочий диск для отката к предыдущей версии. 4. Отключите CPU watchdog:     priv     diswd Примечание: во время загрузки образа mini-vm CPU watchdog следит за тем, чтобы CPU не оставался в подвисшем состоянии "вечно" и обнуляет состояние CPU через 30 мин. В случае, если скорость передачи данных по TFTP заведомо не даст скачать образ быстрее чем за 30 мин, CPU watchdog обнулит CPU и все придется начинать с начала. Если вы выполняете Turboboot удаленно, на площадке должен быть персонал, который сможет в таком случае по питанию перезагрузить маршрутизатор, если по какой-то причине CPU все-таки подвиснет. 5. Задайте сетевые настройки на интерфейсе управления:     IP_ADDRESS=ip_address     IP_SUBNET_MASK=mask     DEFAULT_GATEWAY=ip_address 6. Задайте параметры для TFTP соединения:     TFTP_RETRY_COUNT=4     TFTP_TIMEOUT=6000     TFTP_CHECKSUM=1     TFTP_SERVER=server_ip_addr     TFTP_MGMT_INTF=0     TFTP_BLKSIZE=1400 Примечание: переменную TFTP_CHECKSUM стоит устанавливать равной 1, чтобы избежать получение поврежденного образа; для CRS переменная, которая задает размер блока - TFTP_BLOCK_SIZE. 7. Ключевой шаг, задайте параметры Turboboot:     TURBOBOOT=on, {boot-device},[format | clean],[nodisablebreak]     где, on - означает install add и install activate, когда маршрутизатор загружается из VM,     boot-device - устройство, на котором планируется развернуть ПО, обычно disk0:     format - полностью заменить ПО, за исключением admin конфигурации     clean - полностью заменить ПО, за исключением admin или exec конфигурации     nodisablebreak - позволяет прервать процедуру Turboboot посредством посылки сигнала прерывания (break signal)     Пример,     TURBOBOOT=on,disk0,format     sync Некоторые замечание по поводу опций format и clean. 1. Для CRS опция format работает для файловой системы типа FAT16, для типа FAT32 и QNX4 должна быть использована переменная MEDIA_FORMAT. 2. Для ASR9K опция MEDIA_FORMAT используется, чтобы полностью стереть как exec, так и admin конфигурацию. 8. Загрузите mini.vm (будьте внимательны, тип файла не должен быть tar или pie): rommon> boot tftp://server/directory/filename     На этом шаге образ копируется в оперативную память и процесс установки на выбранный диск, после чего маршрутизатор перезагружается.     Дождитесь сообщения "SYSTEM CONFIGURATION COMPLETED"     После перезагрузки система автоматически очистит значение переменной TURBOBOOT в ROMmon. Как выполнить Turboboot с USB. RSP440 и ASR9001 с версией ROMmon 2.03 может загружаться с USB флэшки. Для этого вместо команды boot используется команда mediaboot: rommon> mediaboot usb:\release_mini.vm Однако, в поздних версиях ROMmon, команда mediaboot все же была заменена на команду boot и, что самое важное, для ASR9001 локация USB диска стала disk1: rommon> boot disk1:/... Для получения карты дисков в ROMmon существует команда dev, которую стоит использовать, если нет уверенности в названии USB диска. Как выполнить обновления прошивок FPD. После обновления ПО на маршрутизаторе и добавления дополнительных пакетов и SMU, всегда имеет смысл убедиться, что прошивки FPD не требуют обновления и в противном случае их обновить. 1. Введите команду admin show hw-module fpd location all и обратите внимание на поле Upg/Dng, если значение поля yes, то FPD требуется обновление. 2. Для обновления используйте команду admin upgrade hw-module fpd location all, которая выполнит обновления на всех RSP и линейных картах. Дополнительные материалы. 1. ASR9000/XR Understanding Turboboot and initial System bring up 2. Cisco ASR 9000 Series Aggregation Services Router ROM Monitor Configuration Guide, Release 5.3.x ... View more

[toc:faq] В статье будет рассмотрен вопрос манипуляции значением MED относительно оригинального значения на iBGP и eBGP линках, в частности будет проиллюстрировано, что относительное изменение значения может выглядеть как абсолютное. Так же будет рассмотрен вопрос учёта IGP метрики до машрутизатора, который является next-hop для маршрута, при анонсе маршрута в соседнюю автономную систему. Что такое MED? Итак, что такое MED? Из RFC4451, MULTI_EXIT_DISC есть опциональный нетранзитивный атрибут, который предназначен для использования на внешних (inter-AS) линках, чтобы  информировать eBGP-соседей о том, какой путь в автономную систему более предпочтительный. Топология. MED на iBGP линках. Рассмотрим сценарий распространения атрибута MED на iBGP линках. Согласно RFC4451 атрибут MED передается внутри автономной системы и относительное изменение значения MED с помощью route-map будет иметь ожидаемый результат.   Маршрутизатор R1 из AS100 анонсирует префикс 192.168.100.0/24 с относительным изменением MED (+111). Так как команда show ip bgp показывает префиксы до обработки route-map мы видим только оригинальное значение MED (22), установленное при редистрибуции. Конфигурация BGP на R1: router bgp 100 bgp router-id 11.11.11.11 bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 100 neighbor 1.1.1.1 update-source Loopback0 ! address-family ipv4   redistribute connected metric 22 route-map NET198   neighbor 1.1.1.1 activate   neighbor 1.1.1.1 route-map SET_MED out route-map NET198 permit 10 match ip address prefix-list NET198 route-map SET_MED permit 10 set metric +111 R1#show ip bgp 192.168.100.0 BGP routing table entry for 192.168.100.0/24, version 4 Paths: (1 available, best #1, table default)   Advertised to update-groups:      2   Refresh Epoch 1   Local     0.0.0.0 from 0.0.0.0 (11.11.11.11)       Origin incomplete, metric 22, localpref 100, weight 32768, valid, sourced, best       rx pathid: 0, tx pathid: 0x Итоговое значение MED (22 + 111 = 133) видно уже на соседнем маршрутизаторе ASBR1: ASBR1#sh ip bgp 192.168.100.0 BGP routing table entry for 192.168.100.0/24, version 6 Paths: (1 available, best #1, table default)   Advertised to update-groups:      3   Refresh Epoch 2   Local     11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)       Origin incomplete, metric 133, localpref 100, valid, internal, best       rx pathid: 0, tx pathid: 0x0 MED на eBGP линках. Рассмотрим теперь сценарий с eBGP линком. Cогласно все тому же RFC4451, атрибут MED нетранзитивный и получен по iBGP линку, а значит должен быть отброшен при передаче маршрута в соседнюю автономную систему, что как мы видим и происходит: ASBR2#show ip bgp      Network          Next Hop            Metric LocPrf Weight Path *>  192.168.100.0    10.10.21.1                             0 100 ? И в случае, если будет использована route-map с относительным изменением значения MED, то, фактически, это будет означать абсолютное измненение. ASBR1: route-map SET_MED permit 10 set metric +55 ... neighbor 10.10.21.2 route-map SET_MED out ... ASBR2#sh ip bgp      Network          Next Hop            Metric LocPrf Weight Path *>  192.168.100.0    10.10.21.1              55             0 100 ? С первого взгляда это может показаться очевидным, однако, иногда факт того, что все происходит на eBGP линке может ускользнуть от внимания и такое поведение может оказаться неожиданным. Команда set metric-type internal Если существует необходимость учесть IGP метрику до маршрутизатора, который является next-hop для заданного маршрута, то можно использовать команду `set metric-type internal`. ASBR1#sh ip bgp 192.168.100.0 BGP routing table entry for 192.168.100.0/24, version 6 Paths: (1 available, best #1, table default)   Advertised to update-groups:      3   Refresh Epoch 2   Local     11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)       Origin incomplete, metric 133, localpref 100, valid, internal, best       rx pathid : 0, tx pathid : 0 x 0 Значение IGP метрики до NH маршрута 192.168.100.0/24 - 2 (не путать со значением MED маршрута - 133). После обработки маршрута route-map с относительным изменением значения MED и командой `set metric-type internal`: route-map SET_MED permit 10 set metric +55 set metric-type internal ожидаемым значением, которое будет анонсировано соседу, будет значение 2 + 55 = 57: ASBR2#sh ip bgp 192.168.100.0 BGP routing table entry for 192.168.100.0/24, version 6 Paths: (1 available, best #1, table default)   Not advertised to any peer   Refresh Epoch 2   100     10.10.21.1 from 10.10.21.1 (1.1.1.1)       Origin incomplete, metric 57, localpref 100, valid, external, best       rx pathid: 0, tx pathid: 0x0 Это бывает полезным, если маршрут присутствует в IGP и на ASBR этот маршрут анонсируется командой network <prefix>. В этом случае MED берется из IGP метрики и относительное изменение MED будет очевидным и ожидаемым результатом: ASBR1#sh run | sec bgp router bgp 100 bgp router-id 1.1.1.1 bgp log-neighbor-changes neighbor 10.10.21.2 remote-as 200 neighbor 11.11.11.11 remote-as 100 neighbor 11.11.11.11 update-source Loopback0 ! address-family ipv4   network 192.168.100.0   neighbor 10.10.21.2 activate   neighbor 10.10.21.2 next-hop-self   neighbor 10.10.21.2 route-map SET_MED out   neighbor 11.11.11.11 activate ASBR1#sh ip bgp 192.168.100.0 BGP routing table entry for 192.168.100.0/24, version 5 Paths: (2 available, best #1, table default)   Advertised to update-groups:      1          2   Refresh Epoch 1   Local     10.100.21.2 from 0.0.0.0 (1.1.1.1)       Origin IGP, metric 2, localpref 100, weight 32768, valid, sourced, local, best       rx pathid: 0, tx pathid: 0x0   Refresh Epoch 1   Local     11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)       Origin incomplete, metric 133, localpref 100, valid, internal       rx pathid: 0, tx pathid: 0 ASBR1#show ip route  192.168.100.0 Routing entry for 192.168.100.0/24   Known via "ospf 1", distance 110, metric 2, type intra area   Advertised by bgp 100   Last update from 10.100.21.2 on GigabitEthernet0/2, 00:00:57 ago   Routing Descriptor Blocks:   * 10.100.21.2, from 11.11.11.11, 00:00:57 ago, via GigabitEthernet0/2       Route metric is 2, traffic share count is 1 ASBR2#sh ip bgp 192.168.100.0 BGP routing table entry for 192.168.100.0/24, version 4 Paths: (1 available, best #1, table default)   Not advertised to any peer   Refresh Epoch 2   100     10.10.21.1 from 10.10.21.1 (1.1.1.1)       Origin IGP, metric 57, localpref 100, valid, external, best       rx pathid: 0, tx pathid: 0x0 Ссылки по теме. http://www.ietf.org/rfc/rfc4451.txt http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/112965-bgpmed-attr-00.html http://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp4.html ... View more