GRE/IPSEC терминация зад NAT

Да предположим , че ни трябва (по каквато и да било причина; ) ) site-to-site VPN, на който едната страна да е зад NAT. Следната диаграма илюстрира този сценарий:

GRE over IPSEC, terminating both behind NAT

GRE/IPSEC terminating behind NAT

Трябва да имаме IPSEC SA между RLeft и RRight и също така трябва да имаме GRE тунел между същите два рутера, върху тази IPSEC SA. IPSEC асоцияцията ще енкапсулира и защитава само GRE трафика за тунелния интерфейс.

Начални бележки

Ако искаме RRight да бъде зад NAT, има някои потенциални проблеми пред нормалната работа на IPSEC. Source адреса на пакетите от RRight се замества с публичното IP, което NATRouter използва за адресната транслация. Понеже RLeft не знае за никакви NAT-ове по пътя, той ще вижда пакети идващи от публичното NAT IP 172.16.20.3, а не от същинския интерфейс на RRight. Следователно, за да работят нещата нормално, RRight ще трябва да се аутентикира като 172.16.20.3, и поради тази причина трябва да вдинем loopback на RRight, който да държи този IP адрес. По същата причина, тази ситуация не би могла да работи с NAT interface overloading на NATRouter, когато NATRouter ще използва своя собствен интерфейс за публичен адрес при адресната транслация – в този случай адреса на loopback интерфейса на RRight би бил същия, като IP адреса на fa0/0 интерфейса на NATRouter, и в този случай ще има проблем с рутираните на пакетите обратно до RRight.

NAT traversal

IPSEC има вградена NAT-transparency функционалност, също известна на някои места кат “UDP wrapper”, или “UDP енкапсулация” – тази функционалност е включена по подразбиране от IOS 12.2(13)T нататък. Тази функционалност позволява на IPSEC крайните точки да засичат дали някъде по мрежата между тях има NAT. Това става, като си обменят хешове на source и destination IP адреса и порта, на всеки край на IPSEC Security Association-а. След това всеки от двата рутера рекалкулира хешовете локално, и ги сравнява с получените хешове от отсрещтната страна. Ако се появи разлика, значи адресите са били променени някъде по мрежата и следователно някъде по пътя има NAT. Следващата стъпка е да се договори изполването на NAT-T, при положение, че и двата рутера го поддържат. Последната (и може би нй-важна) стъпка е да се енкапсулира всеки IPSEC SA и ISAKMP пакет в нов UDP хедър. IPSEC NAT-T  използва UDP порт 4500.

Конфигурации

(more…)

Първоначалната спецификация на TCP

Интересно четиво, което ми попадна напоследък е първоначалната предложена спецификация на TCP протокола. Спецификацията е презентация на Винт Сърф и Робърт Кан от 1974г. когато по време на IEEE Transaction of Communications те предлагат дизайн на нов протокол за пакетна комутация. Документът се казва A protocol for packet network intercommunication и е интересен от гледна точка на първоначалните планове за протокола за пакетна комутация. В първоначален вид предложението включва само един протокол TCP, а по-късно следва разделянето на фунционалността между два протокола TCP и IP. Интересни са някои предвидени проблеми, както и доста разлики от сегашния му вид, вкл. размера на адресното пространство.

Cisco IOS banner константи

От Cisco IOS Release 12.0(3)T съществува опция за използване на константи в различните банери, настройвани на рутери. Константите се заменят от съответната фактическа стойност при показване на банера и могат да сочат към различни параметри на устройството или конфигурацията.

Възможните константи и тяхната поддържка в различните банери са описани в таблицата:

Банерконстанта
motd
login
exec
incoming
slip-ppp
Описание
$(hostname)
ДА
ДА
ДА
ДА
ДА
Хостнаме на устройството
$(domain)
ДА
ДА
ДА
ДА
ДА
Домейн
$(peer-ip)
НЕ
НЕ
НЕ
НЕ
ДА IP Address на отсрещното устройство
$(gate-ip)
НЕ
НЕ
НЕ
НЕ
ДА
IP Address на gateway-а
$(encap)
НЕ
НЕ
НЕ
НЕ
ДА тип на енкапсулацията
$(encap-alt)
НЕ
НЕ
НЕ
НЕ ДА Показване на енкапсулацията като SL/IP вместо SLIP.
$(mtu)
НЕ
НЕ
НЕ
НЕ
ДА
MTU на устройството
$(line)
ДА
ДА
ДА
ДА
НЕ Номер на линията на която влиза конекцията
$(line-desc)
ДА
ДА
ДА
ДА
НЕ Описание на линията, на която влиза конекцията

Пример за употребата на константата $(hostname):

R1(config)#banner login # You are connected to $(hostname). Authorized users only! #

Възможността е доста удобна в случай на приложение на банери на много устройства едновременно (с помощта на някакъв инструмент за автоматизация/управление на конфигурации, например Expect, или комерсиален като CiscoWorks).

BGP RIB Failure

BGP RIB-Failure е ситуация, при която маршрути от BGP базата данни не могат да бъдат инсталирани в главната рутинг таблица, по различни причини:

  • Маршрутът вече е инсталиран в маршрутната таблица с по-нисък administrative distance (напр. статичен маршрут или научен от вътрешен протокол);
  • Маршрутът е директно свързана мрежа (частен случай на по-ниският administrative distance);
  • Маршрутът е до IP адрес на получаващия рутер;
  • Инсталирането на този маршрут в рутинг таблицата ще надвиши лимита за маршрути, зададен на конкретен VRF (при наличие на VRF-и);
  • Проблем с паметта на рутера не позволява маршрутът да бъде инсталиран в таблицата;

В такива случаи, въпросните маршрути са маркирани с r>; в списъка на BGP маршрути, например:

R1#sh ip bgp
BGP table version is 9, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
r>i192.168.0.1/32   192.168.1.1              0    100      0 i
r>i192.168.1.0/30   192.168.1.1              0    100      0 i
*>i192.168.10.0     192.168.1.1              0    100      0 i
r>i192.168.30.0     192.168.1.1              0    100      0 i
R1#

Можем да прегледаме всички маршрути, които са в RIB-Failure статус с show ip bgp rib-failure :

R1#sh ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
192.168.0.1/32 192.168.1.1 Own IP address n/a
192.168.1.0/30 192.168.1.1 Higher admin distance n/a
192.168.30.0 192.168.1.1 Higher admin distance n/a
R1#

Ако прегледаме всяка една от тези три мрежи по отделно с show ip bgp няма да забележим нищо кой-знае колко повече:

R1#sh ip bgp 192.168.0.1/32
BGP routing table entry for 192.168.0.1/32, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(4) - next-hop mismatch)
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#sh ip bgp 192.168.1.0/30
BGP routing table entry for 192.168.1.0/30, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#sh ip bgp 192.168.30.0
BGP routing table entry for 192.168.30.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Advertised to update-groups:
1
Local, (received & used)
192.168.1.1 from 192.168.1.1 (192.168.10.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

Причините можем да установим ако прегледаме маршрутната таблица за всяка от тези мрежи:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

D    192.168.30.0/24 [90/156160] via 192.168.1.9, 01:40:21, FastEthernet2/0
B    192.168.10.0/24 [200/0] via 192.168.1.1, 01:46:46
C    192.168.255.0/24 is directly connected, FastEthernet1/0
192.168.0.0/32 is subnetted, 1 subnets
C       192.168.0.1 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 3 subnets
C       192.168.1.8 is directly connected, FastEthernet2/0
C       192.168.1.0 is directly connected, FastEthernet0/0
C       192.168.1.4 is directly connected, FastEthernet0/1
R1#

Виждаме, че за всеки от трите маршрута има данни в рутинг таблицата, като единият от тях е собственият IP адрес на R1, другият е научен по EIGRP, а третият е директно свързана мрежа през fa0/0. Въпреки, че тези BGP маршрути не са инсталирани в рутинг таблицата, те продължават да бъдат анонсирани към BGP peer-а на R1, за разлика от споменатото в BGP FAQ документа от Cisco. За илюстрация на ситуацията тестовата топология е изложена по-долу.

Sample topology for BGP RIB Failure

Sample lab for BGP RIB-Failure

В случая, R0 анонсира въпросните няколко мрежи в iBGP процеса към R1, за които R1 има по-добър маршрут от EIGRP (.30.0/24), директно свързани са (.1.0./30), или е собственият му IP адрес (.0.1/32). R1 от своя страна има eBGP сесия към R2. Нека прегледаме какво R2 получава по тази eBGP сесия и дали RIB-Failure маршрутите се анонсират към него:

R2#sh ip bgp
BGP table version is 5, local router ID is 192.168.20.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.0.1/32   192.168.1.5                            0 100 i
*> 192.168.1.0/30   192.168.1.5                            0 100 i
*> 192.168.10.0     192.168.1.5                            0 100 i
*> 192.168.30.0     192.168.1.5                            0 100 i
R2#

Както се вижда, всички RIB-Failure маршрути се анонсират и се приемат нормално по eBGP сесията независимо от RIB-Failure статуса им. Те не са в RIB-Failure състояние на R2 и са инсталирани в маршрутната таблица:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B    192.168.30.0/24 [20/0] via 192.168.1.5, 02:27:02
B    192.168.10.0/24 [20/0] via 192.168.1.5, 02:27:02
C    192.168.20.0/24 is directly connected, Loopback0
192.168.0.0/32 is subnetted, 1 subnets
B       192.168.0.1 [20/0] via 192.168.1.5, 02:27:02
192.168.1.0/30 is subnetted, 2 subnets
B       192.168.1.0 [20/0] via 192.168.1.5, 02:27:02
C       192.168.1.4 is directly connected, FastEthernet0/0
R2#

VRF Lite – VRF без MPLS

MPLS VRF-ите са едно колкото популярно, толкова и рекламирано решение за provider vpn-и и сегрегация на трафик в трета мрежа, което предлага и разчита на няколко неща, за да се продава 😉 :

  • Сегментиране на трафик между устройства на различни клиенти през трета мрежа, обикновено доставчик на услуга;
  • Възможност за запазване на маршрутната информация на клиента, чрез прозрачно пренасяне на маршрутната информация между неговите устройства от различните страни на мрежата на доставчика;
  • Възможност за доставчика да носи няколко маршрутни таблици, сегментирани една от друга, и евентуално включващи припокриващи се адресни пространства, вkл. RFC1918 адреси;

Решението за такава ситуация, базирано на MPLS VPN-и с различни VRF-и (Virtual Routing and Forwarding) разрешава всички от гореизброените проблеми на базата на няколко неща:

  • Настройка на маршрутно отношение между клиентският (Customer Edge – CE) рутер, и граничен рутер на доставчика (Provider Edge – PE), използвайки рутинг протокола на клиента;
  • Анонсиране от клиента на всички вътрешни мрежи по това рутинг отношение, както към вътрешен рутинг съсед в клиентската мрежа;
  • Наличие на поне една VRF инстанция за всеки клиент;
  • Маркиране от страна на PE устройството на клиентските маршрути със специфичен Route Distinguisher (RD) етикет, по този начин формирайки т.нар. VPNv4 адрес;
  • Редистрибуция от PE устройтвото на клиентските маршрути от клиентският рутинг протокол към MP-iBGP протокол, вървящ между PE устройствата в различните краища на мрежата на доставчика;
  • Наличие на стабилен вътрешен IGP рутинг протокол, осигуряващ свързаност на MPLS мрежата и косвено на MP-BGP;
  • Наличие на стабилна и мащабируема MPLS конфигурация в опорната мрежа на доставчика;

Всичко това е чудесно, ако сте доставчик, имащ готов MPLS Core. Ако обаче се опитвате да разработите специфично решение за собствени нужди, решение базирано на MPLS VPN ви изправя пред няколко предизвикателства, повечето от които са свързани с осигуряване на скъпи ресурси:

  • Настройка на 3 рутинг протокола на всяко PE-устройство (протокол на клиента, MP-BGP, и отделен вътрешен рутинг протокол);
  • Осигуряване  на достатъчно мощни и надеждни PE-рутери, способни да поддържат надеждно и мащабируемо 3те рутинг протокола, както и определен брой VRF-и;
  • Осигуряване на достатъчно мощни и надеждни core рутери, поддържащи MPLS Core на мрежата;

VRF Lite представлява VRF без изискване за опорна MPLS свързаност, и без необходимост от 3 рутинг протокола на PE устройствата. По този начин можем да постигнем пренос на няколко паралалелни рутинг таблици през опорна мрежа, без да имаме MPLS.

При използването на VRF с MPLS разделеността на комуникацията между рутинг таблиците се постига чрез използването на отделен рутинг протокол между PE устройствата, който носи различните маршрутни таблици, тагнати със съответният етикет. За да има разделяне на комуникацията и сегрегация на отделните рутинг таблици при използването на VRF Lite, т.е. без MPLS, трябва да има разделена комуникация между рутинг отношенията, носещи различните маршрутни таблици.

За илюстрация на двата варианта VRF, можем да използваме две топологии на тестови мрежи.

(more…)

“странни” команди при CISCO3825 boot

Доста се учудих като видях следните команди логнати при bootване на един рутер:

idx   sess           [email protected]      Logged command
1     1        [email protected]  |access-list 199 permit icmp host 10.10.10.10 host 20.20.20.20
2     1        [email protected]  |crypto map NiStTeSt1 10 ipsec-manual
3     1        [email protected]  |match address 199

4     1        [email protected]  |set peer 20.20.20.20

5     1        [email protected]  |exit
6     1        [email protected]  |no access-list 199
7     1        [email protected]  |no crypto map NiStTeSt1

В случая знам, че на конзолата няма и не е имало вързано нищо при стартирането на въпросното устройство… впоследствие след малко търсене се оказа, че въпросният crypto map е част от autotest-а на крипто акселератора при стартиране. 🙂

http://www.securityfocus.com/archive/75/474377/30/180/threaded

cable testing на cisco 3750

Catalyst 2960, 2970, 3560/3560-E, и 3750/3750-E суичовете имат вграден Time Domain Reflector (TDR), с който може да се тестват кабелите директно от порта на суича. TDR не се поддържа на 10Gig портове и на SFP-портове.

Пример:

 

SW01#test cable-diagnostics tdr interface gigabitethernet2/1
TDR test started on interface Gi2/1

A TDR test can take a few seconds to run on an interface

Use ‘show cable-diagnostics tdr’ to read the TDR results.
SW01#

SW01#sh cable-diagnostics tdr interface gig2/0/11
TDR test last run on: March 02 00:31:15

Interface Speed Local pair Pair length Remote pair Pair status
——— —– ———- —————— ———– ——————–
Gi2/0/11 100M Pair A 47 +/- 4 meters Pair A Normal
Pair B 48 +/- 4 meters Pair B Normal
Pair C 48 +/- 4 meters Pair C Open
Pair D 48 +/- 4 meters Pair D Open
SW01#

Изхода от командата показва освен интерфейса и скоростта, кой локален чифт на кой отдалечен чифт съответства, дължината на чифта, и статуса на чифта:

  • Normal;
  • Open – несвързан;
  • Not Completed – неуспешен tdr тест на интерфейса;
  • Not supported – tdr тест не се поддържа на интерфейса;
  • Shorted – чифта е свързан накъсо;

TCP congestion control и queueing

TCP механизми за регулация на трафика и congestion-control

В стандартните TCP имплементации има няколко механизма за предотвратяване на congestion:

  • TCP Slow-start – това е стандартният метод за увеличаване на количеството данни, което се изпраща – в началото експоненциално започвайки от един сегмент, а след определен момент – линейно(congestion-avoidance поведение), и регулация на това количество при наличие на задръстване (congestion) някъде по мрежата след източника на трафик;
  • TCP congestion-avoidance – работи заедно с TCP Slow-start и дефинира начин за регулация на нарастването на обема данни за изпращане при TCP – де факто представлява flow control при източника;
  • TCP Fast retransmit -дефинира ускорено препредаване на част от данни, при получаване на минимум 3 дубликатни квитанции (duplicate acknowledgements), без да се изчаква изтичането на TCP retransmission timeout-а.
  • TCP Fast recovery – след изпращането на липсващият сегмент от fast retransmit механизма, TCP продължава с линейно нарастване на количеството изпращана информация (congestion avoidance), вместо със започване на slow-start от самото начало;

TCP Slow-start

При установяване на TCP сесия една от променливите, които се инициализират в крайните възли е cwnd – congestion window. (more…)

Port-channel

Имаме следната настройка на port-channel между два Catalyst 3750 – SW1 Gig1/0/1 и Gig1/0/2, комбинирани в port-channel1 са свързани към Gig1/0/1 и Gig1/0/2 на SW2:

port-channel: sample topology

SW1:

interface GigabitEthernet1/0/1
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface GigabitEthernet1/0/2
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface Port-channel1
description to SW2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate

SW2:

interface GigabitEthernet1/0/1
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface GigabitEthernet1/0/2
description Member of PC1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate
channel-group 1 mode on

interface Port-channel1
description to SW1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,3,4
switchport mode trunk
switchport nonegotiate

За да се формира успешно portchannel интерфейса, всички членове на portchannel-а трябва да имат еднакви: (more…)

Планиране на капацитет за VoIP

Няколко са основните неща при планиране на необходим капацитет на свързаност при внедряване на VoIP:

  • Период на пакетизация (packetization period, a.k.a. PP);
  • Пакети в секунда (a.k.a. PPS, обратно пропорционална на периода на пакетизация);
  • Капацитет на кодека (codec bandwidth, a.k.a. CBW);
  • Допълнителни байтове от Data Link/IP/UDP/RTP/tunneling хедъри (overhead, a.k.a. TOH);

Съществуват някои механизми за спестяване на капацитет като например VAD (Voice Activity Detection), известно при някои вендори като Silence Suppression, но тяхната полза е условна и зависи от средната зашуменост на средата при провеждане на VoIP разговори. В идеални условия и отчитане на културните особености на разговор при различни националности се счита, че VAD може да спести до 35% от необходимия капацитет, но е прието тези спестявания да не се отчитат при първоначално планиране на капацитет за пренос на глас по IP. (more…)