Нестандартные VPI/VCI

Заметка для себя:
Иногда бывает, что провайдер выдает нестандартные значения VPI/VCI. (VPI>31 или VCI > 1023). Решается очень просто:
atm vc-per-vp 512 (например).
Подробности здесь:
http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00801086c5.shtml

Juniper for Security Platforms

Сейчас изучаю Juniper for Security Platforms Student's Guide и вижу такой опус:
IPSec supports both unicasts and multicasts traffic.
Однако, ещё из курса Cisco ISCW известно, что "IPmc is not supported with IPsec Direct Encapsulation. IPsec was created to be a security protocol
between two and only two devices, so a service such as multicast is problematic.". Примерно то же говорит RFC 2401. Понятно, конечно, что в Juniper используется IPSec over GRE (точее, route-based ipsec vpn через интерфейс st), однако об этом прямо не сказано, зачем же людей путать?
Спустя несколько дней:
Выясняются ещё более интересные подробности:

A route-based VPN is required for which scenario?
A. when the remote VPN peer is behind a NAT device
B. when multiple networks need to be reached across the tunnel and GRE cannot be used
C. when the remote VPN peer is a dialup or remote access client
D. when a dynamic routing protocol is required across the VPN and GRE cannot be used
Answer: D

Т.е это не GRE. Тогда мне совсем не ясно как это работает.

Cisco Bugs #1

In the past i was working closely with Mikrotik RouterOS and was thinking what it is full of bugs. I have found lot of them and was sending bugreports to the developers every week. Nowadays I'm working with Cisco products and they not free from bugs too. Today i have found a new one, it gave me a lot of inconvenience and trouble caused. I hope you will not find yourself in my place if you read this note.
 

Let's look at this mac access filter:
mac access-list extended bridge_in
permit any host 000c.4209.536b
permit any host 0007.b359.6b60
permit any host 0007.b359.6b61
permit any host 0013.c39a.7c10
permit any host 0013.c39a.7c11
permit any host ffff.ffff.ffff
!


This filter was used on Catalyst 2960 with c2960-lanbasek9-mz.122-40.SE (also tested with c2960-lanbasek9-mz.122-52.SE.bin)

What do you think, should it block all OSPF multicast (0100.5e00.0005, 0100.5e00.0006) and prevent routers from forming OSPF neighbor adjacencies? Answer is YES. But this is not working on this switch. Maybe this is feature?



Let's look at the another switch - Catalyst 2950 with c2950-i6k2l2q4-mz.121-22.EA10a.bin
Here was used this mac access list:
mac access-list extended bridge_in
permit any host 000c.4203.4ca5
permit any host ffff.ffff.ffff
permit any host 000c.421c.f855
!


And it is working! Routers is not forming OSPF neighbor adjacencies because OSPF multicasts are blocked.


Updated:

another funny bug with Catalyst 2960 (IOS 122(40)):

sw#show clock
10:14:42.496 MSK Sun Oct 25 2009

sw#reload at 04:00 26 oct
Reload scheduled for 19:40:34 MSK Tue Dec 8 2009 (in 1065 hours and 26 minutes) by admin on vty0 (192.168.0.1)
Proceed with reload? [confirm]
sw#show reload
No reload is scheduled.





 

Вычисление оптимального MTU и MSS для TCP/IP траффика в сетях VPN

Фрагментация пакетов - обычно это лишняя нагрузка для маршрутизатора. Чтобы посмотреть статистику и выяснить, какое количесво пакетов фрагментированно маршрутизатором Cisco, можно воспользоваться командой show ip traffic. Для того, чтобы избежать фрагментации и некоторых других проблем, вызванных ей и невозможностью, например, доставки сообщений ICMP fragmentation needed, MTU для Ethernet-фреймов и MSS для данных TCP-сегмента должны быть оптимальными. Встает вопрос - как правильно их рассчитать?
Пример:
1500 байт - стандартный размер MTU (Для Ethernet фрейма размером 1518 байт - 1500 + 14 MAC заголовок + 4 FCS)
- 20 байт - IP заголовок
- 4 байт - заголовок туннеля GRE
- 8 байт - заголовок PPPoE
- 20 байт - заголовок TCP
- 52 байта - заголовок IPSec туннельном режиме
или
- 32 байта - заголовок IPSec в транспортном режиме


Выполним подсчёт MTU и MSS для удаленного офиса, подключенного к интернет по протоколу PPPoE в случае использования DMVPN:

(Макс. MTU) - [ (GRE Encaps) + (IPSec Transport) + (PPPoE) ] = ( MTU )
(1500) - [ ( 24 ) + ( 32 ) + ( 8 ) ] = ( 1436 )

(Макс. MTU) - [ (GRE Encaps) + (IPSec Transport) + (PPPoE) + ( TCP ) + ( IP ) ] = ( MSS )
(1500) - [ ( 24 ) + ( 32 ) + ( 8 ) + ( 20 ) + ( 20 ) ] = ( 1396 )

P.S. Заголовки следуют в следующем порядке:
PPPoE - IPSec - GRE - original IP - TCP ...

P.P.S Если нет ip tcp ajust-mss или неправильно выставлено значение ip mtu, а на ingress интерфейсе стоит no ip unreachables - могут быть проблемы с фрагментацией, т.к. ICMP fragmentation needed не будет приходить (PMTUD не работает). Точнее не будут прихоить сообщения ICMP destination unreachable с соответствующим кодом.

Конфигурация для возврата к исходному состоянию

Бывает такое, что нужно провести полную реконфигурацию маршрутизатора (например, с помощью скрипта загрузить на несколько однотипных удаленных маршрутизаторов новый startup-config по tftp и перезагрузиться, чтобы не вычищать тонны мусора, оставшиеся от предыдущей конфигурации). Однако, людям свойственно ошибаться, и в некоторых случаях новые параметры могут оказаться неработоспособными. Для этого я разработал следующую конфигурацию:
Задаем параметры ip sla, будем отслеживать состояние IP адреса 192.168.0.44 - доступен ли он (успешно доставлены 10 icmp-echo с таймаутом 2000 мс):
ip sla 100
icmp-jitter 192.168.0.44 num-packets 10
timeout 2000
frequency 5

ip sla мониторинг запустим через 5 минут, чтобы избежать неверных
срабатываний (например, маршрутизатор ещё не поднял pppoe соединение):
ip sla schedule 100 life forever start-time after 00:05:00

object-id 15 будет отслеживать событие изменения состояния ip sla:
track 15 rtr 100 reachability
delay down 180

Изменение состояния объекта на down сделаем с задержкой 3 минуты (180 сек.), чтобы объект имел возможность восстановиться (icmp-echo пакеты пройдут) и избежать ложного срабатывания. Далее создаем аплет, который по состоянию down объекта c id 15 будет выполнять не интерактивные команды, заданные в action. Т.к. команды не интерактивные, нам потребуется выполнить дополнительную настройку (1.2 – 1.4), а затем скопировать предварительно сохраненные файлы конфигурации и затем перезагрузиться. failed-config нужен для последующего анализа:
event manager applet IfPingFailed
event track 15 state down
action 1.0 syslog msg "Ping has failed, reverting configuration!"
action 1.1 cli command "enable"
action 1.2 cli command "configure terminal"
action 1.3 cli command "file prompt quiet"
action 1.4 cli command "end"
action 2.0 cli command "copy startup-config failed-config"
action 3.0 cli command "copy backup-config startup-config"
action 4.0 reload

Добавлено. В результае долгих экспериментов выяснил, что если такая конфигурация используется первый раз, например, когда вы загружаете startup-config по tftp и затем перезагружаете маршрутизатор, object trackig имеет состояние down сразу же после загрузки маршрутизатора. Соответственно состояние не меняется и возврат к исходному состоянию не происходит. Я вылечил это так:
event manager applet schedule_script
event timer countdown time 60
action 0.0 syslog msg "Tiggering rollback script!"
action 1.0 cli command "enable"
action 2.0 cli command "configure terminal"
action 3.0 cli command "no event manager applet schedule_script"
action 4.0 cli command "end"
action 5.0 cli command "write"
action 6.0 reload

Этот апплет удаляет сам себя, сохраняет конфигурацию и перезагружает маршрутизатор. Приследующей загрузке object tracking уже нормально срабатывает

Храните деньги в сберегательной кассе

Знаете кто такой гик? Или может быть просто профессионально наметанный глаз? Вот пример: идёте вы в банк, чтобы открыть депозит. Конечно, перед этим внимательно изучили условия договора, процентную ставку, приняли решение в каком банке лучше всего открыть свой счёт... Итак, Вы в заурядном офисе банка, который был выбран не в последнюю очередь за довольно близкое местоположение относительно вашего микрорайона. Осматриваемся по сторонам - офис достаточно новый, однако выглядит каким-то неряшливым: возможно из-за того, что это отделение было открыто в вашем микрорайоне совсем недавно и сотрудники недосовершили переезд. Несколько банкоматов, разбросанная по столам для посетителей реклама, кучки бумаг на столах у менеджеров. С потолка в некоторых местах свисают сопли витой пары (хотя короба, как положено, проложены к рабочим местам). Ну да ладно... Это всё мелочи. Для того, чтобы открыть счёт Вам требуется внести некоторую сумму в кассу - Вы подходите к окошку, отдаете деньги и смотрите как девушка-кассир выписывает Вам приходный ордер. Скучающим взглядом вы окидываете внутреннее помощение и... видите за её спиной настенный телекоммуникационный шкафчик! Он притягивает ваше внимание, пока девушка неторопливо возится с вашими деньгами и вбивает что-то в компьютер. В нем (в шкафчике) стоит какой-то древний коммцутатор L2 Dlink, абсолюно никаких патчпанелей, патчкорды смотаны в ужасный моток. Хуже того - ниже, под шкафчиком Вы замечаете каких-то два странных системных блока (наверное, сервера ;)). У Вас складывается хорошее впечатление о такой IT-инфраструктуре? А если вы 2 дня назад посетили подобный офис, но другого банка, отличие которого от данного в том, что у абсолютно такой же девочки-кассира за спиной висит полочка с Cisco 1841, идеальный порядок в офисе, однако процент по вкладам всего лишь на 1,25 менее того, в котором Вы находитесь сейчас?

BCMSN Self Study Guide ошибки

Люблю находить ошибки в книгах. Когда находишь их, чувствуешь, что ты становишься экспертом (наивно) и в чем-то превосходишь автора или хотя бы редактора...

Вот, пример, на странице 238 сабжа:

Set port cost Switch(config)# spanning-tree [vlan vlan-id] cost cost

Set port priority Switch(config)# spanning-tree [vlan vlan-id] port-priority
port-priority

На самом деле стоимость и приоритет для порта указывается в режиме конфигурации интерфейса, а не в режиме глобальной конфигурации:

Set port cost Switch(config-if)# spanning-tree [vlan vlan-id] cost cost

Set port priority Switch(config-if)# spanning-tree [vlan vlan-id] port-priority port-priority

И вот ещё на странице 590:

After a switch receives news of a topology change, how long does it wait to ush entries from
its CAM table?
Answer: The switch flushes entries immediately instead of employing the timer reduction that
802.1D uses.

Имелось ввиду flush, очистка, а не "ush".

Затем на странице 372 есть такая фраза по поводу DSCP:

The relationship is confusing, and Table 14-2 should
be a handy aid.

Однако таблица 14-2 относится к PoE. Имелась ввиду таблица 14-4.

И снова на странице 395 опечатка:

...naïve user sending...