Jump to content

Recommended Posts

Posted

В свете отсутствия на платформе PVLAN edge, для изоляции портов предполагается использовать private-vlan.

private-vlan host работает прекрасно, но возникли проблемы с пониманием работы и имплементацией private-vlan trunk

 

Конфиг

 

vlan 113
 private-vlan primary
 private-vlan association 2113
!
vlan 2113
 private-vlan isolated
!
interface Vlan113
ip address 192.168.2.1 255.255.255.0
ip local-proxy-arp
private-vlan mapping 2113
!
interface GigabitEthernet1/1
switchport private-vlan host-association 113 2113
switchport mode private-vlan host
!
interface GigabitEthernet1/2
switchport private-vlan host-association 113 2113
switchport mode private-vlan host
!
interface GigabitEthernet1/3
switchport private-vlan trunk allowed vlan 1,113
switchport private-vlan mapping trunk 113 2113
switchport mode private-vlan trunk promiscuous
!
interface GigabitEthernet1/4
switchport private-vlan trunk native vlan 1
switchport private-vlan trunk allowed vlan 1,113
switchport private-vlan association trunk 113 2113
switchport mode private-vlan trunk secondary
!
interface GigabitEthernet1/5
switchport private-vlan trunk native vlan 1
switchport private-vlan trunk allowed vlan 1,113
switchport private-vlan association trunk 113 2113
switchport mode private-vlan trunk secondary

 

+ Нетегированные порты (1/1 и 1/2) работают именно так, как и требуется: видят SVI vlan113 (192.168.2.1) и не видят друг друга напрямую (а исключительно через proxyarp, т.к. изолированы по L2)

+ Порт 1/3 работает в тегированном режиме, но, поскольку он promiscuous, то через него видно напрямую как SVI так и устройства, подключённые к портам 1/1 и 1/2. Это тоже нормально и закономерно.

но мне нужна изоляция тегированных портов (точней сегментация виланов в них)

- А вот с портов 1/4 и 1/5, из vlan113, ни SVI, и друг друга не видно. Хотелось, чтобы они работали так же, как и порты 1-2, но с тегированным трафиком, т.е чтобы устройства из vlan113 общались друг с другом исключительно через proxyarp (были изолированы друг от друга на L2).

 

Вопрос, собственно в том, ЧЯНД и КЭЗП?

Posted

Попробовал обойти данную проблему через mac vacl (без private-vlan). Предполагалось, что, если дропнуть на vlan113 все исходящие MAC-адреса, кроме MAC адреса железки (либо входящие с другим маком назначения), работа в обход proxyarp будет исключена, и я получу требуемое.

Но куда там, похоже, на этой платформе (4948, 4900M) MAC VLAN ACLs (и портовые тоже) не работают с IP трафиком. По крайней мере у меня не получилось. Печаль.

 

mac access-list extended ALLOW_IN_113
permit any host a493.xxxx.xxxx ! <- mac железки
!
vlan access-map ALLOW_IN_113 10
match mac address ALLOW_IN_113
action forward
!
vlan filter ALLOW_IN_113 vlan-list 113
!
interface GigabitEthernet1/4
switchport mode trunk
interface GigabitEthernet1/5
switchport mode trunk

 

Или я опять что-то напутал?

Posted
interface GigabitEthernet1/4

switchport private-vlan trunk native vlan 1

switchport private-vlan trunk allowed vlan 1,113

switchport private-vlan association trunk 113 2113

switchport mode private-vlan trunk secondary

!

interface GigabitEthernet1/5

switchport private-vlan trunk native vlan 1

switchport private-vlan trunk allowed vlan 1,2113

switchport private-vlan association trunk 113 2113

switchport mode private-vlan trunk secondary

 

это так и надо?

 

по идее с Gi1/5 все должно работать.

Posted

это так и надо?

 

по идее с Gi1/5 все должно работать.

 

Сори описка, ошибся при копировании. Исправил.

Но по факту не работает...

 

М.б. я всё-таки что-то упустил?

 

Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
113     2113      isolated          Gi1/1, Gi1/2, Gi1/3, Gi1/4, Gi1/5, Gi1/6

 

System image file is "bootflash:cat4500e-entservicesk9-mz.151-2.SG8.bin"

cisco WS-C4948E-F (MPC8548) processor (revision 8) with 1048576K bytes of memory

Posted (edited)

Добрый день!

Насколько я пониманию работу 4500 платформы с dot1q, то в такой конфигурации работать будет следующее:

 

Порты 1/4 и 1/5 принимают тегированный трафик, на SVI же может уходить только "нетегированный" (cisco снимает тег с фрейма, перед тем как подавать его на SVI)

Поэтому они и не будут работать в конфигурации private-vlan trunk + SVI на любой из вланов в транке. Но функционал private vlan они обеспечивать будут - собственно это по вашему описанию мы и видим у Вас.

 

 

Выхода два - SVI "уходит" на другую железку, но тогда теряется суть Private Vlan, либо подаете трафик, которому нужен SVI в виде native.

Ну и третий вариант - искать еще какое-то обходное решение - VACL все должен работать с IP-трафиком. Обновите IOS - может не хватает каких=то features, хотя у меня VACL работал "из коробки" с IP ( но у меня была ME4924:))

Edited by iostream
Posted

Спасибо за ответ. Да, скорей всего так и есть.

 

Возможности поставить ещё одну железку, к сожалению, нет. Остаётся вариант "мутить" с VACL.

 

На данный момент железка в работе, трафик бегает через нетегированные порты, настроенные в switchport mode private-vlan host (как 1 и 2 порт в СТ)

Но нужен именно тегированный трафик, и от private-vlan прийдётся уходить в обычные vlan.

 

Теоретически VACL решили бы всё, но у меня пока не получается настроить фильтрацию IP-трафика на исход таким образом, чтобы отфильтровать весь исходящий трафик по всем MAC-адресам, за исключением собственного мака железки. Ну или фильтровать входящий IP-трафик, адресованный любому маку, кроме, опять же, мака железки.

 

Другими словами, сам коммутатор должен принимать фреймы с любых адресов, но они не должны распространяться по сети далее, через другие порты, т.е. необходимо запретить прямое общение узлам сети в vlan113, подключенных к портам 1/4 и 1/5 соответственно, иначе, чем через local-proxy-arp SVI, навешенного на тот же vlan113.

 

vlan 113
!
interface GigabitEthernet1/4
switchport trunk allowed vlan 1,113
switchport mode trunk
spanning-tree portfast
!
interface GigabitEthernet1/5
switchport trunk allowed vlan 1,113
switchport mode trunk
spanning-tree portfast
!
interface Vlan113
ip address 192.168.2.1 255.255.255.0
ip local-proxy-arp
!

Пример VACL, приведённый во втором сообщении, вообше никак не повлиял на хождение трафика.

 

Есть ещё, правда, костыльное решение - отрезать "входящие" маки на свитчах, подключенных к этим портам (кроме мака SVI), но оно уж очень костыльное, в свете лишнего трафика, льющегося на них из других портов железки.

Posted

Для Cisco 2950 — MAC ACL применяется и для IP, и для non-IP

Для Cisco 2960 — MAC ACL применяется только для non-IP

Для Cisco 6500 — MAC ACL применяется только для non-IP

Но при этом у Cisco 6500 есть фича «Protocol-Independent MAC ACL Filtering», в которой MAC ACL может применяться и к IP, и к non-IP трафику

 

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-1SY/config_guide/sup720/15_1_sy_swcg_720/ios_acl_support.html#21460

 

Protocol-independent MAC ACL filtering applies MAC ACLs to all ingress traffic types (for example, IPv4 traffic, IPv6 traffic, and MPLS traffic, in addition to MAC-layer traffic).

Do not configure protocol-independent MAC ACL filtering on VLAN interfaces where you have configured an IP address.

When the mac acl filtering is enabled, all other protocol features such as RACL, microflow policing will be ignored in the hardware.

 

Что-то есть, только осталось подружить его со SVI.

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.