Таймеры протокола
- Update timer — частота отправки обновлений протокола, по истечению таймера отправляется обновление. По умолчанию равен 30 секундам.
- Invalid timer — Если обновление о маршруте не будет получено до истечения данного таймера, маршрут будет помечен как Invalid, то есть с метрикой 16. По умолчанию таймер равен 180 секундам.
- Flush timer (garbage collection timer) — По умолчанию таймер равен 240 секундам, на 60 больше чем invalid timer. Если данный таймер истечет до прихода обновлений о маршруте, маршрут будет исключен из таблицы маршрутизации. Если маршрут удален из таблицы маршрутизации то, соответственно, удаляются и остальные таймеры, которые ему соответствовали.
- Holddown timer — Запуск таймера произойдет после того, как маршрут был помечен как не достижимый. До истечения данного таймера маршрут будет находиться в памяти для предотвращения образования маршрутной петли и по этому маршруту передается трафик. По умолчанию равен 180 секундам. Таймер не является стандартным, добавлен в реализации Cisco.
A minimum RIP configuration must include at least the statements
- rip
- group
- neighbor
(The term neighbor is a misnomer, by the way, in that you don’t include the address of a neighbor but the name of the logical interface that connects to a neighbor or neighbors.) You include one neighbor statement for each logical interface on which you want to receive routes.
The router imports all routes by default from this neighbor (that is, interface) but will not advertise any routes unless you write and apply a routing policy. Because of this, one might argue that the minimum configuration should include a policy and its relevant export statements.
[edit protocols]
root@jun1# show
rip {
group riptest {
neighbor em0.0;
neighbor em1.0;
}
}
root@jun1> show rip neighbor
Local Source Destination Send Receive In
Neighbor State Address Address Mode Mode Met
-------- ----- ------- ----------- ---- ------- ---
em0.0 Up 192.168.10.1 224.0.0.9 mcast both 1
em1.0 Up 172.20.10.1 224.0.0.9 mcast both 1
Логичным вопросом сразу встаёт узнать -- а есть-ли живой сосед на интерфейсе с той стороны
root@jun1> show rip statistics
RIPv2 info: port 520; holddown 120s.
rts learned rts held down rqsts dropped resps dropped
2 0 0 0
em0.0: 0 routes learned; 2 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 24 11 2
Triggered Updates Sent 1 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
RIPv1 Updates Received 0 0 0
RIPv1 Bad Route Entries 0 0 0
RIPv1 Updates Ignored 0 0 0
RIPv2 Updates Received 0 0 0
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 0 0 0
RIP Requests Received 0 0 0
RIP Requests Ignored 0 0 0
none 0 0 0
em1.0: 2 routes learned; 0 routes advertised; timeout 180s; update interval 30s
Counter Total Last 5 min Last minute
------- ----------- ----------- -----------
Updates Sent 0 0 0
Triggered Updates Sent 0 0 0
Responses Sent 0 0 0
Bad Messages 0 0 0
RIPv1 Updates Received 0 0 0
RIPv1 Bad Route Entries 0 0 0
RIPv1 Updates Ignored 0 0 0
RIPv2 Updates Received 31 13 3
RIPv2 Bad Route Entries 0 0 0
RIPv2 Updates Ignored 0 0 0
Authentication Failures 0 0 0
RIP Requests Received 0 0 0
RIP Requests Ignored 0 0 0
none 0 0 0
Applying Export Policy
Создаём политики
[edit policy-options]Пихаем их export'ом в rip
root@jun1# show
policy-statement connected-routes {
term advertise-routes {
from protocol direct;
then accept;
}
}
policy-statement transit-rip-routes {
term advertise-routes {
from protocol rip;
then accept;
}
}
[edit protocols rip]Смотрим результат
root@jun1# show
group riptest {
export [ transit-rip-routes connected-routes ];
neighbor em0.0;
neighbor em1.0;
}
[edit protocols rip]
root@jun1# run show route protocol rip
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[RIP/100] 00:13:16, metric 2, tag 0
> to 172.20.10.2 via em1.0
172.20.20.0/24 *[RIP/100] 00:13:16, metric 2, tag 0
> to 172.20.10.2 via em1.0
224.0.0.9/32 *[RIP/100] 00:00:24, metric 1
MultiRecv
[edit protocols rip]
root@jun1# run show route
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[RIP/100] 00:13:30, metric 2, tag 0
> to 172.20.10.2 via em1.0
172.20.10.0/24 *[Direct/0] 00:13:32
> via em1.0
172.20.10.1/32 *[Local/0] 00:13:32
Local via em1.0
172.20.20.0/24 *[RIP/100] 00:13:30, metric 2, tag 0
> to 172.20.10.2 via em1.0
192.168.10.0/24 *[Direct/0] 00:13:32
> via em0.0
192.168.10.1/32 *[Local/0] 00:13:32
Local via em0.0
224.0.0.9/32 *[RIP/100] 00:00:38, metric 1
MultiRecv
Applying Import Policy
Создаём политику
policy-options {
policy-statement stim-filter {
term filter-routes {
from {
protocol rip;
route-filter 172.20.10.0/24 exact;
}
then reject;
}
}
}
И применяем её на импорт соседа
protocols {
rip {
group riptest {
neighbor em0.0 {
import stim-filter;
}
}
}
}
или глобально на всех соседей
protocols {
rip {
group riptest {
import stim-filter;
neighbor em0.0;
}
}
}
Modifying the Incoming Metric
[edit]
root@jun2# run show route protocol rip
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[RIP/100] 00:42:28, metric 3, tag 0
> to 192.168.10.1 via em0.0
172.20.20.0/24 [RIP/100] 00:42:28, metric 3, tag 0
> to 192.168.10.1 via em0.0
224.0.0.9/32 *[RIP/100] 00:09:46, metric 1
MultiRecv
Меняем метрику
protocols {
rip {
group riptest {
import stim-filter;
neighbor em0.0 {
metric-in 10;
}
}
}
}
Результат:
[edit]
root@jun2# run show route protocol rip
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[RIP/100] 00:43:05, metric 12, tag 0
> to 192.168.10.1 via em0.0
172.20.20.0/24 [RIP/100] 00:43:05, metric 12, tag 0
> to 192.168.10.1 via em0.0
224.0.0.9/32 *[RIP/100] 00:00:17, metric 1
MultiRecv
Modifying the Outgoing Metric
metric-out применяется только на group, логически нельзя применять его на соседа
protocols {
rip {
group riptest {
metric-out 5;
import stim-filter;
neighbor em0.0;
}
}
}
Configuring Authentication
protocols {Как обычно, роутеры без совпадения аутентификации обмениваться маршрутами не будут, изменения вступят в силу после истечения Flush timer (240 секунд).
rip {
authentication-type md5;
authentication-key "$9$KKZ8xdbwgZGireMXN-g4aZU"; ## SECRET-DATA
group riptest {
metric-out 5;
import stim-filter;
neighbor em0.0;
}
}
}
Controlling Route Preference
protocols {
rip {
group riptest {
preference 80;
import stim-filter;
neighbor em0.0;
}
}
}
root@jun2# run show route protocol rip
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/24 *[RIP/80] 00:00:04, metric 3, tag 0
> to 192.168.10.1 via em0.0
172.20.20.0/24 [RIP/80] 00:00:04, metric 3, tag 0
> to 192.168.10.1 via em0.0
224.0.0.9/32 *[RIP/100] 00:00:04, metric 1
MultiRecv
Configuring Update Messages
protocols {
rip {
group riptest {
neighbor em0.0 {
send version-1;
receive version-1;
}
}
}
}
Configuring the Number of Route Entries in an Update Message
protocols {
rip {
message-size 100;
group riptest {
neighbor em0.0;
}
}
}
Accepting Packets Whose Reserved Fields Are Nonzero
Recall that the Request and Response messages for both RIPv1 and RIPv2 were identical. The difference between them was in the use of the message fields. RIPv1 viewed many fields as reserved, while the RIPv2 specification used those same fields for subnet mask, next hop, and so forth.
An RIPv1 router expects the reserved fields to contain zeroes and will discard any received packets with nonzero values. In addition, a RIPv2 router will discard any received packet with a nonzero value in a field that must be set to zero. The JUNOS software allows you to alter this behavior so that the RIP process can receive packets that are being sent in violation of the RFC 1058 and RFC 2453 specifications. You can do this with the no-check-zero command. Suppose Shiraz is connecting to a partner network on interface so-1/0/0.0 to a RIP router that may not adhere to the correct standards. To guarantee that all possible RIP packets will be received, Shiraz configures no-check-zero at the global RIP level:
user@Shiraz# show
rip {
no-check-zero;
group neighbor-routers {
export [connected-routes transit-rip-routes];
neighbor fe-0/0/1.0;
neighbor so-1/0/0.0;
}
}
Комментариев нет:
Отправить комментарий