freebsd + bgp

[dzek]

ок. делаю тогда так....
удаляю/делаю в /etc/rc.conf

Код: Выделить всё

#defaultrouter="10.10.10.1"

и в зебру пишем так...

Код: Выделить всё

... skip ...
!
ip route 0.0.0.0/0 10.10.10.1
ip route 0.0.0.0/0 10.30.30.1
ip route 10.10.10.0/29 10.10.10.1
ip route 10.30.30.0/29 10.30.30.1
!
!ip route 192.168.1.0/24 de2
!
!-----------------ip route 172.16.0.0/12 Null0 254
!
ip forwarding
!
line vty
 exec-timeout 0 0
!

и смотрим....

вот линк de0 включен на as65001

Код: Выделить всё

zebra-as65001> sh ip r
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, A - Babel,
       > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 10.10.10.1, de0
                    via 10.30.30.1, de1
C>* 10.10.10.0/29 is directly connected, de0
S   10.10.10.0/29 [1/0] via 10.10.10.1 inactive
S   10.30.30.0/29 [1/0] via 10.30.30.1 inactive
C>* 10.30.30.0/29 is directly connected, de1
C>* 127.0.0.0/8 is directly connected, lo0
C>* 192.168.1.0/24 is directly connected, de2
B>* 192.168.2.0/24 [180/0] via 10.30.30.1, de1, 00:08:33
C>* 195.1.1.24/29 is directly connected, de2
zebra-as65001>

на AS65000

Код: Выделить всё

AS65000> s ip b
BGP table version is 0, local router ID is 195.1.1.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0      10.10.10.2               0           200 65001 i
*                   10.20.20.2                           100 65002 65001 i
*> 192.168.2.0      10.10.10.2                           200 65001 65002 i
*                   10.20.20.2               0           100 65002 i
*> 195.1.1.24/29 10.10.10.2                  0           200 65001 i
*                   10.20.20.2                           100 65002 65001 i

Total number of prefixes 3
AS65000>

с AS64512

Код: Выделить всё

gw# traceroute 195.1.1.25
traceroute to 195.1.1.25 (195.1.1.25), 64 hops max, 52 byte packets
 1  AS65000 (195.1.1.10)  1.153 ms  1.858 ms  1.992 ms
 2  195.1.1.25 (195.1.1.25)  1.990 ms  0.985 ms  1.994 ms
gw#

вроде все ок... все как и задумано...

идем далее... роняем линк между AS65000 и AS65001
ждем чуток....

Код: Выделить всё

AS65000> s ip b
BGP table version is 0, local router ID is 195.1.1.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0      10.20.20.2                           100 65002 65001 i
*> 192.168.2.0      10.20.20.2               0           100 65002 i
*> 195.1.1.24/29 10.20.20.2                              100 65002 65001 i

Total number of prefixes 3
AS65000>

Код: Выделить всё

zebra-as65001> s ip r
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, A - Babel,
       > - selected route, * - FIB route

S>  0.0.0.0/0 [1/0] via 10.10.10.1 inactive
  *                 via 10.30.30.1, de1
S   10.10.10.0/29 [1/0] via 10.10.10.1 inactive
S   10.30.30.0/29 [1/0] via 10.30.30.1 inactive
C>* 10.30.30.0/29 is directly connected, de1
C>* 127.0.0.0/8 is directly connected, lo0
C>* 192.168.1.0/24 is directly connected, de2
B>* 192.168.2.0/24 [180/0] via 10.30.30.1, de1, 00:15:21
C>* 195.1.1.24/29 is directly connected, de2
zebra-as65001>


маршрут ушел.... проверяем...

Код: Выделить всё

gw# traceroute 195.1.1.25
traceroute to 195.1.1.25 (195.1.1.25), 64 hops max, 52 byte packets
 1  AS65000 (195.1.1.10)  2.515 ms  0.999 ms  1.897 ms
 2  10.20.20.2 (10.20.20.2)  2.012 ms  1.969 ms  1.991 ms
 3  195.1.1.25 (195.1.1.25)  2.035 ms  2.055 ms  1.833 ms
gw#

проверка далеко из сети

Код: Выделить всё

C:\>tracert 195.1.1.25

Трассировка маршрута к 195.1.1.25 с максимальным числом прыжков 30

  1    <1 мс    <1 мс    <1 мс  10.10.10.2
  2     1 ms     1 ms     1 ms  10.10.10.1
... skip ...
  5     5 ms     3 ms     5 ms  AS65000 [195.1.1.10]
  6     *        *        *     Превышен интервал ожидания для запроса.
  7     4 ms     5 ms     4 ms  195.1.1.25

Трассировка завершена.

C:\>

убивает только что на 6-ом хопе звезды.... в любом случае... если идет через 65001 или через 65002.
ноо тут возможно сказывается загрузка вдс-ноды.

[root]

конфиги, тут уже роли не играют. они не шибко отличаются от топикстарта.

и во всех zebra.conf у тябя не на всех интерфейсах указаны IP-адреса, а в большей части просто отсутствуют.
настоятельно рекомендую описать в зебре все интерфейсы с указанием IP-адресов и маски подсети.

на AS65001:

Код: Выделить всё

network 195.1.1.25/29

адрес сети указан не верно, должно был 195.1.1.24/29

для верности пингуем с AS64512

ага, только ты опять же не указал SRC адрес, с которого уходит пинг из AS64512

идем на AS65000 и tcpdump -i de2

т.к. ключа -n ты не указал, то лично мне имя gw.AS64512.ru не говорит о SRC IP-адресе.
я могу только по схеме предположить что это адрес 195.1.1.1, но маска этого IP для меня пока остается загадкой.

на AS65001 на int: de1 видим входящий.....
а исходящий видим только на de0.

и что в этом удивительного ? это нормальная ситуация, куда смотри маршрут туда и идет пакет.
а вот это:

а исходящий видим только на de0.

меня лично смущает, исходя из того что ты пишешь:

Jan 22 12:59:52 AS65001 kernel: de0: link down: cable problem?

как же он отправляет туда пакеты если линк лежит ?
и это ещё не все:

AS65001# netstat -rn
Destination Gateway Flags Refs Use Netif Expire
default 10.10.10.1 UGS 0 12343 de0

опять же если линк лежит, то откуда в табле роутинга default маршрут, который смотрит в de0 ?
так же исходя из предположений что AS64512 при пинге адреса 195.1.1.25 имеет SRC 195.1.1.1 и исходя из приведенной таблицы роутинга AS65001 мы получаем, что AS65001 будет отправлять ответные пакеты к AS64512 через интерфейс de0, т.к. маршрута в подсеть 195.1.1.0/24 у AS65001 нет, а значит будет использоваться default маршрут.
В виду того что маршрутов на AS65002 ты не привел, как и не привел анонсирует ли AS65002 маршрут 195.1.1.0/24 в сторону AS65001, то невозможно сказать почему на AS65001 отсутствует маршрут 195.1.1.0/24.
Толи потому что AS65002 сам не знает маршрута в эту подсеть, толи потому что конфиг AS65002 запрещает ему эти анонсы и т.п.

убирал на AS65001 В /etc/rc.conf
#defaultrouter="10.10.10.1"
тогда из внешней сети не видно 195.1.1.24/29

Ессно не видишь, это вполне естественно. Почему ?
Потому что если default`а нет, а маршрут в эту подсеть у AS65001 отсутствует, то AS65001 (195.1.1.25) не сможет отправить REPLY до 195.1.1.1. Об этом же написано чуть выше.

ок. делаю тогда так....
удаляю/делаю в /etc/rc.conf
......
и в зебру пишем так...

Тем самым ты добавляешь второй default через 10.30.30.1 и когда ты роняешь линк в сторону 10.10.10.1 у тебя пакеты из AS65001 (195.1.1.25) до AS64512 (195.1.1.0/24) будут уходить по этому default`у, в сторону AS65002, а AS65002 в свою очередь и согласно своей таблицы маршрутизации будет пытаться продвигать эти пакеты далее к IP-адресу назначения.

Опять же повторюсь:

Трафик - это двустронний обмен, а значит мало знать путь к хосту назначения, нужно чтобы и хост назначания знал обратный путь к источнику.

Если ты проследишь путь пакета в обе стороны по шагам, то и вопросов "почему" у тя не должно остаться. Каждый роутер, через который проходит пакет, должен знать как добираться и до SRC-адреса и до DST-адреса, которые указаны в пакете. Если маршрут до SRC или до DST у роутера отсутствует, то пакет "умирает" (он отбрасывается как недостижимый).

проверка далеко из сети

"далеко" это откуда ? SRC-адрес ? Где расположен данный хост ?
запомни, что при маршрутизации и траблшуте не существует понятий "далеко", "близко" или "там". Всегда есть два конкретных хоста с конкретными IP-адресами, которые пытаются обменяться между собой IP пакетами.

убивает только что на 6-ом хопе звезды....

звезды будут возникать когда хост, через который проходит пакет в трассе, отправляет REPLY, но он до хоста, с которого запускали трассу, не доходит.
например в ситуации, когда внутри AS p2p связи строятся на IP-адресах из серых подсетей, а трассу выполняют из инета, где маршруты до серых подсетей отсутствуют.


------------------------------------------------------------------

так и не догоняю в чем мой косяк.

Исходя из уже написанного тобой, я могу набросать тебе несколько пунктов
1. Не все до конца настроено (я как минимум о зебре)
2. не до конца есть понимание как работает процесс маршрутизации, по этой причине отсутствует понимание того как идет пакет "запроса" и как возвращается пакет "ответа"
3. не вижу попыток дебага по шагам. как я уже писал, когда что-то не работает нужно разобраться по шагам:

Вот и дебаж это по шагам, начиная с AS64512 и далее.
А вот эти BGP команды тебе помогут:

Выводов приведенных мной команд ни с одной из AS ты так и не привел, как и вообще проскочил AS65002, а она имеет прямое отношение при передаче ответных пакетов от 195.1.1.25 (AS65001) до 195.1.1.1 (AS64512).
Думаю что как только ты решишь эти проблемы, так сразу у тя и понимание придет и все заработает, так как ты хочешь.

[dzek]

и во всех zebra.conf у тябя не на всех интерфейсах указаны IP-адреса, а в большей части просто отсутствуют.
настоятельно рекомендую описать в зебре все интерфейсы с указанием IP-адресов и маски подсети.

поправил/прописал.

на AS65001:

Код: Выделить всё

network 195.1.1.25/29

адрес сети указан не верно, должно был 195.1.1.24/29

тогда сразу и
network 192.168.1.0/24 - поправил...

для верности пингуем с AS64512

ага, только ты опять же не указал SRC адрес, с которого уходит пинг из AS64512

а он там как бы вроде и не нужен.
AS64512 это 195.1.1.1/24, AS65000 это 195.1.1.10/24
чтоб на AS64512 было видно 195.1.1.24/29 видно, мы ее пробросили и анонсировали с AS65000, т.е. грубо выдернули ее из сети /24

идем на AS65000 и tcpdump -i de2

т.к. ключа -n ты не указал, то лично мне имя gw.AS64512.ru не говорит о SRC IP-адресе.
я могу только по схеме предположить что это адрес 195.1.1.1, но маска этого IP для меня пока остается загадкой.

на AS64512
em0 - 172.18.8.6/30
em1 - 195.1.1.1/24

опять же если линк лежит, то откуда в табле роутинга default маршрут, который смотрит в de0 ?
так же исходя из предположений что AS64512 при пинге адреса 195.1.1.25 имеет SRC 195.1.1.1 и исходя из приведенной таблицы роутинга AS65001 мы получаем, что AS65001 будет отправлять ответные пакеты к AS64512 через интерфейс de0, т.к. маршрута в подсеть 195.1.1.0/24 у AS65001 нет, а значит будет использоваться default маршрут.
В виду того что маршрутов на AS65002 ты не привел, как и не привел анонсирует ли AS65002 маршрут 195.1.1.0/24 в сторону AS65001, то невозможно сказать почему на AS65001 отсутствует маршрут 195.1.1.0/24.
Толи потому что AS65002 сам не знает маршрута в эту подсеть, толи потому что конфиг AS65002 запрещает ему эти анонсы и т.п.

вечером не осилил это.... после обновления суслика (suricata)...

AS64512 <-> AS65000 <-> AS65001
195.1.1.1/24 <-> 195.1.1.10/24 <-> 195.1.1.24/29
т.е. из сети /24 мы выдрали сеть /29. и чтоб на AS64512 мы знали что оторвали (себе по.....) то и пишем ее в маршрутизацию на AS64512. Чтоб не делить сеть /24 (экономия блин)

вот таблица на AS64512

Код: Выделить всё

gw-zebra> sh ip ro
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, A - Babel,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 via 172.18.8.5, em0
C>* 10.255.255.0/24 is directly connected, em1
C>* 91.2.129.96/27 is directly connected, em1
C>* 127.0.0.0/8 is directly connected, lo0
C>* 172.18.8.4/30 is directly connected, em0
B>* 192.168.1.0/24 [20/0] via 195.1.1.10, em1, 00:35:43
B>* 192.168.2.0/24 [20/0] via 195.1.1.10, em1, 00:50:14
C>* 195.1.1.0/24 is directly connected, em1
B>* 195.1.1.24/29 [20/0] via 195.1.1.10, em1, 00:35:43


Ессно не видишь, это вполне естественно. Почему ?
Потому что если default`а нет, а маршрут в эту подсеть у AS65001 отсутствует, то AS65001 (195.1.1.25) не сможет отправить REPLY до 195.1.1.1. Об этом же написано чуть выше.

но мы же в zebra.conf прописали

Код: Выделить всё

hostname zebra-as65001
......
ip route 0.0.0.0/0 10.10.10.1
ip route 0.0.0.0/0 10.30.30.1


и когда на AS65001 int: de0 в активном статусе(up)....

Код: Выделить всё

zebra-as65001> sh ip ro
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, A - Babel,
       > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 10.10.10.1, de0
                    via 10.30.30.1, de1
.....

тоже, но int: de0 в не активном (down)

Код: Выделить всё

zebra-as65001> s ip ro
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, A - Babel,
       > - selected route, * - FIB route

S>  0.0.0.0/0 [1/0] via 10.10.10.1 inactive
  *                 via 10.30.30.1, de1
....

т.е. маршрут поменялся. при записи на AS65001 в /etc/rc.conf

Код: Выделить всё

defaultrouter="10.10.10.1"

чтоб не делал. с de0 маршрут не хотел никак меняться. вот с этим то и возникла проблема...
тестовые пинги входили на int: de1 но ответные пакеты было видно только на int: de0

....skip....
Опять же повторюсь:

Трафик - это двустронний обмен, а значит мало знать путь к хосту назначения, нужно чтобы и хост назначания знал обратный путь к источнику.

Если ты проследишь путь пакета в обе стороны по шагам, то и вопросов "почему" у тя не должно остаться. Каждый роутер, через который проходит пакет, должен знать как добираться и до SRC-адреса и до DST-адреса, которые указаны в пакете. Если маршрут до SRC или до DST у роутера отсутствует, то пакет "умирает" (он отбрасывается как недостижимый).

пакеты ходят правильно. судя по tcpdump начиная от AS64512 и до AS65001

проверка далеко из сети

"далеко" это откуда ? SRC-адрес ? Где расположен данный хост ?
запомни, что при маршрутизации и траблшуте не существует понятий "далеко", "близко" или "там". Всегда есть два конкретных хоста с конкретными IP-адресами, которые пытаются обменяться между собой IP пакетами.

не из сети 195.1.1.0/24.

убивает только что на 6-ом хопе звезды....

звезды будут возникать когда хост, через который проходит пакет в трассе, отправляет REPLY, но он до хоста, с которого запускали трассу, не доходит.
например в ситуации, когда внутри AS p2p связи строятся на IP-адресах из серых подсетей, а трассу выполняют из инета, где маршруты до серых подсетей отсутствуют.

точно... as65002 чисто попугайские адреса... все понятно теперь.... придется заново освежать .....

------------------------------------------------------------------

так и не догоняю в чем мой косяк.

Исходя из уже написанного тобой, я могу набросать тебе несколько пунктов
1. Не все до конца настроено (я как минимум о зебре)
2. не до конца есть понимание как работает процесс маршрутизации, по этой причине отсутствует понимание того как идет пакет "запроса" и как возвращается пакет "ответа"
3. не вижу попыток дебага по шагам. как я уже писал, когда что-то не работает нужно разобраться по шагам:

Вот и дебаж это по шагам, начиная с AS64512 и далее.
А вот эти BGP команды тебе помогут:

1. с bgpd вроде прояснилась ситуация... но еще читать читать и читать... для полного понимания...
2. уже понял... буду исправляться.
3. в смысле журналов bgpd.log и zebra.log. можно их показать.... но там вроде все чисто.

Код: Выделить всё

2013/01/24 00:41:02 BGP: %ADJCHANGE: neighbor 10.10.10.1 Down BGP Notification send
....
2013/01/24 00:41:02 BGP: 10.30.30.1 rcvd UPDATE about 192.168.1.0/24 -- withdrawn
2013/01/24 00:41:02 BGP: 10.30.30.1 Can't find the route 192.168.1.0/24
2013/01/24 00:41:02 BGP: 10.30.30.1 rcvd UPDATE about 195.1.1.24/29 -- withdrawn
2013/01/24 00:41:02 BGP: 10.30.30.1 Can't find the route 195.1.1.24/29
2013/01/24 00:41:11 BGP: Performing BGP general scanning
2013/01/24 00:41:11 BGP: scanning IPv4 Unicast routing tables
2013/01/24 00:41:11 BGP: scanning IPv6 Unicast routing tables
2013/01/24 00:41:13 BGP: 10.10.10.1 [FSM] Timer (start timer expire).
2013/01/24 00:41:13 BGP: 10.10.10.1 [FSM] BGP_Start (Idle->Connect)
2013/01/24 00:41:13 BGP: 10.10.10.1 [Event] Connect start to 10.10.10.1 fd 12
2013/01/24 00:41:13 BGP: 10.10.10.1 [FSM] Non blocking connect waiting result
2013/01/24 00:41:13 BGP: 10.10.10.1 [Event] Connect failed (Operation now in progress)
2013/01/24 00:41:13 BGP: 10.10.10.1 [FSM] TCP_connection_open_failed (Connect->Active)
2013/01/24 00:41:14 BGP: Import timer expired.


при штатной ситуации соответсвенно все вернется назад... т.е. as65001 -> as65000 -> as64512

Выводов приведенных мной команд ни с одной из AS ты так и не привел, как и вообще проскочил AS65002, а она имеет прямое отношение при передаче ответных пакетов от 195.1.1.25 (AS65001) до 195.1.1.1 (AS64512).
Думаю что как только ты решишь эти проблемы, так сразу у тя и понимание придет и все заработает, так как ты хочешь.

хм... вывод команд... что то я пропустил.... прошелся по топику... не понял про что ...

[dzek]

глубина, глубина, отпусти меня.....


еще раз прочитал топик... прочитал свою ...... стало....
ушел читать про маршрутизацию начиная с "Административная дистанция"


спасибо за терпение

[root]

хм... вывод команд... что то я пропустил.... прошелся по топику... не понял про что ...

Вот о чем:

А вот эти BGP команды тебе помогут:

Код: Выделить всё

show ip bgp neighbors [address] received-routes

Код: Выделить всё

show ip bgp neighbors [address] advertised-routes

С помощью этих команд всегда можно узнать, какие маршруты ты получил от соседа и какие маршруты ему отанонсил.
По команде c received-routes нужно учитывать два момента:

а) при указании соседа в конфиге обязательно должна быть дана команда soft-reconfiguration inbound
б) отображаются все полученные от соседа маршруты, но ДО того как они были обработаны BGP фильтром на стороне этого роутера, если фильтр задан

а он там как бы вроде и не нужен.
AS64512 это 195.1.1.1/24, AS65000 это 195.1.1.10/24

Консоль видишь ты, я то твоей консоли не вижу Потому я не могу быть на 100% уверен в том, что там один IP, а не несколько, поэтому для моего 100% понимания я и прошу явным образом указывать SRC при пинге. Так будет на 100% понятно от какого IP пойдут ICMP запросы и других возможных вариантов просто не будет.

3. в смысле журналов bgpd.log и zebra.log. можно их показать.... но там вроде все чисто.

Нет, не в этом смысле.
В смысле, то ты прошелся по всем роутерам поочередно и выяснил что все промежуточные роутеры получают маршруты для достижения адресов 195.1.1.1 и 195.1.1.25, инсталят эти маршруты в свои роутинг таблицы, а так же то что они анонсируют эти маршруты своему соседу.
Так AS64512 должна анонсировать 195.1.1.0/24 в сторону AS65000, AS65000 должна анонсировать эту же подсеть в сторону AS65001 и AS65002 и AS65002 должна анонсировать в сторону AS65001.
В нормальной ситуации у AS65001 должно быть два возможных маршрута до 195.1.1.1:

1. через AS65000. Этот маршрут будет best маршрутом, т.к. AS-PATH будет из двух хопов
2. через AS65002. Этот маршрут будет запасным, т.к. исходя из BGP Path Selection Process у данного маршрута AS-PATH из трех хопов и из-за этого он проиграет при выборе лучшего маршрута.

Это был дебаг пути "туда" к 195.1.1.25, соответственно затем нужно проверить точно так же, но в обратную сторону.
AS65001 должна анонсировать подсеть 195.1.1.24/29 в сторону AS65000 и AS65002 и т.д. и т.п.

Вот когда ты по шагам пройдешь, убедишься как та или иная AS видит маршруты к искомым адресам, видит ли она их вообще, анонсирует ли она эти маршруты соседям, если не, то почему и т.п. вот тогда вопросов "почему нет пинга?" у тебя уже не должно возникнуть.

но еще читать читать и читать... для полного понимания...

Это да, т.к. протокол BGP сложная штука, да и вообще как и любой другой протокол динамической маршрутизации. Много ситуаций и много нюансов.

[dzek]

но еще читать читать и читать... для полного понимания...

Это да, т.к. протокол BGP сложная штука, да и вообще как и любой другой протокол динамической маршрутизации. Много ситуаций и много нюансов.

не буду раз... тут далее. задачу частично решил. правда между AS64512 и AS65000 нет анонсов сети /24, хотя из всего выше изложены тогда должна быть.
тогда поидеи вооще внутри нужно разделить сеть /24 на более мелкие сети, /26, /27, /28

ошибки осознал. отразил... будем практиковаться на стэндах...

p.s. очень часто читаю Ваш блог... и все вытекающее... нравится манера ответов. спасибо!

[root]

равда между AS64512 и AS65000 нет анонсов сети /24

Так разберись почему их нет

тогда поидеи вооще внутри нужно разделить сеть /24 на более мелкие сети, /26, /27, /28

Именно. Как ты разбил свою сеть внутри может не иметь никакого отношения к тому как ты анонсируешь свою сеть своим BGP пирам.
Суммаризацию маршрутов никто не отменял Поэтому внутри ты можешь "рубить" как тебе нужно, а наверх анонсировать суммарный /24 маршрут.

будем практиковаться на стэндах...

Это единственно правильное решение. Сначала осознай что к чему на стендах, а потом только можно настраивать "боевую" схему.

спасибо

пжалста. пиво лить сюда )))

[dzek]

равда между AS64512 и AS65000 нет анонсов сети /24

Так разберись почему их нет

не прописал.... уже поправил...

тогда поидеи вооще внутри нужно разделить сеть /24 на более мелкие сети, /26, /27, /28

Именно. Как ты разбил свою сеть внутри может не иметь никакого отношения к тому как ты анонсируешь свою сеть своим BGP пирам.
Суммаризацию маршрутов никто не отменял Поэтому внутри ты можешь "рубить" как тебе нужно, а наверх анонсировать суммарный /24 маршрут.

хм.... видимо так и заверну.

будем практиковаться на стэндах...

Это единственно правильное решение. Сначала осознай что к чему на стендах, а потом только можно настраивать "боевую" схему.

спасибо

пжалста. пиво лить сюда )))

ок.... скоко милилитров или тепалитров

[root]

хм.... видимо так и заверну.

пропиши маршрут на /24 в Null0 с метрикой 254, а в route-map на out в сторону твоего прова укажи матчить только этот /24. Таким образом твой роутер всегда будет анонсить /24 вверх, а трафик будет ходить по твоим more specific (меньшая маска) маршрутам.

скоко милилитров или тепалитров

это дело сугубо добровольное