Перейти к содержимому
Калькуляторы

Переход на бОльшие масштабы

Судя по ценам CWDM экономически целесообразен при больших расстояниях

Там есть и минусы. Несколько сложнее в эксплуатации, надо понимать как все это работает. У нас тут такие схемы были это просто взрыв мозга полнейший. Потом разобрали, фух. :)

И еще CWDM потом сильно тормозит различные перестановки и переделки. Продали лямбду клиенту или задействовали под критичный узел и стеснили себя в выборе вариантов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

что ж, просуммирую

1) элементная база надежная, однако могут быть проблемы с софтом и при высоком транзитном траффике

2) GVRP нафиг, вланы предзаводить

3) так же

5) переходить на CWDM если припрет траффик и получать независимый гиг на каждый свич доступа

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

с четвертым пунктом полная ж...

 

собрал на столе копию схемы которая работает в домонете. 3550 на доступе, включен igmp snooping, вставляется option82, влан абонента пробрасывается до аггрегационного 3560 каталиста, где заведет SVI интерфейс, оттуда helper-address до биллинга, дальше абонент попадает в отдельный vrf. Все ok.

Ставлю вместо 3560 на аггрегацию роутер 7206, пока без QinQ для упрощения и... 7206 релеит dhcp запрос до биллинга, биллинг получает opt82, отвечает... и на 7206 не создается /32 маршрут на абонента. Упс.

Конфиг скопировал с аггрегационного свича (вместо SVI конечно сабинтерфейс):

 

ip dhcp relay information policy keep
ip dhcp relay information trust-all

interface Loopback52
ip vrf forwarding domonet
ip address 109.XXX.XXX.254 255.255.255.0

interface GigabitEthernet0/3.1201
encapsulation dot1Q 1201
ip vrf forwarding domonet
ip unnumbered Loopback52
ip helper-address 10.199.1.23

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5) переходить на CWDM если припрет траффик и получать независимый гиг на каждый свич доступа

CWDM не дорог. Это не DWDM, тем более магистральный.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Разница в логах: у 3560:

*Mar  1 01:29:41.056: DHCPD: BOOTREQUEST from 0015.60bb.cb17 forwarded to 10.199.1.23.
*Mar  1 01:29:41.065: DHCPD: Reload workspace interface Vlan52 tableid 1.
*Mar  1 01:29:41.065: DHCPD: tableid for 10.112.1.1 on Vlan52 is 1
*Mar  1 01:29:41.065: DHCPD: client's VPN is .
*Mar  1 01:29:41.065: DHCPD: DHCPOFFER notify setup address 109.XXX.XXX.24 mask 255.255.255.0
*Mar  1 01:29:41.065: DHCPD: forwarding BOOTREPLY to client 0015.60bb.cb17.
*Mar  1 01:29:41.065: DHCPD: Forwarding reply while saving lease state, on UNNUM-IF
*Mar  1 01:29:41.065: DHCPD: Keeping state: Received DHCPOFFER, from UNNUM-IF
*Mar  1 01:29:41.065:  DHCPD: lease time of offer = 300
*Mar  1 01:29:41.065:  DHCPD: Server Address = 0.0.0.0
*Mar  1 01:29:41.065:  DHCPD: Giaddr Address = 109.XXX.XXX.254
*Mar  1 01:29:41.065: DHCPD: Check for IPe on Vlan1201
*Mar  1 01:29:41.065: DHCPD: creating ARP entry (109.XXX.XXX.24, 0015.60bb.cb17).
*Mar  1 01:29:41.073:  outbound IF index  = 2165
*Mar  1 01:29:41.073:  outbound IF sub-index = 0

 

у 7206:

*Jun  2 23:10:01.947: DHCPD: BOOTREQUEST from 0015.60bb.cb17 forwarded to 10.199.1.23.
*Jun  2 23:10:01.951: DHCPD: forwarding BOOTREPLY to client 0015.60bb.cb17.
*Jun  2 23:10:01.951: DHCPD: No vpn from sub-option, using global
*Jun  2 23:10:01.951: DHCPD: Setting giaddr to 109.XXX.XXX.254
*Jun  2 23:10:01.951: DHCPD: Forwarding reply while saving lease state, on UNNUM-IF
*Jun  2 23:10:01.951: DHCPD: Keeping state: Received DHCPOFFER, from UNNUM-IF
*Jun  2 23:10:01.951:  DHCPD: lease time of offer = 300
*Jun  2 23:10:01.951:  DHCPD: Server Address = 0.0.0.0
*Jun  2 23:10:01.951:  DHCPD: Giaddr Address = 109.XXX.XXX.254
*Jun  2 23:10:01.951: DHCPD: creating ARP entry (109.XXX.XXX.23, 0015.60bb.cb17, vrf default).
*Jun  2 23:10:01.951:  outbound IF index  = 6
*Jun  2 23:10:01.951:  outbound IF sub-index = 1201

 

похоже дело в vrf'е: "DHCPD: creating ARP entry (109.XXX.XXX.23, 0015.60bb.cb17, vrf default)."

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добавил:

no ip dhcp use vrf connected
!
ip dhcp pool mypool
  vrf domonet
  update arp
  relay source 109.XXX.XXX.0 255.255.255.0
  relay destination global 10.199.1.23

 

не помогает. все равно в конце:

 

DHCPD: creating ARP entry (109.XXX.XXX.225, 0015.60bb.cb17, vrf default).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сменил иос - та же фигня. Проблема серьезная, потому как с увеличением масштабов хотелось бы терминировать абонентов по L3 не на районном аггрегирующем свиче (как сейчас), а на одном-двух ASR'ах в центре - это позволит выделить один пул IPv4 адресов и не морочиться с их разбивкой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

это то чего я и боялся. Хотя если будет отдельный линк до каждого свича доступа проблем конечно нет.

 

А в DCN/SNR ещё не запилили транзитный влан? (выключение изучения маков на влане). Если наконец-то сделали, то можно транзит гонять

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А в DCN/SNR ещё не запилили транзитный влан?

пока только в стадии заказа новых железок, еще не пробовал, как получу - скажу :)

 

helper адрес в каком VRF?

в vrf domonet. До dhcp сервера запрос доходит, проблема не в этом. DHCP даже IP выдает для данного opt82 и роутер видит ответ. Только /32 маршруты не заводятся.

 

Для проверки удалил вообще vrf'ы - все заработало. Только мне нужно именно с vrf'ами

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вроде вспомнил. на qtech 2800 есть транзитный влан(но не больше, чем на двух портах), остаётся найти соответсвующий ему SNR

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

helper адрес в каком VRF?

в vrf domonet. До dhcp сервера запрос доходит, проблема не в этом. DHCP даже IP выдает для данного opt82 и роутер видит ответ. Только /32 маршруты не заводятся.

 

Для проверки удалил вообще vrf'ы - все заработало. Только мне нужно именно с vrf'ами

Вопрос в каком VRF сервер видит запрос и в каком отдает.

Точно, маршрут к 10.199.1.23 был в VRF?

Если конфигурацию переносили - могли что-то потерять вполне...

Вот эта строку я не понимаю.

DHCPD: No vpn from sub-option, using global

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Точно, маршрут к 10.199.1.23 был в VRF?

Точно, этот адрес виден только через vrf, а на сервер dhcp запросы приходили

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну вот и контрольный выстрел в пункт 4:

не работает вариант с second-dot1q any

 

Даже без vrf, вот так работает:

ip dhcp relay information policy keep
ip dhcp relay information trust-all

interface Loopback52
ip address 109.XXX.XXX.254 255.255.255.0

interface GigabitEthernet0/3.333
encapsulation dot1Q 333 second-dot1q 1201
ip unnumbered Loopback52
ip helper-address 109.XXX.XXX.23

 

а так уже нет:

ip dhcp relay information policy keep
ip dhcp relay information trust-all

interface Loopback52
ip address 109.XXX.XXX.254 255.255.255.0

interface GigabitEthernet0/3.333
encapsulation dot1Q 333 second-dot1q any
ip unnumbered Loopback52
ip helper-address 109.XXX.XXX.23

 

Значит не получится объединить L3 аггрегацию всех районов в одном роутере (через qinq). Ну не заводить же по 4 тысячи сабинтерфейсов для каждого районного outer влана....

 

Плюс еще с vrf'ами проблема остается.

 

SergeiK

Вот эта строку я не понимаю.

DHCPD: No vpn from sub-option, using global

Похоже циска хочет чтобы dhcp сервер ей сказал vrf. Не видит соответствующей опции и выбирает global. Зачем, ведь есть же конфиг:

ip dhcp use vrf connected

Похоже на баг иоса. У кого-нибудь такое работает?

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тоже проблема с vrf и dhcp релей:

Абоны в глобале на аннамбреде интерфейсах, dhcp-relay в vrf mgmt. Кошка упорно суёт абонентский маршрут в VRF, а не в глобал.

Если ответ на запрос адреса dhcp пришлёт в глобале на giaddr - то маршрут вставляется в глобальную таблицу. ЧЯДНТ?

 


ip dhcp use vrf connected

ip dhcp pool pool1
  vrf gloabal
  relay source 100.64.10.0 255.255.254.0
  relay destination vrf mgmt 10.XXX.XXX.1
!


interface Loopback11
ip address 100.64.11.254 255.255.254.0
end

interface FastEthernet0/1.3104
description 112
encapsulation dot1Q 3104
ip unnumbered Loopback11
ip helper-address vrf mgmt 10.XXX.XXX.1
ip nat inside
no cdp enable
end



 

С хелпером вот так:

Apr 27 08:42:17.050:  DHCPD: lease time = 3600
Apr 27 08:42:17.054:  DHCPD: Server ID saved in Binding = 10.1.0.4
Apr 27 08:42:17.054:  DHCPD: Giaddr Address = 100.64.11.254
Apr 27 08:42:17.054: DHCPD: Adding binding to radix tree (100.64.10.1)
Apr 27 08:42:17.054: DHCPD: VPN 'mgmt'
Apr 27 08:42:17.054: DHCPD: Sending notification of ASSIGNMENT:
Apr 27 08:42:17.054:  DHCPD: address 100.64.10.1 mask 255.255.254.0
Apr 27 08:42:17.054:   DHCPD: htype 1 chaddr c46e.1fbc.8137
Apr 27 08:42:17.054:   DHCPD: lease time remaining (secs) = 3600

 

Если убрать хелпер из интерфейса, то циска в дебаг ругается, что нет пула:

 

Apr 27 09:37:17.875: DHCPD: DHCPDISCOVER received from client 01c4.6e1f.bc81.37 on interface FastEthernet0/1.3104.
Apr 27 09:37:17.875: DHCPD: Seeing if there is an internally specified pool class:
Apr 27 09:37:17.875:   DHCPD: htype 1 chaddr c46e.1fbc.8137
Apr 27 09:37:17.875:   DHCPD: remote id 020a000064400bfe01000c20
Apr 27 09:37:17.875:   DHCPD: circuit id 00000000
Apr 27 09:37:17.875: DHCPD: there is no address pool for 100.64.11.254.

 

Если из пула убрать vrf global, то ситуация в целом не меняется - циска маршрут кладёт в vrf

Apr 27 09:42:42.957: DHCPD: Keeping state: Received DHCPACK, from UNNUM-IF
Apr 27 09:42:42.957:  DHCPD: lease time = 3600
Apr 27 09:42:42.961:  DHCPD: Server ID saved in Binding = 10.1.0.4
Apr 27 09:42:42.961:  DHCPD: Giaddr Address = 100.64.11.254
Apr 27 09:42:42.961: DHCPD: Adding binding to radix tree (100.64.10.1)
Apr 27 09:42:42.961: DHCPD: VPN 'mgmt'
Apr 27 09:42:42.961: DHCPD: Sending notification of ASSIGNMENT:
Apr 27 09:42:42.961:  DHCPD: address 100.64.10.1 mask 255.255.254.0
Apr 27 09:42:42.961:   DHCPD: htype 1 chaddr c46e.1fbc.8137
Apr 27 09:42:42.961:   DHCPD: lease time remaining (secs) = 3600

 

Куда копать? Выносить биллинг из VRF, делать второй интерфейс в глобал, чтобы ответы летели на giaddr уж больно топорно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Похоже, баг иоса: c2800nm-spservicesk9-mz.124-8.bin и c2800nm-spservicesk9-mz.124-25d.bin вели себя одинаково.

c2800nm-spservicesk9-mz.151-4.M10.bin заработала как положено и с ip-helper в интерфейсе и с релеем в пуле.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.