Configuring Floating Summary Routes

You can use a floating summary route when configuring the ip summary-address eigrp command. This enhancement was introduced in Cisco IOS Release 12.2. The floating summary route is created by applying a default route and administrative distance at the interface level. 

The default summary route is applied to interface with the following configuration:  

Router(config)# interface  
Router(config-if)# ip summary-address eigrp 10 0.0.0.0 0.0.0.0

The configuration of the default summary route on Router-1 sends a 0.0.0.0/0 summary route to Router-2 and blocks all other routes, including the all route, from being advertised to Router-2. However, this also generates a local discard route on Router-1, a route for 0.0.0.0/0 to the null 0 interface with an administrative distance of 5. When this route is created, it overrides the EIGRP learned default route. Router-1 will no longer be able to reach destinations that it would normally reach through the 0.0.0.0.0/0 route. 

This problem is resolved by applying a floating summary route to the interface on Router-1 that connects to Router-2. The floating summary route is applied by applying an administrative distance to the default summary route on the interface of Router-1 with the following statement: 

Router(config-if)# ip summary-address eigrp 10 0.0.0.0 0.0.0.0 250

  The administrative distance of 250, applied in the above statement, is now assigned to the discard route generated on Router-1. The 0.0.0.0/0 is learned through EIGRP and installed in the local routing table. Routing to Router-2 is restored.

The summary address is not advertised to the peer if the administrative distance is configured as 255

http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfeigrp.html
http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/command/ire-i1.html
http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_eigrp/configuration/xe-3s/asr1000/ire-cfg-eigrp.html#GUID-6A20D55E-4611-4FC7-9CF4-EC7ACA5DF440

Измерение ширины LFN канала

LFN (Long Fat Network) - сеть обладающая большой пропускной способностью и большим временем задержки. Например, спутниковые или WiMAX каналы.

Чтобы получить адекватные значения пропускной способности каналов такого типа с использованием TCP, нужно иметь ввиду, что настройки TCP по умолчанию скорее всего не позволят это сделать. В windos os TCP Window Size определяется согласно данного алгоритма. Полученное значение не обеспечивает полную загрузку канала на широких линках с большой задержкой.

При тестировании LFN сетей с помощью TCP для достижения  максимальной пропускной способности канала необходимо на конечных узлах тестирования менять TCP Window size в соответствии с пропускной способностью и задержкой  тестируемого канала.
 Расчет размера окна производится по формуле:

TCP window size (kBytes)  ≥ Bandwidth (KBytes/sec) *  packet RTT (sec)

Также для удобства расчетов TCP window size можно воспользоваться этим инструментом.

Оптимальным методом тестирования максимальной пропускной способности канала является передача UDP потока со скоростью заведомо превышающей скорость канала.

Алгоритм тестирования LFN:

iperf -c 10.0.0.1 -i 10 -u -b50M -d -f k -t 600

Расчет пропускной способности канала:
http://en.wikipedia.org/wiki/Bandwidth_test

 

16 кб размер окна   100 мс задержка RTR 

16 kbyte*8=128 kbit

128000 bit/0,05c=2 560 000bit/s= 2,56 Mb/c                       100mc/2=50 mc (one way delay)



Почему нельзя полагаться на измерения полосы пропускания, полученные от стандартных программных средств? 

На скорость работы приложений может влиять очень много факторов. Один из основных - для передачи данных многие приложения используют протокол TCP, в котором есть ряд параметров, которые могут существенно влиять на скорость его работы, например размер "окна". Данный параметр определяет, сколько данных может передать отправитель без получения подтверждения об их приеме от получателя. В идеальном случае, "окно" должно расти до тех пор, пока не достигнет максимально возможного для данного канала размера. Но в каждой операционной системе этот алгоритм реализован по-разному. В Windows'XX, например, стек TCP/IP оптимизирован под применение в локальных сетях, со скоростями ~10Mbit/s и задержками ~1-70ms. Если RTT превышает указанный промежуток, размер "окна" не увеличивается, а значит остается значение по умолчанию (например MS - 8KB, Solaris - 24KB и т.д.). Даже если "окно" увеличивается, то в Windows 2000 max TcpWindowsSize равно 17520 байт, что при задержке Москва - Владивосток в ~130ms дает максимально возможную скорость передачи для одной TCP сессии между Window's машинами ~135КБ/c(~1Мбит/c). С помощью настроек в реестре Windows можно несколько улучшить ситуацию, но, к сожалению, незначительно. В UNIX-системах ситуация немного лучше.

Public iperf server:

iperf.eltel.net

Источник: http://ciao-cacao.blogspot.com/search/label/Performance

http://iperf.comcor.ru/

SNMP ifIndex

 Фиксация и определение номера интерфейса в IOS

При использовании систем управления удобно иметь возможность ссылаться на интерфейсы по номеру, который сохраняется даже после перезагрузки устройства. Начиная с Cisco IOS Release 12.1(5) эту возможность обеспечивает Interface Index Persistence feature.

Для включения данной функциональности нужно выполнить либо глобальную команду:

R(config)# snmp-server ifindex persist

Либо локальную на интерфейсе:

R(config)# interface type slot/port
R(config-if)# snmp ifindex persist

Определить номер интерфейса можно командой
R# show snmp mib ifmib ifindex type slot/port

R#show snmp stats oid

R#show snmp mib

Источник http://ciao-cacao.blogspot.com/2011/03/blog-post_23.html

Denial of Service Tuning for Cisco IOS Software Firewall and IPS

Cisco IOS Stateful Packet Inspection provides protection from DoS attacks as a default when an inspection rule is applied. The DoS protection is enabled on the interface, in the direction in which the firewall is applied, for the protocols that the firewall policy is configured to inspect. DoS protection is only enabled on network traffic if the traffic enters or leaves an interface with inspection applied in the same direction of the traffic's initial movement. Cisco IOS Firewall inspection provides several adjustable values to protect against DoS attacks. These settings have default values that may interfere with proper network operation if they are not configured for the appropriate level of network activity in networks where connection rates will exceed the defaults:

ip inspect max-incomplete high value (default 500)

ip inspect max-incomplete low value (default 400)

ip inspect one-minute high value (default 500)

ip inspect one-minute low value (default 400)

ip inspect tcp max-incomplete host value (default 50) [block-time minutes (default 0)]

These parameters allow you to configure the points at which your firewall router's DoS protection begins to take effect. When your router's DoS counters exceed the default or configured values, the router will reset one old half-open connection for every new connection that exceeds the configured max-incomplete or one-minute high values, until the number of half-open sessions drops below the max-incomplete low values. The router will send a syslog message if logging is enabled, and if an intrusion prevention system (IPS) is configured on the router, the firewall router will send a DoS signature message via Security Device Event Exchange (SDEE). If the DoS parameters are not adjusted to your network's normal behavior, normal network activity may trigger the DoS protection mechanism, causing application failures, poor network performance, and high CPU utilization on the Cisco IOS Firewall router.
While you cannot "disable" your firewall's DoS protection, you can adjust the DoS protection so that it will not take effect unless a very large number of half-open connections are present in your firewall router's Stateful Inspection session table.
Follow this procedure to tune your firewall's DoS protection to your network's activity:

Step 1. Be sure your network is not infected with viruses or worms that could lead to erroneously large half-open connection values and attempted connection rates. If your network is not "clean", there is no way to properly adjust your firewall's DoS protection.

Step 2. Set the max-incomplete high values to very high values:

ip inspect max-incomplete high 20000000

ip inspect one-minute high 100000000

ip inspect tcp max-incomplete host 100000 block-time 0

This will prevent the router from providing DoS protection while you observe your network's connection patterns. If you wish to leave DoS protection disabled, stop following this procedure now.

Step 3. Clear the Cisco IOS Firewall statistics, using the following command:

show ip inspect statistics reset

Step 4. Leave the router configured in this state for some time, perhaps as long as 24 to 48 hours, so you can observe the network's pattern over a full day's activity cycle.

Note: While the values are adjusted to very high levels, your network will not benefit from Cisco IOS Firewall or IPS DoS protection.

Step 5. After the observation period, check the DoS counters with the following command. The parameters you must observe to tune your DoS protection are highlighted in bold:

router#show ip inspect statistics

Packet inspection statistics [process switch:fast switch]

tcp packets: [528:22519]

udp packets: [318:0]

Interfaces configured for inspection 1

Session creations since subsystem startup or last reset 766

Current session counts (estab/half-open/terminating) [1:0:0]

Maxever session counts (estab/half-open/terminating) [48:12:5]

Last session created 00:12:21

Last statistic reset never

Last session creation rate 0

Last half-open session total 0

Step 6. Configure "ip inspect max-incomplete high" to a value 25-percent higher than your router's indicated maxever session count half-open value. A 1.25 multiplier offers 25-percent headroom above observed behavior.

For example:

Maxever session count (estab/half-open/terminating) [920:460:331]

460 * 1.25 = 575

Thus, configure:

router(config)#ip inspect max-incomplete high 575

Step 7. Configure "ip inspect max-incomplete low" to the value your router displayed for its maxever session count half-open value.

For example:

Maxever session counts (estab/half-open/terminating) [920:460:331]

Thus, configure:

router(config)#ip inspect max-incomplete low 460

Step 8. The counter for "ip inspect one-minute high" and "one-minute low" maintains a sum of all TCP, UDP, and Internet Control Message Protocol (ICMP) connection attempts during the preceding minute of the router's operation, whether the connections have been successful or not. A rising connection rate could be indicative of a worm infection on a private network, or an attempted DoS attack against a server.

Cisco IOS Software does not maintain a value of the maxever one-minute connection rate, so you must calculate the value you will apply based on observed maxever values. While the maximum indicated values for established, half-open, and terminating sessions are unlikely to occur in the same instant, the calculated values used for the one-minute settings have been observed to be reasonably accurate. To calculate the ip inspect one-minute low value, add the indicated "established" value by three.

For example:

Maxever session counts (estab/half-open/terminating) [920:460:331]

920 * 3 = 2760

Thus, configure:

ip inspect one-minute low 2760

Step 9. Calculate and configure "ip inspect one-minute high". The ip inspect one-minute high value should be 25-percent greater than the calculated one-minute low value.

For example:

ip inspect one-minute low (2760) * 1.25 = 3450

Thus, configure:

ip inspect one-minute high 3450

Step 10. You will need to define a value for "ip inspect tcp max-incomplete host" according to your understanding of your servers' capability.

Step 11. Monitor your network's DoS protection activity. Ideally, you should use a syslog server and record occurrences of DoS attack detection. If detection happens very frequently, you may need to monitor and adjust your DoS protection parameters.

источник: http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5708/ps5710/ps1018/prod_white_paper0900aecd804e5098.html

Резервирование каналов СПД

В качестве примера рассмотрен вариант с одним основным каналом точка-точка L2VPN и резервным каналом через интернет провайдера.

В качестве основного канала выхода в интернет используется канал интернет провайдера.

Роутер Office-MSK анонсирует по EIGRP роутеру Remote-Office суммарные маршруты корпоративной сети и дефолт-роут 0.0.0.0/0

На роутере Remote-Office статикой настроен дефолт-роут 0.0.0.0/0 через шлюз провайдера с метрикой ниже чем дефолт-роут 0.0.0.0/0 от роутера Office-MSK и отслеживание доступности шлюза провайдера.

Логика работы:
трафик в корпоративную сеть идет через EIGRP маршруты полученные от роутера Office-MSK, так как эти маршруты являются more-specific по сравнению с дефолт-роутом до шлюза провайдера.
Трафик в сети для которых нет записей в таблице маршрутизации маршрутизируется через  дефолт-роут 0.0.0.0/0 шлюза провайдера.

В случае отказа в работе основного канала l2vp в таблице маршрутизации роутера Remote-Office удаляются маршруты изученные по EIGRP, таким образом весь трафик маршрутизируется через дефолт-роут 0.0.0.0/0 шлюза провайдера.

В случае отказа в работе интернет канала  в таблице маршрутизации роутера Remote-Office удаляется дефолт-роут 0.0.0.0/0 шлюза провайдера(так как настроено отслеживание доступности шлюза провайдера), после чего в таблицу маршрутизации добавляется дефолт-роут 0.0.0.0/0 от роутера Office-MSK изученный по EIGRP и находящейся в eigrp topology table. Таким образом  трафик для которого отсутствуют маршруты в таблице маршрутизации маршрутизируется через дефолт-роут 0.0.0.0/0 роутера Office-MSK


UPD:
для трекинга роута лучше использовать:


ip sla 1
 icmp-jitter 10.0.0.1 source-ip 10.0.0.2 num-packets 20 interval 200
 timeout 2000
 frequency 30

track 111 rtr 1 state

Warm Reload

This is a new feature in 12.3 that enables the router to perform a reboot using the IOS image currently running in DRAM. Having this capability greatly reduces boot time (no decompression or copying from slow flash) and reduces down-time when the router is returned to ROM by a bug. It also enables us to reboot the router even if we don’t have a valid IOS image in flash.
However, for warm-reboot to be active the router has to be cold-rebooted at least once after it’s configured.
With this command “warm-boot”, comes two options. The first is “count” which configures the maximum number of warm-reboots after which the router will perform a cold reboot. The second keyword is “uptime” which configures the time after which warm-reboot will be safe in case of a crash.


R1(config)#warm-reboot count 10


источник http://anetworkerblog.com/2007/11/04/a-warm-reload/

Troubleshooting Drop

Проверка буферов ASIC:

show platform port-asic stats drop

Проверка TCAM:

show platform tcam utilization

Загрузка шины:

show controllers utilization

show platform hardware capacity

CCNA Voice 640-460 (draft notice)

Loop start signaling

Anytime the phone is on-hook, the phone separates the two wires, preventing electric signal from flowing through the phone. When the phone is lifted off-hook, the phone connects the two wires, causing an electrical signal (48V DC voltage) to flow from the phone company central office (CO) into the phone. This is known as loop start signaling.

Supervisory Signaling

In addition to using the of properties of electric signals to generate voice traffic, analog phones are responsible for accepting and sending multiple types of signaling. The first type of signaling the phone handles is considered supervisory signaling. Supervisory signaling handles the following:

•  On-hook signal: When the phone is on-hook, the connection between the tip andring wires is broken and no electrical signal passes between them.
• Off-hook signal: When the phone is off-hook, the phone connects the tip and ring wires, completing the circuit and allowing electrical signal to pass.
• Ringing: To cause an analog phone to ring, the phone company sends an alternating current (AC) signal down one of the wires, which the phone detects and generates aring signal.

Informational Signaling

Once the analog phone generates an off-hook signal, the phone company responds by using informational signaling to generate a dial tone. Informational signaling uses specific electrical frequencies to send a plethora of information to the caller. The following events are results of informational signaling:

• Dial tone: Indicates the phone company is ready to receive digits
• Busy: Indicates the remote phone is already in use
• Ringback: Indicates the remote phone is currently ringing
• Congestion: Indicates the long-distance telephone network is not able to complete the call
• Reorder: Indicates the local telephone company is not able to complete the call
• Receiver off-hook: Indicates the local receiver has been off-hook for an extended period of time
• No such number: Indicates the dialed number is invalid
• Confirmation: Indicates the telephone company is attempting to complete the call

The phone company generates each of these informational signals using well-known electrical frequencies for the local region (country). All analog phones operating within the same country should have identical informational signals.

Address Signaling

Once the phone company has used informational signaling to generate a dial tone signal, the user can dial digits. There are two types of address signaling in use worldwide:

• Dual-tone multifrequency (DTMF): The buttons on a telephone keypad use a pair of high and low electrical frequencies (thus “dual-tone”) to generate a signal each time a caller presses a digit. DTMF is the predominant signal type used in the United States.
• Pulse: The rotary-dial wheel of a phone connects and disconnects the local loop circuit as it rotates around to signal specific digits.

The Evolution: Digital Connections

Analog signaling was a massive improvement over tin cans and string, but still posed plenty of problems of its own. First, an analog electrical signal experiences degradation (signal fading) over long distances. To increase the distance the analog signal could travel, the phone company had to install repeaters (shown in Figure 1.6) to regenerate the signal as it became weak.

Unfortunately, as the analog signal was regenerated, the repeater device was unable to differentiate between the voice traveling over the wire and line noise. Each time the repeater regenerated the voice, it amplified the line noise as well. Thus, the more times a phone company regenerated a signal, the more distorted and difficult to understand the signal became.

The second difficulty encountered with analog connections was the sheer number of wires the phone company had to run to support a large geographical area or a business with a large number of phones. Because each phone required two wires, the bundles of wire became massive and difficult to maintain (imagine the hassle of a single pair of wires in the bundle breaking). A solution to send multiple calls over a single wire was needed. A digital connection is that solution.

Sending Multiple Calls over a Single Line

Now, let’s come back to the original problems of analog connections:

• The signal degrades over long distances.
• You can’t send multiple calls over a single line (resulting in massive cabling requirements).

Digitizing voice solves the first problem because you can easily transmit a numeric valu any distance a cable can run without any degradation or line noise. Time-division multiplexing (TDM) solves the second problem.

TDM allows voice networks to carry multiple conversations at the same time over a single, four-wire path. Because the multiple conversations have been digitized, the numeric values are transmitted in specific time slots (thus the “time-division”) that differentiate the separate conversations. Figure 1.10 illustrates three separate voice conversations sent over a digital connection.

Corporations use digital voice connections to the PSTN as T1 circuits in the United States, Canada, and Japan. A T1 circuit is built from 24 separate 64-kbps channels known as a digital signal 0 (DS0). Each one of these channels is able to support a single voice call. Corporations in areas outside the United States, Canada, and Japan use E1 circuits, which allow you to use up to 32 DS0s for voice calls.

Two primary styles of signaling were created for digital circuits:

• Channel associated signaling (CAS): Signaling information is transmitted using the same bandwidth as the voice. Uses the eighth bit on every sixth sample in each T1channel (DS0)
• Common channel signaling (CCS): Signaling information is transmitted using a separate, dedicated signaling channel.

When using CCS configurations with T1 lines, the 24th time slot is always the signaling channel. When using CCS configurations with E1 lines, the 17th time slot is always the signaling channel.

The Pieces of the PSTN

• Analog telephone: Able to connect directly to the PSTN and is the most common device on the PSTN. Converts audio into electrical signals.
• Local loop: The link between the customer premises (such as a home or business) and the telecommunications service provider.
• Central office (CO) switch: Provides services to the devices on the local loop. These services include signaling, digit collection, call routing, setup, and teardown.
• Trunk: Provides a connection between switches. These switches could be CO or private.
• Private switch: Allows a business to operate a “miniature PSTN” inside its company.This provides efficiency and cost savings because each phone in the company does not require a direct connection to the CO switch.
• Digital telephone: Typically connects to a PBX system. Converts audio into binary 1s and 0s, which allows more efficient communication than analog.

Understanding PBX

Many businesses have hundreds or even thousands of phones they support in the organization. If the company purchased a direct PSTN connection for each one of these phones, the cost would be astronomical. Instead, most organizations choose to use a private branch exchange (PBX) or key system internally to manage in-house phones. These systems allow internal users to make phone calls inside the office without using any PSTN resources. Calls to the PSTN will forward out the company’s PSTN trunk link.

When you first look at a PBX system, it looks like a large box full of cards. Each one of

these cards has a specific function:

• Line cards: Provide the connection between telephone handsets and the PBX system.
• Trunk cards: Provide connections from the PBX system to the PSTN or other PBX systems.
• Control complex: Provides the intelligence behind the PBX system; all call setup, routing, and management functions are contained in the control complex.

PSTN Numbering Plans

Just as data networks use IP addressing to organize and locate resources, voice networks use a numbering plan to organize and locate telephones all around the world. 

Organizations managing their own, internal telephony systems can develop any internal number scheme that best fits the company needs (similar to private IP addressing). 

However, when connecting to the PSTN, you must use a valid, E.164 standard address for your telephone system. E.164 is an international numbering plan created by the International Telecommunication Union (ITU). Each number in the E.164 numbering plan contains the following components:

• Country code
• National destination code
• Subscriber number

E.164 numbers are limited to a maximum length of 15 digits

Characterizing and Tracing Packet Floods

A DoS Characterization Access List

Picture a router with two interfaces. Ethernet 0 is connected to an internal LAN at a business or small ISP. Serial 0 provides an Internet connection via an upstream ISP. The input packet rate on serial 0 is "pegged" at the full link bandwidth, and hosts on the LAN run slowly, crash, hang, or show other signs of a DoS attack. The small site at which the router connects has no network analyzer, and the people there have little or no experience in reading analyzer traces even if the traces are available.   

Now, assume that you apply an access list as this output shows:

access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any
access-list 169 permit tcp any any established
access-list 169 permit tcp any any
access-list 169 permit ip any any

interface serial 0
ip access-group 169 in

This list does not filter out any traffic at all; all the entries are permits. However, because it categorizes packets in useful ways, the list can be used to tentatively diagnose all three types of attacks: smurf, SYN floods, and fraggle. 

Источник: http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080149ad6.shtml

BGP: Community, link bandwidth.

BGP Link Bandwidth это фича, которая нужна для того что бы сделать балансировку трафика на выходе из вашей AS, причем балансировка будет делаться пропорционально исходя из bandwidth линка.
 Для того что бы включить эту фичу необходимо в адресном семействе включить bgp dmzlink-bw и на каждом соседе прописать send-community both.

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftbgplb.html#wp1058373 

http://admindoc.ru/1368/bgp-community-link-bandwidth/ 

http://xgu.ru/wiki/%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_BGP_%D0%B4%D0%BB%D1%8F_%D1%80%D0%B5%D0%B7%D0%B5%D1%80%D0%B2%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82-%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D0%BE%D0%B2#.D0.91.D0.B0.D0.BB.D0.B0.D0.BD.D1.81.D0.B8.D1.80.D0.BE.D0.B2.D0.BA.D0.B0_.D1.81_.D1.83.D1.87.D0.B5.D1.82.D0.BE.D0.BC_.D0.BF.D1.80.D0.BE.D0.BF.D1.83.D1.81.D0.BA.D0.BD.D0.BE.D0.B9_.D1.81.D0.BF.D0.BE.D1.81.D0.BE.D0.B1.D0.BD.D0.BE.D1.81.D1.82.D0.B8_.D0.BA.D0.B0.D0.BD.D0.B0.D0.BB.D0.B0

Supervisor Engine Redundancy

RPR—первый режим избыточности, введенный в программное обеспечение Cisco IOS. В режиме RPR конфигурация автозагрузки и загрузочные регистры синхронизируются между активным модулем и модулем Supervisor в ждущем режиме, модуль в ждущем режиме инициализируется не полностью, и образы на активном модуле Supervisor и модуле Supervisor в ждущем режиме не обязательно должны быть одинаковыми. При переключении модуль Supervisor в ждущем режиме становится активным автоматически, но должен выполнить процесс загрузки. Кроме того, все линейные карты перезагружаются, и оборудование перепрограммируется.
Время переключения режима RPR равно 2 или более минутам. RPR+ — улучшение режима RPR, при котором модуль Supervisor в ждущем режиме полностью загружен и линейные карты не перезагружаются при переключении. Рабочая конфигурация синхронизируется между активным модулем и модулем Supervisor в ждущем режиме. Все действия по синхронизации, унаследованные от режима RPR также выполняются. Синхронизация выполняется перед переключением, и информация, синхронизируемая на модуле в ждущем режиме, используется, когда модуль в ждущем режиме становится активным, для снижения времени простоя. Данные уровня канала передачи данных и элементов управления между активным и ждущим модулем Supervisor Engine не синхронизируются. Интерфейсы временно могут не работать после переключения, и содержимое оборудования необходимо перепрограммировать. Время переключения режима RPR+ равно 30 или более секундам. Реальное время перехода на другой ресурс при сбое зависит от размера и сложности конфигурации. NSF/SSO — и программное обеспечение Cisco IOS, и CatOS поддерживают режим бесперебойной коммутации (NSF) с сохранением состояний (SSO). Ключевая разница заключается в том, когда и как применяются эти функции, поскольку наиболее серьезное развитие они получили сначала в Cisco IOS. SSO расширяет возможности режима RPR+, обеспечивая прозрачную отказоустойчивость протоколов уровня 2 при сбое модуля Supervisor. SSO обеспечивает отслеживание состояния соединений для протоколов уровня 2. При переключении сохраняются данные таблиц оборудования PFC и DFC. Это позволяет осуществить прозрачный переход на другой ресурс при сбое на уровне 2 и уровне 4. Режим бесперебойной коммутации (NSF) и SSO работают совместно, обеспечивая целостность уровня 3 после переключения. Это позволяет маршрутизаторам, испытывающим проблемы с активным модулем Supervisor, продолжать пересылку пакетов данных по известным маршрутам, в то время как информация о протоколах маршрутизации восстанавливается и проверяется. Данная пересылка может продолжаться за счет перезапуска механизмов, обеспечивающих передачу одноранговых настроечных сообщений при переходе на другой ресурс при сбое. Это позволяет избежать ненужных отклонений от маршрутов и нестабильности сети. Время перехода на другой ресурс при сбое составляет от 0 до 3 секунд при использовании NSF/SSO.
 Важно:
 для SSO необходимо соответветсвие IOS image на активном и избыточном супервизоре.
 В случае проблемм с %Error show slavedisk0: (Invalid DOS media or no media in slot) выполнить #format slavedisk0: и после чего скопировать IOS Image на резервный супервизор возможно появления сообщения: %PFREDUN-SP-4-BOOTSTRING_INVALID: The bootfile slavebootflash:image_name is not present in standby
(With correctly configured redundant Supervisor Engine 720s, this erroneous message might be displayed after a reload)

 Команды:
  redundancy
   keepalive-enable 
    mode sso
      main-cpu 
         auto-sync running-config


#redundancy reload peer перезагрузка избыточного супервизора
#show redundancy вывод общей информации

 Enable the console of the standby supervisor on Cisco routers By default, the console of the standby supervisor on Cisco routers is disabled. If for any reason you need to enable it, do the following: router#conf t 
router(config)#redundancy 
router(config-red)#main-cpu 
router(config-r-mc)#standby console enable




Performing a Software Upgrade

iBGP Multipath Load Sharing

Command:
Router(config-router)# maximum-paths ibgp maximum-number 
Purpose:
Controls the maximum number of parallel iBGP routes that can be installed in a routing table.

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ftbgpls.html

BGP: Route Refresh

Route Refresh убирает тот недостаток, который есть в soft outbound (когда нам нужно было заходить на маршрутизатор соседний и делать clear ip bgp * out), теперь можно попросить этого соседа переслать всю таблицу ADJ-RIB-out. Делается это не просто, а очень просто:
 clear ip bgp [* | ip | peer-gorup] in
 После этой команды соседу посылается Route Refresh сообщение с просьбой переслать маршруты, после получение соседом, он отправляет BGP маршруты. Таким образом все происходит плавно, без обрывов TCP соединения. Такой способ эффективнее, чем soft in/out. Этот способ так же не требует дополнительной памяти.
 Route Refresh, это возможность, которая согласуется на этапе отправки Open сообщения, по умолчанию все должно согласоваться и такая возможность у вас будет.
 Чтобы проверить это необходимо сделать:
 AS1#sh ip bgp neighbors 200.200.200.200 
 BGP neighbor is 200.200.200.200, remote AS 2, external link Description: toR2 BGP version 4, remote router ID 200.200.200.200 BGP state = Established, up for 3d21h Last read 00:00:46, last write 00:00:46, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(old & new) Address family IPv4 Unicast: advertised and received

Capability  согласована и поддерживается. Значит все будет работать.

Источник http://admindoc.ru/1248/bgp-route-refresh/

BGP: soft reconfiguration

Когда мы изменяем конфигурацию секцию BGP, например когда прописали новый префикс лист, то он сразу не применится, так как нужно перезапросить маршруты, делаем мы стандартно это так: clear ip bgp * , думаю все знают, что делает эта команда. Она полностью обрывает все соседние отношения (TCP сессию), обнуляет полностью таблицу BGP, и все заново происходит.
Если соседей не много, и они посылают не много маршрутов это пол беды, но если соседей много, и маршрутов от них очень много, здесь конечно уже это серьезная нагрузка на роутер. Да и вобще, не очень красиво это как-то :) То есть нам нужно как минимум оставлять TCP сессию и перезапрашивать или переотправлять маршруты соседям.

BGP предоставляет 4 выхода из этой ситуации.
 1. Cisco механизм, который называется soft reconfigureation 
 2. BGP route refrash 
 3. Outbound route filtering 
 4. route dampening 


  Soft Reconfiguration.
При включении этой опции на соседе (как это делается, посмотрим ниже), мы создаем область памяти, где будут хранится все маршруты от данного пира, без каких-либо модификаций (то есть будут находиться до фильтров, префикс листов и прочего). И когда, нам нужно перезапросить данные о маршрутах соседа, мы можем это делать из этой области памяти, и далее пуская эти данные через различные фильтры, мапы и прочее.
 Итак, конфигурируется это так:
 neighbor 1.1.1.1 soft-reconfiguration inbound
 После этого все маршруты от соседа 1.1.1.1 будут сохранены в отдельной области памяти. Теперь нам необходимо перезапросить маршруты из этой области, далается так:
 clear ip bgp [* | ip address | peer-group] soft in
 После этого не будет разорвана TCP сессия, и даже не будет обращения к соседу за маршрутами, все возмется из области памяти, которую мы создали выше. Тут есть один и очень большой минус, это то, что под каждого пира нам необходимо еще выделять область памяти, а если маршрутов много, то это не маленький расход памяти. Но в небольших сетях это вполне работоспособный и правильный вариант.
 Это мы рассмотрели inbound reconfiguration, вторым подвидом является outbound configuration Outbound активировать не нужно, он работает по умолчанию и им можно пользоваться. Он так же не использует дополнительную память, так как использует ADJ-Rib-Out
 Пользоваться так же просто: clear ip bgp [* | ip | peer-group] soft out
 Эта команда рассылает соседу (пир группе, или всем) маршруты из своей ADJ-RIB-out без обрыва TCP сессии. Плюсы очевидны. А минус, это то что Вам нужно заходить на этот маршрутизатор и делать soft-rec out, не всегда это можно использовать. В заключение по этому методу хотелось бы отметить как посмотреть таблицу при использовании soft in? (то есть таблицу до филтров, роут мапов и так далее).
 show ip bgp neighbors 1.1.1.1 received-routes 
После route-map, фильтров, префиксов и прочего:
 show ip bgp neighbors 1.1.1.1 routes 
И соответсвенно до исходящих route-map, фильтров и т.п.:
 sh ip bgp
 И после:
 show ip bgp neighbors 1.1.1.1 advertised-routes

Источник http://admindoc.ru/1244/bgp-soft-reconfiguration

Route Dampening

Route Flap Dampening - (начал использоваться в CISCO Internetwork
Operating System [Cisco IOS] Release 11.0])
- это механизм предотвращения нестабильности
работы роутеров, основанный на flap dampening'е.

Route dampening is a BGP feature designed to minimize the propagation of flapping routes across an internetwork. The values the ISP recommended are the defaults on Cisco IOS® and you only need to configure this command in order to enable it.
router bgp "AS number"
bgp dampening

The bgp dampening commandsets default values for the dampening parameters such as Halftime= 15 minutes, reuse = 750, Suppress = 2000 and Max Suppress Time= 60. These values are user configurable but Cisco recommends that it remains unchanged.
(http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800945fe.shtml)

Для описания Route Flap Dampening'а используются следующие термины:

Penalty - Числовое значение, которое присваивается маршруту, когда роутер flaps

Half-life time - Числовое значение, которое устанавливается в конфигурации и означает время которое должно пройти с момента поднятия линка, и ведущее к уменьшению panalty вполовину.

Suppress limit - Числовое значение, с которым сравнивается panalty. Если penalty больше, чем suppress limit, то маршрут считается недоступным и отбрасывается.

Suppressed - маршрут, который не анонсируется, даже если он "UP". Маршрут считается Suppressed, если Penalty больше Suppress Limit.

Reuse limit - Числовое значение, устанавливаемое в процессе конфигурации. Это значение сравнивается с Penalty; Если Penalty меньше Reuse Limit, то Suppressed маршрут, если он UP в настоящий момент, больше не будет замораживаться (то есть считается размороженным).

History entry - запись, которая используется для сохранения flap information о маршрутах, которые down.

Маршруты, которые flapping, получают 1000 penalty за каждый flap. Когда накопленный таким образом penalty привысит установленный в конфигурации предел (Suppress Limit), BGP приостанавливает анонсирование данного маршрута, даже если в этот момент маршрут является рабочим (я его назвал UP). Накопленный penalty уменьшается вдвое по истечении half-life time. Если после этого оказывается, что penalty "reuse limit" , маршрут начинает анонсироваться опять (если он UPв этот момент, конечно).

Замечание: Dampening не применяется к маршрутам, которые
получены по IBGP.
Это ограничение предотвращает forwarding loops
и как бы защищает IBGP peer'ы от имеющих бОльшие penalty у
маршрутов, которые являются внешними к данной AS.

http://subnets.ru/wrapper.php?p=7#xtocid2375345

SNMP Monitoring BGP sessions status

1.3.6.1.2.1.15.3.1.2.ip.ip.ip.ip - Managed objects for BGP v4
Just replace IP with the ip of the bgp neighbor

Superior references

1.3.6.1.2.1.15 - BGPv4
1.3.6.1.2.1 - SNMP MIB-2
1.3.6.1.2 - IETF Management
1.3.6.1 - OID assignments from 1.3.6.1 - Internet
1.3.6 - US Department of Defense
1.3 - ISO Identified Organization
1 - ISO assigned OIDs

Possible SNMP Output

1 = IDLE
2 = CONNECT
3 = ACTIVE
4 = OPENSENT
5 = OPENCONFIRM
6 = ESTABLISHED

Trigger Example for zabbix:
{host2:1.3.6.1.2.1.15.3.1.2.ip.ip.ip.ip.last(0)}#6

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.2.1.15.3.1.2

ICMP and NAT

Идентификатор и номер очереди могут использоваться отправителем для соотнесения сообщений (запросов) и ответов на них. На пример, идентификатор может использоваться в качестве порта, аналогично протоколам TCP и UDP, для идентификации сессии. Номер очереди может увеличиваться на единицу при каждой посылке сообщения (запроса). Адресат возвращает для этих параметров те значения, которые были обнаружены в запросе. И шлюз и хост-компьютер могут возвращать сообщения с кодом 0.






Note the number 24320 in the translation table above. It is the ICMP ident value included in the ICMP header of the IP datagram

Switchport Host

Use a macro configuration command to force a switch port to support a single host. The following command enables STP PortFast, sets the port to access (non-trunking) mode, and disables PAgP to prevent the port from participating in an EtherChannel:

Switch(config)# interface type mod/num
Switch(config-if)# switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled

STP

Types of STP

STP was originally developed to operate in a bridged environment, basically supporting a single LAN (or one VLAN). Implementing STP into a switched environment has required additional consideration and modification to support multiple VLANs.



Common Spanning Tree

The IEEE 802.1Q standard specifies how VLANs are to be trunked between switches. It also specifies only a single instance of STP that encompasses all VLANs. This instance is referred to as the Common Spanning Tree (CST). All CST BPDUs are transmitted over trunk links using the native VLAN with untagged frames.

Having a single STP for many VLANs simplifies switch configuration and reduces switch CPU load during STP calculations. However, having only one STP instance can cause limitations, too. Redundant links between switches will be blocked with no capability for load balancing. Conditions also can occur that would cause CST to mistakenly enable forwarding on a link that does not carry a specific VLAN, whereas other links would be blocked.

Per-VLAN Spanning Tree

Cisco has a proprietary version of STP that offers more flexibility than the CST version.
Per-VLAN Spanning Tree (PVST) operates a separate instance of STP for each individual VLAN. This allows the STP on each VLAN to be configured independently, offering better performance and tuning for specific conditions. Multiple spanning trees also make load balancing possible over redundant links when the links are assigned to different VLANs. One link might forward one set of VLANs, while another redundant link might forward a different set.

Because of its proprietary nature, PVST requires the use of Cisco Inter-Switch Link (ISL) trunking encapsulation between switches. In networks where PVST and CST coexist, interoperability problems occur. Each requires a different trunking method, so BPDUs are never exchanged between STP types.

Per-VLAN Spanning Tree Plus

Cisco has a second proprietary version of STP that allows devices to interoperate with both PVST and CST. Per-VLAN Spanning Tree Plus (PVST+) effectively supports three groups of STP operating in the same campus network:

■ Catalyst switches running PVST
■ Catalyst switches running PVST+
■ Switches running CST over 802.1Q

To do this, PVST+ acts as a translator between groups of CST switches and groups of PVST switches. PVST+ can communicate directly with PVST by using ISL trunks. To communicate with CST, however, PVST+ exchanges BPDUs with CST as untagged frames over the native VLAN. BPDUs from other instances of STP (other VLANs) are propagated across the CST portions of the network by tunneling. PVST+ sends these BPDUs by using a unique multicast address so that the CST switches forward them on to downstream neighbors without interpreting them first. Eventually, the tunneled BPDUs reach other PVST+ switches where they are understood.


STP port state




STP Timers



Two types of BPDU exist:

■ Configuration BPDU, used for spanning-tree computation
■ Topology Change Notification (TCN) BPDU, used to announce changes in the net-
work topology


Topology Changes

To announce a change in the active network topology, switches send a TCN BPDU.

A topology change occurs when a switch either moves a port into the Forwarding state or moves a port from the Forwarding or Learning states into the Blocking state. In other words, a port on an active switch comes up or goes down. The switch sends a TCN BPDU out its root port so that, ultimately, the root bridge receives news of the topology change. Notice that the TCN BPDU carries no data about the change but informs recipients only that a change has occurred. Also notice that the switch will not send TCN BPDUs if the port has been configured with PortFast enabled.

Bridge ID




STP path cost




Sequence of four criteria that STP uses to choose a path:

1. Lowest bridge ID
2. Lowest root path cost
3. Lowest sender bridge ID
4. Lowest sender port ID


Tuning the Port ID

As an example, you can use the following command sequence to change the port priority of Gigabit Ethernet 3/16 from 128 (the default) to 64 for VLANs 10 and 100:

Switch(config)# interface gigabitethernet 3/16
Switch(config-if)# spanning-tree vlan 10,100 port-priority 64



Tuning the Root Path Cost

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


PortFast

Catalyst switches offer the PortFast feature, which shortens the Listening and Learning states to a negligible amount of time. When a workstation link comes up, the switch immediately moves the PortFast port into the Forwarding state. Spanning-tree loop detection is still in operation, however, and the port moves into the Blocking state if a loop is ever detected on the port.




UplinkFast: Access-Layer Uplinks

Consider an access-layer switch that has redundant uplink connections to two distribution-layer switches. Normally, one uplink would be in the Forwarding state and the other would be in the Blocking state. If the primary uplink went down, up to 50 seconds could elapse before the redundant uplink could be used.

The UplinkFast feature on Catalyst switches enables leaf-node switches or switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use.

When UplinkFast is enabled, it is enabled for the entire switch and all VLANs. UplinkFast works by keeping track of possible paths to the root bridge. Therefore, the command is not allowed on the root bridge switch. UplinkFast also makes some modifications to the local switch to ensure that it does not become the root bridge and that the switch is not used as a transit switch to get to the root bridge. In other words, the goal is to keep UplinkFast limited to leaf-node switches that are farthest from the root.

После включения UplinkFast на коммутаторе:

- приоритет увеличивается до 49152
- стоимость портов устанавливается равной 3000
- отслеживаются альтернативные корневые порты, на которых были получены сообщения hello от корневого коммутатора.

Если основной RP выходит из строя, то коммутатор сразу переключается на запасной и переводит его в состояние forward.
Кроме того, UplinkFast позволяет коммутаторам обновить записи в таблицах коммутации, без использования TCN. Вместо TCN коммутатор находит MAC-адреса всех локальных устройств и отправляет один multicast фрейм с каждым MAC-адресом в поле отправитель. Удаляются также остальные записи в таблицы коммутации самого коммутатора.


BackboneFast

Позволяет быстрее найти альтернативный путь, после изменения топологии. Для того чтобы функция работала, необходимо включить её на всех коммутаторах в сети.

sw(config)# spanning-tree backbonefast

Where PortFast and UplinkFast enable immediate transitions, BackboneFast can reduce the maximum convergence delay only from 50 to 30
seconds.




Permissible combinations on a switch port:
Loop guard and UDLD
Root guard and UDLD

Not permissible on a switch port:
Root guard and Loop guard
Root guard and BPDU guard

Режимы ретрансляции дейтаграмм

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

Process switching

Это наиболее медленный, но универсальный режим. В этом режиме поступившая в маршрутизатор дейтаграмма помещается в очередь и ожидает запуска процесса, который будет ее обрабатывать. Process switching выполняется в следующих случаях:
- необходим поиск маршрута в таблице маршрутов (необходимой информации нет в маршрутном кэше или маршрутный кэш не задействован - fast switching не включен);
- необходима проверка по списку доступа (фильтрация, маршрутизация по особым условиям);
- необходимы шифрование или сжатие дейтаграммы;
- в других случаях, когда требуются "нетривиальные" действия по обработке дейтаграммы.


CEF - Cisco Express Forwarding (Topology-based)

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

Кэш состоит из двух частей: базы данных FIB (Forward Information Base) и таблицы CAM (Content-addressable memory - ассоциативная память). FIB содержит соответствия между IP-адресами получателей и IP-адресами следующих маршрутизаторов. CAM - это таблица канальных адресов следующих маршрутизаторов (в частности, MAC-адресов Ethernet). Элемент FIB является ссылкой на строку в CAM.



Благодаря вынесению MAC-адресов в отдельную таблицу, база данных FIB не теряет актуальность при изменениях MAC-адресов следующих маршрутизаторов, что повышает производительность обработки дейтаграмм. Кроме того, такая организация кэша делает возможным распределение нагрузки между двумя и более каналами, ведущими к одной сети назначения.

Поскольку база данных FIB строится непосредственно при создании (модификации) таблицы маршрутов и включает в себя все известные маршруты, CEF не требует ретранслировать дейтаграмму в режиме process switching при отсутствии маршрутной информации в кэше. Если маршрутной информации в кэше нет, то дейтаграмма не может быть доставлена и уничтожается.

В маршрутизаторах серий 7ххх, начиная с IOS весии 12.0, CEF включен по умолчанию.

At times, however, a packet cannot be switched in hardware, according to the FIB. Packets then are marked as “CEF punt” and immediately are sent to the Layer 3 engine for further processing. Some of the conditions that can cause this are as follows:

■ An entry cannot be located in the FIB.
■ The FIB table is full.
■ The IP Time-To-Live (TTL) has expired.
■ The maximum transmission unit (MTU) is exceeded, and the packet must be fragmented.
■ An Internet Control Message Protocol (ICMP) redirect is involved.
■ The encapsulation type is not supported.
■ Packets are tunneled, requiring a compression or encryption operation.
■ An access list with the log option is triggered.
■ A Network Address Translation (NAT) operation must be performed (except on the
Catalyst 6500 Supervisor 720, which can handle NAT in hardware).