VitekA

На коммутаторе куда подключен данный роутер уже есть настройки, других промежуточных коммутаторов между ними нет vlan 999 remote-span monitor session 1 destination interface Te1/6 monitor session 1 source remote vlan 999 monitor session 1 filter packet-type good rx но трафик не идет, а должно быть в районе 300 Мбит/сек

Здравствуйте! В процессе настройки подачи трафика для СОРМ настроил RSPAN на коммутаторах CISCO 4900M/4924/ME3400, все работает, однако есть нюанс, через мониторящийся 10G интерфейс идет трафик между нашими бордерами (CISCO ASR1004), т.е. получается определенное "задвоение" трафика в сторону оборудования СОРМ. В связи с этим решили настроить RSPAN на самих бордерах, чтобы зеркалировать трафик с их внешних интерфейсов. По документации необходимо создать Bridge domain interface который организует передачу между L2- и L3-уровнями interface BDI999 no ip address encapsulation dot1Q 999 Затем на интерфейсе в сторону ядра сети куда нужно отправлять зеркалированный трафик создаю EVI для поддержки L2 сервисов и привязываю его к BDI interface interface TenGigabitEthernet0/0/0 no ip address no ip redirects no ip unreachables no ip proxy-arp negotiation auto service instance 1 ethernet encapsulation dot1q 999 bridge-domain 999 После чего создаю RSPAN-сессию где указываю источник и получателя зеркалированного трафика. monitor session 1 type rspan-source source interface Te0/0/0 destination remote vlan 999 no shut Но такая конструкция не работает и трафик на СОРМ не идет. Понимаю что что-то упустил в конфигурации поэтому прошу помочь в донастройке. P.S. Все это нужно чтобы снизить объемы "сливаемого" на СОРМ трафика и снижения нагрузки на магистральные каналы ядра сети. С Уважением.

access-list 106 remark PBR to NetFlow Collector access-list 106 permit ip host 172.16.2.1 host 192.168.1.100 access-list 106 permit ip host 172.16.6.2 host 192.168.1.100 access-list 106 permit ip host 172.16.4.2 host 192.168.1.100 access-list 106 permit ip host XXX.XXX.XXX.XXX host 192.168.1.100 route-map To_NetFlow_Collector permit 10 match ip address 106 set ip next-hop 172.16.6.8 ip local policy route-map To_NetFlow_Collector Сейчас так и стоит/работает статический маршрут ip route 192.168.1.100 255.255.255.255 172.16.6.8 но руководство упорно считает это неправильным.

Здравствуйте! Поставили задачу отправлять весь NetFlow трафик с маршрутизатора ASR 1002 на IP-адрес коллектора не через основной канал, а через резервный, причем с нюансом - ТОЛЬКО NetFlow трафик, весь остальной трафик на этот IP-адрес должен идти по основному каналу. Маршрутизация в сети динамическая по EIGRP. Первоначальный вариант с прописыванием статики только на адрес коллектора работает нормально, но руководству почему-то не нравится. Попытка настроить local PBR на ASR 1002 показала, что данный тип трафика не попадает даже в случае указания ip access-list 100 permit ip any host 192.168.1.100 eq 9999 (чтобы посмотреть попадает ли вообще какой-нибудь трафик, до этой строки стоят аналогичные, но с указанием ВСЕХ IP-адресов на интерфейсах данного маршрутизатора) ip flow-export source GigabitEthernet0/0/2 ip flow-export version 5 origin-as ip flow-export destination 192.168.1.100 9999 В описаниях указывается, что PBR применяется на интерфейсах для входящего трафика (и это прекрасно работает для обратного трафика с коллектора на ASR 1002), в тоже время в описании local PBR говорится, что она применяется для пакетов генерируемых самим маршрутизатором и настраивается в глобальном конфигурационном режиме. В связи с этим я недопонимаю почему не срабатывает описанная выше конструкция и прошу помочь разобраться с данной задачей. С Уважением, Виктор

Проблему решил отключением VTP pruning, хотя в документации CISCO пишется, что на коммутаторах по умолчанию pruning выключен, на поверку оказалось что это не совсем так. Видимо есть некоторая несовместимость в работе VTP pruning в результате которой на линках между МЕ4924 и МЕ3400 блокировались все VLAN-ы кроме Native VLAN1. Спасибо.

Специальных настроек для мультикаскта на коммутатрах нет. Для МЕ3400: ME3400#sh sdm prefer The current template is "layer-2" template. The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 1024 VLANs. number of unicast mac addresses: 8K number of IPv4 IGMP groups: 1K number of IPv4 multicast routes: 0 number of IPv4 unicast routes: 0 number of IPv4 policy based routing aces: 0 number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K ME3400# МЕ4924 с указанным IOS-ом такую команду вообще не поддерживает. ip routing настроен на SW1 и SW2 на которых и поднят EIGRP, МЕ-шки как я уже говорил чистый L2 там естественно ничего относильно маршрутизации не конфигурировалось.

1) EIGRP запущен на коммутаторах SW1 и SW2 - кольцо из МЕ-шек чистый L2 2) В IOSе cat4500-entservicesk9-mz.150-2.SG.bin для МЕ4924 для портов нет понятия UNI/ENI/NNI. Да и траффик между портами одного и того-же коммутатора МЕ4924 проходит без каких-либо проблем (а UNI-порты на одном устройстве вроде как являются изолированными по умолчанию даже если в одном VLAN-е) 3) Конфиг STP везде дефолтный, т.к. схема не сложная и аналогичная на всех четырех коммутаторах, в транках разрешены все VLAN-ы Для МЕ3400: spanning-tree mode rapid-pvst spanning-tree portfast bpdufilter default spanning-tree extend system-id ! vlan internal allocation policy ascending Для МЕ4924: spanning-tree mode rapid-pvst spanning-tree portfast bpdufilter default spanning-tree extend system-id ! vlan internal allocation policy ascending

Настройки для ME4924 я уже давал в первом посте: interface GigabitEthernet1/1 description This is TEST port switchport access vlan 1000 switchport mode access interface GigabitEthernet1/28 description This port connect to CISCO ME4924 switchport trunk encapsulation dot1q switchport mode trunk Все коммутаторы работают как L2 устройства. При отладке сообщений EIGRP на коммутаторах в МЕ3400 замечено, что с коммутаторов от МЕ4924 на приходят сообщения HELLO, а только UPDATE.

Здравствуйте! Уже "сломал" голову по поводу совместной работы коммутаторов CISCO ME4924 и ME3400. Магистральное кольцо состоит из двух ME4924 и двух ME3400 и возникла проблема односторонних линков при работе клиентских VLAN на коммутаторах разных моделей, т.е. работа протокола EIGRP на оборудовании (catalyst-ы 3560 или 3550) включенном в ME4924 получает пакеты от аналогичного оборудования с ME3400, но не наоборот. При этом через VLAN1 EIGRP работает нормально в обе стороны. Также EIGRP во всех VLAN-ах нормально работает между одинаковыми парами коммутатров. Вот настроки ME3400: vlan 1000 name TEST_LINK interface GigabitEthernet0/1 description This is TEST port port-type nni switchport access vlan 1000 interface GigabitEthernet0/16 description This port connect to CISCO ME4924 port-type nni switchport mode trunk А это настройки для ME4924: interface GigabitEthernet1/1 description This is TEST port switchport access vlan 1000 switchport mode access interface GigabitEthernet1/28 description This port connect to CISCO ME4924 switchport trunk encapsulation dot1q switchport mode trunk Сами VLAN прописаны на всех четырех коммутаторах кольца и показывается по sh vlan. MTU на всех коммутатрах также совпадает. Более того, на оконечных коммутатрах 3550/3560, включенных в ME3400 в интерфейсы vlan 1000, в таблице ARP видны IP-адреса всех соседей по этому vlan, однако соседи в коммутатрах ME4924 появляются только после запуска команды ping на соответствующий IP. Такое ощущение, что ME3400 не принимает широковещание от ME4924, но принимает его от второй ME3400. Прошу подсказать что я упустил в настроках и в чем может быть проблема. С Уважением, Виктор P.S. Ранее магистральное кольцо состояло из 4-х ME3400 и такой проблемы не возникало, но в связи с необходимостью расширения SFP-портов, были приобретены две ME4924. Причем возникшая проблема была обнаружена не сразу, т.к. в vlan 1000 входят резервные линки от 3550/3560.

По поводу п.1 я имел ввиду что именно кольцо из МЕ3400 не будет видно клиенту. А по поводу использования BRAS-ов - к сожалению МЕ3400 и 3550 есть в наличии и стоит задача вывести 3550 из ядра сети (в остальном их текущая работа нас вполне устраивает), а докупать дополнительное оборудование пока не планируется.

Здравствуйте! В настоящее время занимаюсь проработкой схемы модернизации сети. Планируется организовать кольцо из 4-х CISCO МЕ3400 в качестве Core (трафик в сети пока не забивает и 100 Мбит) к которым будут подключаться Catalyst 3550-48 в качестве уровня доступа. С целью резервирования линков стоит задача подключения 3550 к двум "соседним" ME3400. Маршрутизация внутри сети осуществляется посредством 3550 и работает по EIGRP. Для доступа в Интернет через NNI порты каждый МЕ3400 будет соединен с бордером на базе 7600VXR (по два коммутатора на бордер) чем так же будет достигнуто резервирование доступа на бордеры. (Адаптированная схема L2 VPN сервиса с сайта cisco.com) Аналогично бордерам в МЕ3400 планируется включить и имеющиеся сервера - хостинг, DNS, VPN. Как мне видится задача реализации: 1. Прозрачность опорной сети для наших клиентов. 2. Посредством 3550 разделить сеть на изолированные домены, один L3-коммутатор - 1 здание/группа зданий. 3. Резервирование каналов. Смущает меня следующее - если подключение между МЕ3400 и 3550 строить через транки, то вопрос №1 и №3, а также работа EIGRP вроде бы решается как мне необходимо. А вот как решить вопрос №2 с изоляцией домена, чтобы проблемы на L2 уровне не отражались на всей остальной сети. Т.к. у МЕ3400 имеются UNI/ENI и NNI режимы работы портов, причем для портов типа UNI имеется целый раяд жестких ограничений, то вот я и подумал, позволит ли этот функционал решить вопрос №2 если транковые порты к 3550 будут в режиме UNI. подскажите как лучше/правильней реализовать данную схему.

У нас есть прямое подключение к MSK-IX, а через Рубиком (они же РетН) после подключения "потекла" часть трафика, которая ранее шла через MSK-IX. Трафик РосТелеКома ранее весь ходил через MSK-IX, а сейчас часть пошла через РубиКом. Это попытка вернуть трафик на интерфейс MSK-IX. Можно расшифровать "ОПГ", а то на ум приходит только "организованная преступная группировка" :( Я как раз обдумывал такой вариант, чтобы Голден сделать резервным каналом на запад. Спасибо за ответ.

Здравствуйте, имеется два ап-линка - "Голден" и "РубиКом" каждый из которых подключен к отдельному бордеру 7206VXR-G2 от каждого из ап-линков мы принимаем Full View. После перехода на "РубиКом" (до этого на данном бордере был "ТрансТелеком") возникла проблема со значительной ассиметрией трафика в результате чего ухудшился доступ в нашу автономную систему (время возросло на 60-100 мсек). Борьба за выправление данной ситуации, использование комьюнити и препендов не очень-то и помогает, в основном это относится к западному трафику. Хочется иметь два внешних канала с более-менее симметричным (вход-выход) трафиком. Посоветуйте можно ли выправить ситуацию более элегантно/просто, или выход только договариваться об организации с одним из ап-линков резервного канала? Вариант анонсов одному из ап-линков наших сетей как /23 или /24 (сейчас анонсируем блоки /22) я рассматриваю как не очень правильный, хотя и достаточно распространенный случай. Конфиги ниже. Первый бордер //сессия iBGP между двумя бордерами neighbor zzz.zzz.zzz.146 remote-as MY-AS neighbor zzz.zzz.zzz.146 description 7206VXR-G2 neighbor zzz.zzz.zzz.146 activate neighbor zzz.zzz.zzz.146 next-hop-self neighbor zzz.zzz.zzz.146 soft-reconfiguration inbound neighbor 87.245.ххх.ххх remote-as RUBYCOM neighbor 87.245.ххх.ххх description RUBYCOM neighbor 87.245.ххх.ххх activate neighbor 87.245.ххх.ххх send-community neighbor 87.245.ххх.ххх remove-private-as neighbor 87.245.ххх.ххх soft-reconfiguration inbound neighbor 87.245.ххх.ххх route-map RubyCom_out out neighbor 87.245.ххх.ххх filter-list 5 out //здесь анонсирются наши сети route-map RubyCom_out permit 10 set community 702:65534 1273:65534 3549:65534 8359:65534 8631:65535 12389:65535 20485:65534 Второй бордер //сессия iBGP между двумя бордерами neighbor zzz.zzz.zzz.145 remote-as MY-AS neighbor zzz.zzz.zzz.145 description 7206VXR-G2 neighbor zzz.zzz.zzz.145 activate neighbor zzz.zzz.zzz.145 next-hop-self neighbor zzz.zzz.zzz.145 soft-reconfiguration inbound neighbor 195.218.ууу.ууу remote-as Golden neighbor 195.218.ууу.ууу description Golden_Telecom neighbor 195.218.ууу.ууу activate neighbor 195.218.ууу.ууу send-community neighbor 195.218.ууу.ууу remove-private-as neighbor 195.218.ууу.ууу soft-reconfiguration inbound neighbor 195.218.ууу.ууу route-map setlocalin_Golden in neighbor 195.218.ууу.ууу filter-list 5 out //эта часть - попытка создать "костыль", чтобы выправить асимметрию ip as-path access-list 1 permit ^3216*$ ip as-path access-list 1 permit ^3216_20485_[0-9]*$ ip as-path access-list 1 permit ^3216_8359_[0-9]*$ ip as-path access-list 1 permit ^3216_702_[0-9]*$ ip as-path access-list 1 permit ^3216_701_[0-9]*$ ip as-path access-list 1 permit ^3216_1239_[0-9]*$ ip as-path access-list 1 permit ^3216_1273_[0-9]*$ ip as-path access-list 1 permit ^3216_1273_3257_10912_10912_10912_[0-9]*$ ip as-path access-list 1 permit ^3216_3549_[0-9]*$ route-map setlocalin_Golden permit 10 match as-path 1 set local-preference 110

Здравствуйте! В нашей сети имеются два граничных маршрутизатора Cisco 7206VXR-G2 и 7204VXR-G2. Каждый из этих маршрутизаторов подключен к своему UpStream-у и получает по eBGP от него Full View. Также маршрутизаторы соединены между собой прямым каналом где поднят iBGP. В такой схеме работы нас все устраивало до тех пор пока по независящим от нас причинам нам не перерубили на несколько часов кабель между маршрутизаторами (т.е. линк с iBGP). В результате наша сеть оказалась разделена на две не сообщающиеся между собой части, до момента восстановления канала. В свете возникшей проблемы, мне руководством была поставлена задача организовать резервный канал через UpStream-ов, но без аренды дополнительных физических каналов. Решение мне видится в организации туннеля между интерфейсами 7206 и 7204 подключенными к UpStream-ам. (Жизненная ли это схема?) Конфиг для 7206 interface Tunnel0 bandwidth 20000 ip address 192.168.2.9 255.255.255.252 delay 100 tunnel source FastEthernet2/0 tunnel destination YYY.YYY.137.6 /*интерфейс на 7204 tunnel mode ipip tunnel bandwidth transmit 18000 tunnel bandwidth receive 18000 max-reserved-bandwidth 90 interface GigabitEthernet0/1 description This interface connect to 7204VXR-G2 ip address ZZZ.ZZZ.161.145 255.255.255.252 /*внутренний линк который резервируется interface FastEthernet2/0 description UpStream1 Internet Exit ip address VVV.VVV.52.245 255.255.255.252 router bgp AS_OUR no bgp enforce-first-as bgp log-neighbor-changes neighbor ZZZ.ZZZ.161.146 remote-as AS_OUR neighbor VVV.VVV.52.246 remote-as AS_UpStream1 neighbor VVV.VVV.52.246 description UpStream1 maximum-paths 2 address-family ipv4 neighbor ZZZ.ZZZ.161.146 activate neighbor ZZZ.ZZZ.161.146 next-hop-self neighbor ZZZ.ZZZ.161.146 weight 100 neighbor ZZZ.ZZZ.161.146 soft-reconfiguration inbound neighbor VVV.VVV.52.246 activate neighbor VVV.VVV.52.246 send-community both neighbor VVV.VVV.52.246 remove-private-as neighbor VVV.VVV.52.246 weight 100 neighbor VVV.VVV.52.246 soft-reconfiguration inbound neighbor VVV.VVV.52.246 route-map UpStream1_out out neighbor VVV.VVV.52.246 filter-list 5 out maximum-paths 2 no auto-summary no synchronization network ZZZ.ZZZ.160.0 mask 255.255.252.0 exit-address-family ip route YYY.YYY.137.6 255.255.255.255 FastEthernet2/0 ip as-path access-list 1 permit ^AS_UpStream2$ ip as-path access-list 5 permit ^$ route-map TEST permit 10 match as-path 1 set weight 300 route-map TEST permit 20 set weight 100 route-map UpStream1_out permit 10 set local-preference 130 set as-path prepend AS_OUR Конфиг для 7204 interface Tunnel0 bandwidth 20000 ip address 192.168.2.10 255.255.255.252 delay 100 tunnel source FastEthernet0/0 tunnel destination XXX.XXX.52.245 /*интерфейс на 7206 tunnel mode ipip tunnel bandwidth transmit 18000 tunnel bandwidth receive 18000 max-reserved-bandwidth 90 interface FastEthernet0/0 description UpStream2 Internet Exit ip address YYY.YYY.137.6 255.255.255.252 interface GigabitEthernet0/1 description This interface connect to 7206VXR-G2 ip address ZZZ.ZZZ.161.146 255.255.255.252 /*внутренний линк который резервируется router bgp AS_OUR bgp log-neighbor-changes neighbor ZZZ.ZZZ.161.145 remote-as AS_OUR neighbor YYY.YYY.137.5 remote-as AS_UpStream2 neighbor YYY.YYY.137.5 description UpStream2 maximum-paths 2 maximum-paths ibgp 2 address-family ipv4 neighbor ZZZ.ZZZ.161.145 activate neighbor ZZZ.ZZZ.161.145 next-hop-self neighbor ZZZ.ZZZ.161.145 weight 110 neighbor ZZZ.ZZZ.161.145 soft-reconfiguration inbound neighbor ZZZ.ZZZ.161.145 route-map TEST in neighbor YYY.YYY.137.5 activate neighbor YYY.YYY.137.5 send-community neighbor YYY.YYY.137.5 remove-private-as neighbor YYY.YYY.137.5 weight 100 neighbor YYY.YYY.137.5 soft-reconfiguration inbound neighbor YYY.YYY.137.5 route-map UpStream2_out out neighbor YYY.YYY.137.5 filter-list 5 out maximum-paths 2 maximum-paths ibgp 2 no auto-summary no synchronization network ZZZ.ZZZ.160.0 mask 255.255.252.0 exit-address-family address-family nsap maximum-paths 2 no synchronization exit-address-family ip route VVV.VVV.52.245 255.255.255.255 FastEthernet0/0 ip as-path access-list 1 permit ^AS_UpStream1$ ip as-path access-list 5 permit ^$ route-map TEST permit 10 match as-path 1 set weight 300 route-map TEST permit 20 set weight 110 route-map UpStream2_out permit 10 set local-preference 130 set as-path prepend AS_OUR Однако в такой конфигурации мне не удается настроить такой резервный канал т.к. в зависимости от состояния таблиц маршрутизации BGP, то один интерфейс, то другой становятся недоступными. В связи с этим прошу помочь разобраться с проблемой и посоветовать как лучше решить возникшую проблему. С Уважением, Виктор

Здравствуйте! Пытаюсь решить следующую задачу: имеются маршрутизаторs 7204VXR-G2 и 7206VXR-G2 соединенные между собой прямым линком с поднятым iBGP (коннект на адреса Loopback0). Каждый маршрутизатор принимает от апстрима Full BGP таблицу. Другим интерфейсом каждый маршрутизатор смотрит во внутреннюю сеть где на нескольких Catalyst 3550 поднят EIGRP. Необходимо организовать резервный канал на случай повреждения оптического кабеля (специфика такова, что при повреждении кабеля (уже были прецеденты) вся сеть "разрезается" практически пополам, т.к. линки между 7206-7204 и 3550-3550 проходят по одному кабелю). Для этих целей я пытаюсь настроить нешифрованный туннель через сети апстримов, однако опыты показали что туннель работает только через наши собственные линки. конфиг CISCO 7204VXR-G2 interface Tunnel0 bandwidth 20000 ip address xxx.xxx.160.153 255.255.255.252 delay 100 tunnel source FastEthernet0/0 tunnel destination zzz.zzz.52.245 tunnel mode ipip tunnel bandwidth transmit 18000 tunnel bandwidth receive 18000 max-reserved-bandwidth 90 interface Loopback0 ip address 172.16.2.1 255.255.255.0 interface FastEthernet0/0 description upstream2 ip address yyy.yyy.137.6 255.255.255.252 interface GigabitEthernet0/1 description link between 7206 and 7204 (рвется при повреждении) ip address xxx.xxx.161.146 255.255.255.252 router eigrp 1 passive-interface FastEthernet0/0 passive-interface Loopback0 network xxx.xxx.160.112 0.0.0.3 (к ближайшей 3550 через нее есть рвущийся линк на третью 3550 и далее на 7206) network xxx.xxx.160.152 0.0.0.3 (туннель) network xxx.xxx.161.144 0.0.0.3 (прямой линк между 7204 и 7206 - рвется при повреждении) network 172.16.2.0 0.0.0.255 (loopback) network 192.168.2.4 0.0.0.3 (еще одна удаленная 3550 - рвется при повреждении) ip route 0.0.0.0 0.0.0.0 yyy.yyy.137.5 конфиг CISCO 7204VXR-G2 interface Tunnel0 bandwidth 20000 ip address xxx.xxx.160.154 255.255.255.252 delay 100 tunnel source FastEthernet2/0 tunnel destination yyy.yyy.137.6 tunnel mode ipip tunnel bandwidth transmit 18000 tunnel bandwidth receive 18000 max-reserved-bandwidth 90 interface Loopback0 ip address 172.16.1.1 255.255.255.0 interface GigabitEthernet0/1 description link between 7206 and 7204 (рвется при повреждении) ip address xxx.xxx.161.145 255.255.255.252 interface FastEthernet2/0 description upstream1 ip address zzz.zzz.52.245 255.255.255.252 router eigrp 1 passive-interface FastEthernet0/0 passive-interface FastEthernet0/1 passive-interface FastEthernet1/0 passive-interface FastEthernet2/0 passive-interface Loopback0 network xxx.xxx.160.152 0.0.0.3 (туннель) network xxx.xxx.161.64 0.0.0.3 (вторая ближняя 3550 через нее есть рвущийся линк на 7204) network xxx.xxx.161.144 0.0.0.3 (прямой линк между 7204 и 7206 - рвется при повреждении) network xxx.xxx.161.244 0.0.0.3 (к ближайшей 3550 через нее есть второй рвущийся линк на третью 3550 и далее 7204) network 172.16.1.0 0.0.0.255 (loopback) ip route 0.0.0.0 0.0.0.0 zzz.zzz.52.246 Подскажите где ошибка в конфигурации, т.к. при повреждении кабеля пропадают анонсы как iBGP, так и EIGRP между маршрутизаторами 7204/7206 и EIGRP между 3550. При этом туннель "падает" и не устанавливается через апстримов. P.S. Арендовать доп каналы или вкладывать средства в прокладку второго маршрута прошу не рекомендовать. Спасибо.