[alibek]

Есть несколько разных BRAS, в том числе пара Cisco ASR 1001X.

Все они подключены в канал с интернетом (SVI на бордере), который используется как аплинк. Этот бордер также принимает стыки от других операторов (BGP).

Абоненты (PPPoE и IPoE) терминируются на BRAS, получают "белые" IP.

У BRAS также есть служебный канал (биллинг и RADIUS), работает на "серых" IP.

До настоящего момента у каждого BRAS был выделен свой пул IP-адресов, а на бордере были прописаны статические маршруты к каждому блоку IP-адресов через соответствующий BRAS.

Но видимо пора переходить на динамику.

Прежде чем начинать, хотел уточнить некоторые вопросы.

 

1) Какой протокол выбрать, BGP или OSPF? Я склоняюсь к BGP (точнее iBGP, все BRAS его поддерживают). Но может быть у OSPF есть свои преимущества?

 

2) Связность между устройствами и петлевые интерфейсы организованы в отдельной vrf, на "серых" адресах. Получится ли обмениваться маршрутной информацией (маршруты на "белые" IP в глобальной таблице маршрутизации) на таком стыке? Или BGP-пиринг нужно будет поднимать на публичных адресах?

 

3) Со связкой eBGP + iBGP раньше не сталкивался. Не поделитесь примерами, как это должно выглядеть?

[sirmax]

Вам в Вашей схеме вообще не нужен iBGP для этого вполне достаточно и OSPF (который тоже абсолютно точно поддерживается в  ASR)

Я пока не очень понял зачем в этой схеме присутвует VRF (vrf lite по-видимому в терминах cisco) 

Есть некоторый vrf, именованый или Global в котором  висят интерфейсы клиентов, эти клиенты после подключения видны через маршруты static  или connected (не уверен но вроде тип маршрутов для сессий клиентов можно настроить, хотя для задачи это не принципиально

 В этом же vrf присутвует интерфейс куда смотрит default и через который доступен интернет 

Тогда вам достатосно следующее
 

router ospf <номер процесса - часто используеся номер автономной системы>
 redistribute connected subnets route-map ROUTE_MAP_REDISTRIBUTE_CONNECTED_TO_OSPF
 redistribute static subnets route-map ROUTE_MAP_REDISTRIBUTE_STATIC_TO_OSPF
 passive-interface default
 no passive-interface Port-channel1.4006
 network 172.31.1.32 0.0.0.15 area 0

тут настройки означают следующее

 redistribute connected subnets route-map ROUTE_MAP_REDISTRIBUTE_CONNECTED_TO_OSPF - помещать коннектед маршруты в процесс OSPF (но не все отфильтровав их через роут-мап), то же самое для статик
 passive-interface default - не включать процесс OSPF  на всех интерфейсах кроме no passive-interface Port-channel1.4006
 network 172.31.100.32 0.0.0.15 area 0 -  сеть настроенная на этом интерфейсе Port-channel1.4006 
(конечно в вашем случае и сеть и интерфейс будет другой)

В route-map  перечислить сети которые выдаете клиентам

Как то так
 

route-map ROUTE_MAP_REDISTRIBUTE_STATIC_TO_OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-TO-OSPF-STATIC-CUSTOMER-NETS


ip prefix-list REDISTRIBUTE-TO-OSPF-STATIC-CUSTOMER-NETS-AND-MGMT-NETS-WITHOUT-DEFAULT seq 10 permit 192.168.0.0/16 ge 32
ip prefix-list REDISTRIBUTE-TO-OSPF-STATIC-CUSTOMER-NETS-AND-MGMT-NETS-WITHOUT-DEFAULT seq 20 permit 100.64.0.0/10 ge 32

Опять же сети будут ваши

То же самое в плане OSPF  настроить на бордере, редистрибьютить на бордере нужно только те статики которые хотите анонсить через OSPF (скорее всего никаких так как бордер указан дефолтом)

Если никаких петель нет и не планируетя этого уже будет достаточно что бы маршруты до  клиентов приехали на бордер
Для второй, третьей, 10-й железки аналогично

Провериять что маршруты отредистрибьютились в OSPF
show ip ospf database

Проверять что установлены отношения соседства
 

show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
100.64.255.252    1   FULL/DR         00:00:32    172.31.100.52   Port-channel1.4006
172.31.100.15     1   FULL/BDR        00:00:38    172.31.100.35   Port-channel1.4004

Обычно еслинет разных  MTU и нужно только то что вы описали, и железок не много  а топология проста то разделение на area не требутся

 

Обмен маршрутам и между Global и VRF  отдельный гимморой - значительно проще между 2-мя VRF

[alibek]

Спасибо за примеры.

 

У меня на BRAS примерно такая конфигурация:

vrf definition Mgmt-intf
 description "Service networks and backbone"
! 
bba-group pppoe global
 virtual-template 1
 vendor-tag circuit-id service
 vendor-tag strip
 sessions max limit 65530
 sessions per-mac limit 10
 sessions per-vlan limit 1024
!
interface Loopback0
 description SELF
 vrf forwarding Mgmt-intf
 ip address 10.255.255.213 255.255.255.255
!
interface TenGigabitEthernet0/0/0
 description UPLINK
 ip address **.**.**.248 255.255.255.240
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip access-group WAN_ACCESS in
 history BPS
!
interface TenGigabitEthernet0/0/1
 description SUBS
 no ip address
 history BPS
 service instance 400 ethernet
  encapsulation default
  bridge-domain 400
 !
!
interface GigabitEthernet0
 description MGMT
 vrf forwarding Mgmt-intf
 ip address 10.1.3.18 255.255.255.252
 negotiation auto
!
interface Virtual-Template1
 mtu 1492
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 peer default ip address pool CLIENT-PPP
 ppp authentication pap PPPOE
 ppp authorization PPPOE
 ppp accounting PPPOE
 ppp ipcp dns **.**.**.1 **.**.**.124
 ppp timeout idle 60
!
interface BDI400
 no ip address
 vlan-range dot1q 400 499
  pppoe enable group global
 !
!
ip local pool CLIENT-PPP <sub-nets>
ip route 0.0.0.0 0.0.0.0 **.**.**.241
ip route <sub-nets> Null0
ip route 10.0.0.0 255.0.0.0 Null0
ip route 172.16.0.0 255.240.0.0 Null0
ip route 192.168.0.0 255.255.0.0 Null0
ip route vrf Mgmt-intf 10.1.0.0 255.255.0.0 10.1.3.17

Если коротко, то в глобальном контексте живет интернет — аплинк (и он же дефолт) и сессии абонентов. Динамика нужна именно тут, для абонентских сессий.

А в vrf находится служебная сеть — прежде всего связь с RADIUS и CoA — за приватными адресами. Какой-то острой необходимости именно в vrf нет (адреса и маршруты не пересекаются), но в ASR mgmt-интерфейс нельзя убрать из vrf Mgmt-intf. Да и обычно отдельный vrf для служебной сети считается хорошим правилом.

 

Что же касается выбора BGP вместо OSPF, то соображения были сугубо теоретические.

Во-первых для OSPF нужен мультикаст, а я со времен IPTV помню, какие там иногда бывают неявные и сложно диагностируемые проблемы.

Во-вторых OSPF является протоколом link-state, предположу что он будет пересчитываться при установке или завершении абонентской сессии, лишняя вычислительная нагрузка на BRAS.

Но да, с ним выглядит проще.

[Умник]

23 часа назад, alibek сказал:

Во-первых для OSPF нужен мультикаст, а я со времен IPTV помню, какие там иногда бывают неявные и сложно диагностируемые проблемы.

Во-вторых OSPF является протоколом link-state, предположу что он будет пересчитываться при установке или завершении абонентской сессии, лишняя вычислительная нагрузка на BRAS.

1) В случае OSPF таких проблем не будет. Во времена IPTV мультикаст нужно было как-то маршрутизировать (а значит был нужен PIM-SM), к тому же со свитчами напрмяую взаимодействовали клиенты по IGMP (igmp_snooping). Это были основные источники проблем и нестабильности. В OSPF все это не нужно. Мультикаст внутри L2 тупо ходит как broadcast.

2) При установке или завершении абонентской сессии пересчета топологии не будет. В предложенной конфигурации вы редистрибьютите нужные маршруты напрямую из таблицы маршрутизации. PPPoE-интерфейсы клиентов не участвуют в OSPF явно, только как connected-маршруты.

[VolanD666]

Если нужно будет мутить связность с VRFами на ASRах есть VASI, может пригодиться.

[alibek]

У меня кроме Cisco еще и Eltex, Extreme, Ericsson.

Так что чем проще, тем лучше.

[Saab95]

В 21.11.2024 в 09:24, alibek сказал:

Во-вторых OSPF является протоколом link-state, предположу что он будет пересчитываться при установке или завершении абонентской сессии, лишняя вычислительная нагрузка на BRAS.

У нас микротики вида RB750 по 40000 маршрутов держат в таблице маршрутизации OSPF, да еще и со своих портов (интерфейсов) маршруты анонсят и производительности хватает, а вы за циску переживаете=)

[alibek]

Вопрос по статике.

 

Есть такая схема (упрощенно):

 

A, B, C — это BRAS, на котором терминируются сессии абонентов и которым выдаются IP-адреса из соответствующего пула.

На каждом из них прописан дефолтный маршрут на Z, а также маршрут в null для своего пула адресов (чтобы избежать зацикливания в случае направления пакета на неактуальный адрес).

Условный пример для A:

ip route 0.0.0.0/0 zz.zz.0.250

ip route aa.aa.0.0/22 null

ip route aa.aa.8.0/22 null

...

 

На Z прописаны статические маршруты к пулам A, B, C через соответствующие линковые интерфейсы (zz.zz.0.a, zz.zz.0.b, zz.zz.0.c, ,,,).

 

То есть в теории должно быть так:

a) внешний входящий трафик попадает на Z, затем по таблице маршрутизации на BRAS (static) и далее на абонента

b) исходящий трафик в мир попадает на BRAS (connected), затем на Z (default), затем в мир

c) трафик между абонентами внутри одного BRAS не выходит за пределы BRAS и маршрутизируется внутри (connected)

d) трафик между абонентами разных BRAS выходит на Z (default), затем направляется в нужный BRAS (static) и абонента

e) трафик на неактуальный адрес (нет сессии с таким адресом) попадает на соответствующий BRAS, затем в null

 

На практике с пунктом (d) есть проблемы, но причина пока непонятна.

И я подумал — а может быть прямо на BRAS прописать маршруты к соседям?

Минусы понятны — если все прописывать статикой, то при любых изменениях нужно будет не забыть внести эти изменения на всех устройствах.

А плюсы будут от экономии на один хоп? Или на самом деле никаких плюсов не будет?

[azhur]

3 синих линка на схеме - это именно три отдельных линка point-to-point, или "облачко-vlan"?
Если первое, то "маршруты к соседям" не помогут, так как прямого пути нет.

[alibek]

Это физические линки, но не PtP (с маской /30), а транспортный VLAN и подсеть /28.

То есть все BRAS в одном сегменте и могут коммутироваться напрямую.

[sirmax]

2 часа назад, alibek сказал:

от экономии на один хоп

Зачем, межабонентский трафик около нуля и экономии не будет