Отзывчивый CLI в IOS

Многие привыкли, что команды в IOS отрабатывают сразу после изменения конфигурации, но это не относится к операциям, связанных с настройкой группы интерфейсов на коммутаторе, где конфигурация разрослась до неприличных 100кбайт.
Например, если дать какую-то команду для стека из восьми 3750, то можно:
- потерять управление устройством из-за сброса терминальной сессии;
- потерять возможность изменения настроек в течение времени

Unable to get configuration. Try again later.

Маршрутизаторы с CUCME могут достаточно длительное время генерировать XML конфигурации для телефонов.
Самый интересный момент, конечно же, связан с последовательным выполнением команд, когда при старте правила AAA применились, а до настроек интерфейсов и конфигураций терминальных линий еще не дошло из-за того, что в какой-то момент не смогла зачитаться база dhcp snooping'а из-за особенности в работе файловой системы.

p.s.
Как мне не хватает Junos CLI в Cisco IOS :)

Супервизоры и флешки

По какой-то малообъяснимой причине в супервизорах II-PLUS-10GE, V-10GE для коммутаторов 4500-серии в отличии от супервизора 6L-E в качестве файловой системы носителей (в том числе и внешних CF ) используется Low End File System, а не FAT. Как следствие, освобождение места на флешке после удаления файлов производится командой squeeze:

C4500#squeeze bootflash:
All deleted files will be removed. Continue? [confirm]
Squeeze operation may take a while. Continue? [confirm]

Squeeze of bootflash complete
C4500#

Это грозит тем, что на носителях невозможно будет записать базу dhcp snooping'а, а иначе получится следующее:

C4500(config)#ip dhcp snooping database bootflash:/dhcp.snoop

Некоторое время спустя:

C4500#show bootflash: all
-#- ED ----type---- --crc--- -seek-- nlen -length- ---------date/time--------- name
1   .. image        FC388696  BD0F08   33 12127880 Mar 15 2011 17:21:00 +07:00 cat4500-ipbase-mz.122-31.SGA8.bin
2   .. image        39CC993A 1A50E78   32 15204080 May 10 2011 02:50:11 +08:00 cat4500-ipbase-mz.122-50.SG8.bin
3   .D unknown      1D7659E2 1A50F28   10       47 May 10 2011 11:00:52 +08:00 dhcp.snoop
4   .D unknown      1040190D 1A5102C   10      129 May 19 2011 11:01:39 +08:00 dhcp.snoop
[все повторяется]
3633 .D unknown      2E1B36D9 3AB8078   10    11035 Jun 21 2011 04:46:21 +08:00 dhcp.snoop
3634 .D unknown      C3E99271 3ABAC14   10    11035 Jun 21 2011 04:51:49 +08:00 dhcp.snoop
3635 .. unknown      2FEA18B7 3ABD7B0   10    11035 Jun 21 2011 04:58:16 +08:00 dhcp.snoop
3636 E. unknown      CC66E02C 3AC0000   10    10192 Jun 21 2011 05:03:27 +08:00 dhcp.snoop

1 bytes available (61341696 bytes used)

-------- F I L E   S Y S T E M   S T A T U S --------
  Device Number = 0
DEVICE INFO BLOCK: bootflash
  Magic Number          = 6887635   File System Vers = 10005    (1.5)
  Length                = 3B00000   Sector Size      = 20000
  Programming Algorithm = 6         Erased State     = FFFFFFFF
  File System Offset    = 40000     Length = 3A80000
  MONLIB Offset         = 100       Length = 2AE40
  Bad Sector Map Offset = 3FFC5     Length = 3B
  Squeeze Log Offset    = 3AC0000   Length = 20000
  Squeeze Buffer Offset = 3AE0000   Length = 20000
  MONLIB Version        = 0        (0.0)
  Num Spare Sectors     = 0
    Spares:
STATUS INFO:
  Writable
  NO File Open for Write
  Complete Stats
  No Unrecovered Errors
  No Squeeze in progress
USAGE INFO:
  Bytes Used     = 3A80000  Bytes Available = 1
  Bad Sectors    = 0       Spared Sectors  = 0
  OK Files       = 3       Bytes = 1A13894
  Deleted Files  = 3632     Bytes = 1FF859C
  Files w/Errors = 1       Bytes = 27D0

Коммутатор обреcетился и при старте не смог зачитать bootflash. Учитесь на чужих ошибках!
После танцев с бубном заработало, конечно. Но осадок остался.

Упаковка STP при использовании QinQ

Читал сегодня документацию по vpls и наткнулся на команду l2protocol-tunnel stp.
Есть схема, в которой два коммутатора соединены темным волокном и дополнительно арендуется l2 у оператора. Оператор обеспечивает MTU 1536 и тем самым гарантирует, что упакованные клиентом vlan'ы и, как следствие, увеличенные до 1522 байт ethernet-фреймы будут переданы от точки до точки. Отдельно хочу обратить внимание, что наличие транка с оператором обязательно, если есть необходимость резервирования средствами STP протокола, а не только средствами динамических протоколов маршрутизации. Если оператор отдает услугу access портом, то можно дальше не читать. Access порт в любом случае снимет все теги. Сначала ваш access-порт снимет оба тега, потом оператор вставит во фрейм свой, потом в удаленной точке снимет его и ваш коммутатор вставит собственный. Но это уже будет фрейм с одним тегом, а не двумя. Главное помнить о таких очевидных вещах, чтобы не получилось недоразумений.



Транк с темным волокном на коммутаторе "А":

interface GigabitEthernet1/0/1
 description *** Fiber optic ***
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100,200,300
 switchport mode trunk
 switchport nonegotiate
 mls qos trust dscp

Стык c оператором на коммутаторе "А", когда номер vlan'а согласуется с оператором:

interface GigabitEthernet1/0/2
 description *** ISP ***
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 345
 switchport mode trunk
 speed 100
 duplex full
 no lldp transmit
 no lldp receive
 no cdp enable
 spanning-tree bpdufilter enable

Петля (пачкордом соединены два порта) для упаковки собственных vlan'ов в операторский. Надо зарезервировать 100 и 200 vlan'ы. Увеличена цена STP, чтобы канал использовался только при пропадании волокна:

interface GigabitEthernet1/0/23
 description *** LOOP TUNNELING ***
 switchport access vlan 345
 switchport mode dot1q-tunnel
 l2protocol-tunnel stp
 no lldp transmit
 no lldp receive
 no cdp enable
interface GigabitEthernet1/0/24
 description *** LOOP TUNNELING ***
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100,200,400
 switchport mode trunk
 no lldp transmit
 no lldp receive
 no cdp enable
 spanning-tree cost 200

Настройки STP:

spanning-tree mode rapid-pvst
spanning-tree vlan 100,200,300,400 priority 24576

Предполагается, что коммутатор "B" настроен аналогично, за исключением STP, так как приоритеты должны все-таки отличаться.

Проверка STP :

switchA#sh spanning-tree vlan 100
[skip]
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Desg FWD 4         128.1   P2p
Gi1/0/24            Desg FWD 200       128.24  P2p

switchB#sh spanning-tree vlan 100
[skip]
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1             Root FWD 4         128.1    P2p
Gi1/0/24            Altn BLK 200       128.24   P2p

Без l2protocol-tunnel stp резервирование средствами STP было бы невозможно. Моментально бы получилась петля со всеми вытекающими.

Netflow для рутины

- Можете посмотреть кто грузит канал?
- Минуточку...

Здесь не пойдет речь о коллекторах и прочих радостях операторов связи. Если надо быстро проанализировать трафик - достаточно сделать так.
Определяем направление трафика. Например, входящий трафик для сети (10.0.10.0/24) обратившегося с жалобой проходит через интерфейс Gi0/2, а исходящий через Gi0/1.100
На обоих интерфейсах включается накопление статистики (flows) по входящему в интерфейс маршрутизатора трафика:

interface gi0/2
 ip flow ingress
interface gi0/1.100
 ip flow ingress

Далее настраивается фильтр top-talker:

ip flow-top-talkers
 top 30
 sort-by bytes

Вывод команд приводить не стану в этот раз.

router#show ip flow top-talkers
[выборка из кэша по заданным условиям]
router#show ip cache flow
[просмотр кэша]

Более интересно использовать top-talkers, когда статистика собирается со всех интерфейсов и надо выбрать какое-то конкретное направление:

ip flow-top-talkers
 top 20
 sort-by bytes
 match destination address 10.0.10.0 255.255.255.0
 match input-interface GigabitEthernet0/2
 match output-interface GigabitEthernet0/1.100

Учтите, что кэш хранится на маршрутизаторе определенное время. В случае необходимости можете настроить коллектор flow-tools для анализа статистики на сервере. Это на случай, если у вас попросят данные за прошедший период.
Если тема интересна, то может вам пригодится и моя старая статья.

Привязка телефонии к интерфейсу

Для маршрутизаторов, выполняющих роль шлюзов ip-телефонии, необходимо выполнить привязку (bind) сервисов телефонии к конкретному адресу/интерфейсу.

Для протокола H323:

interface Loopback0
 ip address 10.0.0.10 255.255.255.255
 h323-gateway voip bind srcaddr 10.0.0.10

Для протокола SIP:

voice service voip
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco
 h323
 sip
  bind control source-interface Loopback0
  bind media source-interface Loopback0

Для протокола SCCP с разными сервисами:

sccp local GigabitEthernet0/0
sccp ccm 10.10.10.100 identifier 1 version 7.0
sccp
!
sccp ccm group 1
 bind interface GigabitEthernet0/0
 associate ccm 1 priority 1
 associate profile 1 register confdsp1
 keepalive retries 16
 keepalive timeout 10


telephony-service
 sdspfarm units 1
 sdspfarm tag 1 confdsp1
 conference hardware
 max-ephones 262
 max-dn 720
 ip source-address 10.10.10.100 port 2000
[skip]

Туннели в Juniper SRX

Межсетевые экраны Juniper SRX в отличие от Cisco ASA поддерживают IPIP и GRE туннели. Конечно, благодаря унифицированной операционной системе Junos.
Дополнительная инкапсуляция сказывается на MTU, а значит на работе приложений, работающих по протоколу TCP. У туннелей в junos предусмотрен функционал удаления DF-бита, который не позволяет дефрагменировать пакеты, а так же функционал, который ограничивает максимальный размер сегмента в TCP пакете (maximum segment size (MSS)) по крайней мере в GRE.
Туннель GRE в Cisco IOS:

interface Tunnel0
 description *** to SRX ***
 bandwidth 10000
 ip address 10.1.1.1 255.255.255.252
 ip mtu 1452
 ip tcp adjust-mss 1000
 tunnel source 100.200.300.400
 tunnel destination 400.300.200.100

Туннель GRE в Junos:

set interfaces gr-0/0/0 unit 0 tunnel source 400.300.200.100
set interfaces gr-0/0/0 unit 0 tunnel destination 100.200.300.400
set interfaces gr-0/0/0 unit 0 family inet mtu 1452
set interfaces gr-0/0/0 unit 0 family inet address 10.1.1.2/30

set security flow tcp-mss gre-out mss 1000
set security flow tcp-session no-syn-check-in-tunnel

Примеры для Junos