key chain с разными key ID

Отвечен
1
0

Разбираюсь с работой key chain.
по примерам с cisco.com имена key chain и key id не обязаны совпадать на двух сторонах, главное чтобы пароли были идентичны.

http://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13719-50.html

Решил протестировать этот момент в лабораторной, но получил другой результат.

Я задал разные key chain name и key ID на R4 и R6

R4#sh key chain
Key-chain RIP-KEY:
key 1 — text «CCIEinaYEAR»
accept lifetime (always valid) — (always valid) [valid now]
send lifetime (always valid) — (always valid) [valid now]

R6#sh key chain
Key-chain TEST:
key 400 — text «CCIEinaYEAR»
accept lifetime (always valid) — (always valid) [valid now]
send lifetime (always valid) — (always valid) [valid now]

В результате R6 видит маршрут от R4

R6#sh ip route 180.1.4.4
Routing entry for 180.1.4.4/32
Known via «rip», distance 120, metric 1
Redistributing via rip
Last update from 188.1.45.4 on Ethernet0/1.456, 00:00:06 ago
Routing Descriptor Blocks:
* 188.1.45.4, from 188.1.45.4, 00:00:06 ago, via Ethernet0/1.456
Route metric is 1, traffic share count is 1

Но R4 не видит маршрут от R6 и в дебаге ошибки аутентификации

R4#sh ip route 180.1.6.6
% Subnet not in table

*May 15 17:34:05.040: RIP: ignored v2 packet from 188.1.45.6 (invalid authentication)

При настройке одинаковых key ID (но разных key chain name) все маршруты обе стороны видят.

Объясните как работает key chain, почему одна сторона видит маршруты, а вторая нет при разных key ID.

Лучший ответ
1
0

Если используется clear text authentication + key chain, то номер ключа совпадать не должен. В RIP пакетах будет отправляться только сам ключ без его id.
Если используется md5 authentication + key chain, то номер ключа должен совпадать, так как он определяет номер RIP security association. Key-id отправляется в RIP пакетах. Так как мы сравниваем хеши, то IOS должен знать, какой пароль брать для локального подсчёта хеша, поэтому он смотрит на key-id. Когда отправляется RIP апдейт, то IOS берёт ключ с наименьшим номером.

Такая ситуация, как у тебя, действительно может случиться.
При получении RIP пакета с аутентификаций, если у нас нет ключа с таким же номером, то для подсчёта хеша IOS берёт ключ с наименьшим key-id, если этот наименьший локальный key-id >= полученный key-id.

Пример с роутерами R2 и R6, соединёнными напрямую через e0/1

R2:

interface Loopback0
ip address 188.2.2.2 255.255.255.255
!
interface Ethernet0/1
ip address 180.1.26.2 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain TEST
!
router rip
version 2
network 180.1.0.0
network 188.2.0.0
no auto-summary
!

R6:

interface Loopback0
ip address 188.6.6.6 255.255.255.255
!
interface Ethernet0/1
ip address 180.1.26.6 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain TEST
!
router rip
version 2
network 180.1.0.0
network 188.6.0.0
no auto-summary
!

1.
Eсли на R2 у нас:

key chain TEST
key 1
key-string RIP
!

а на R6:

key chain TEST
key 100
key-string RIP
!

…то R2 не будет принимать RIP апдейты от R6, потому что 1 < 100, а R6 от R2 будет, потому что 100 >= 1 и hash(«RIP») == hash(«RIP»)

2. Если на R6 добавить ключ с номером 99 и таким же key-string:

key chain TEST
key 99
key-string RIP
key 100
key-string RIP
!

…то ничего не поменяется, так как 99 >= 1

3. А если на R6 добавить еще ключ с номером 98 и другим key-string:

key chain TEST
key 98
key-string cisco
key 99
key-string RIP
key 100
key-string RIP
!

То оба не будут принимать апдейты, потому что с точки зрения R2: 1 < 98, а с точки зрения R6: 98 >= 1, но hash(«cisco») != hash(«RIP»)
Вот блог-пост, который тоже заостряет на этом внимание:
http://lostintransit.se/2012/08/07/rip-md5-authentication-mismatch-in-key-id/
В публичной документации/RFC я не нашёл, что это так должно работать, поэтому, скорее всего, это особенность реализации RIP authentication в IOS.

1
0

Номера ключей должны совпадать, как и сами ключи (кроме случая, если используется IS-IS). Из руководства CCNP Route:

A neighboring router receives the routing update. That router determines
whether the received key matches its configured key (with a matching key
number).

А вот про IS-IS:

Somewhat surprisingly, though, even if the MD5 hash is used and the authentication is
configured using key chains, the key IDs (key numbers) are not carried along with the
authentication information in IS-IS packets. This is different from RIP, EIGRP, or OSPF,
where the number of the key used to sign the packet is indicated in the packet so that
the same key can be used by the receiving router to verify the packet’s authentication. In
IS-IS, key numbers are not advertised and can differ between routers. If the key strings
match, regardless of the key number, the authentication will succeed

  • Andrey
    тогда почему при разных key ID одна сторона видит маршруты, а вторая нет? обе стороны получается должны не проходить аутентификацию.
Показано 2 результата
Ваш ответ

для ответа.