В последнее время не редко можно встретить упоминание концепции vCPE – виртуальной CPE на стороне оператора, технически это означает L2 до оператора (т.е оператор терминирует все абонентские устройства). Причины такого подхода могут быть разные – от персонифицированного родительского контроля до нежелания/неспособности абонента настраивать свою CPE (пробрасывать порты, вешать ACL-и т.п). В этой заметке рассматривается следующий сценарий: каждому абоненту выделяется статический внешний IP, локальная сеть пробрасывается отдельным вланом до устройства vCPEs, в локальной сети используется адресация 192.168.1.0/24 (по желанию абонента может быть изменена), абоненту предоставляются сервисы DHCP, source NAT и NAT port forwarding. В примере используется оборудование Cisco 7200 с ПО “c7200-advipservicesk9-mz.152-4.S5.bin”, но аналогичная конфигурация может быть применена и на современном оборудовании Cisco с ПО IOS или IOS-XE.
Конфигурация ASBR (относящаяся к поставленной задаче):
hostname ASBR ! interface GigabitEthernet0/0 description to-vCPEs ip address 192.0.2.1 255.255.255.252 //p-t-p сеть между ASBR и vCPEs ! ip route 198.51.100.0 255.255.255.0 192.0.2.2 //198.51.100.0/24 - выделенная сеть белых адресов под виртуальные CPE
Конфигурация vCPEs: базовые настройки:
hostname vCPEs ! interface GigabitEthernet1/0 description to-ASBR ip address 192.0.2.2 255.255.255.252 //p-t-p сеть для между ASBR и vCPEs ip nat outside //исходящий NAT-интерфейс (смотрит в интернет) negotiation auto ! interface GigabitEthernet2/0 description to-Clients no ip address negotiation auto ! ip vrf Client1 //создаём vrf для 1ого клиента ! ip vrf Client2 //создаём vrf для 2ого клиента ! interface GigabitEthernet2/0.11 encapsulation dot1Q 11 //выделяем 11-ый vlan 1ому клиенту ip vrf forwarding Client1 //помещаем этот сабынтрфейс в vrf Client1 ip address 192.168.1.1 255.255.255.0 ip nat inside //входящий NAT-интерфейс (смотрит в сторону клиента) ! interface GigabitEthernet2/0.12 encapsulation dot1Q 12 //выделяем 12-ый vlan 2ому клиенту ip vrf forwarding Client2 //помещаем этот сабынтрфейс в vrf Client2 ip address 192.168.1.1 255.255.255.0 ip nat inside //входящий NAT-интерфейс (смотрит в сторону клиента)
Маршрутизация:
ip route 0.0.0.0 0.0.0.0 192.0.2.1 //маршрут по умолчанию на asbr ip route 198.51.100.0 255.255.255.0 Null0 //предотвращение петли маршрутизации для трафика, которые не попадает под таблицу трансляций ip route vrf Client1 0.0.0.0 0.0.0.0 192.0.2.1 global //маршрут по умолчанию для клиента 1 (поскольку клиент находит в vrf, а интернет в GRT, дописываем global) ip route vrf Client2 0.0.0.0 0.0.0.0 192.0.2.1 global //маршрут по умолчанию для клиента 2 (поскольку клиент находит в vrf, а интернет в GRT, дописываем global)
Настройка NAT:
ip access-list standard Client1 //локальные IP-адреса 1ого клиента, которые будут попадать под NAT permit 192.168.1.0 0.0.0.255 ! ip access-list standard Client2 //локальные IP-адреса 1ого клиента, которые будут попадать под NAT permit 192.168.1.0 0.0.0.255 ! ip nat pool Client1 198.51.100.0 198.51.100.0 prefix-length 16 //Внешний IP-адрес 1ого клиента ip nat pool Client2 198.51.100.1 198.51.100.1 prefix-length 16 //Внешний IP-адрес 2ого клиента ! ip nat inside source list Client1 pool Client1 vrf Client1 overload //привязка 1ого клиента к его внешнему IP-адресу ip nat inside source list Client1 pool Client2 vrf Client2 overload //привязка 2ого клиента к его внешнему IP-адресу ! ip nat inside source static tcp 192.168.1.10 23 198.51.100.0 23 vrf Client1 extendable //пример проброса порта 198.51.100.0:23 на 192.168.1.10:23 для 1ого клиента ip nat inside source static tcp 192.168.1.10 23 198.51.100.1 23 vrf Client2 extendable //пример проброса порта 198.51.100.1:23 на 192.168.1.10:23 для 2ого клиента
Относительно “prefix-length 16” – нужно задавать такой prefix-length, чтобы выбранный адрес не был network- или broadcast-адресом, иначе Cisco не даст его использовать. Т.е если вы хотите использовать внешний IP 200.0.0.0, то prefix-length должен быть 7 или меньше.
Настройка DHCP-сервиса для клиентов:
ip dhcp pool Client1 //именной пул для 1ого клиента vrf Client1 //привязка пула к vrf 1ого клиента network 192.168.1.0 255.255.255.0 //сеть из которой выдавать адреса default-router 192.168.1.1 //шлюз по умолчанию, который выдавать 1ому клиенту dns-server 203.0.113.1 203.0.113.2 //dns-сервера, которые выдавать 1ому клиенту ! ip dhcp pool Client2 //именной пул для 2ого клиента vrf Client2 //привязка пула к vrf 2ого клиента network 192.168.1.0 255.255.255.0 //сеть из которой выдавать адреса default-router 192.168.1.1 //шлюз по умолчанию, который выдавать 1ому клиенту dns-server 203.0.113.1 203.0.113.2 //dns-сервера, которые выдавать 2ому клиенту ! ip dhcp excluded-address vrf Client1 192.168.1.2 192.168.1.10 //исключение некоторых адресов .2-.10, чтобы 1ый клиент мог их назначать статически, без dhcp ip dhcp excluded-address vrf Client2 192.168.1.2 192.168.1.10 //исключение некоторых адресов .2-.10, чтобы 2ой клиент мог их назначать статически, без dhcp
Конфигурация свитча ISP-switch:
Настройка завершена. Запросим IP-адрес по DHCP с клиента 1 и клиента 2, посмотрим таблицу dhcp-bindings на vCPEs:
vCPEs#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type State Interface
Bindings from VRF pool Client1:
IP address Client-ID/ Lease expiration Type State Interface
192.168.1.11 0063.6973.636f.2d63. Nov 09 2014 08:57 PM Automatic Active GigabitEthernet2/0.11
6130.612e.3031.3564.
2e30.3030.382d.4769.
302f.30
Bindings from VRF pool Client2:
IP address Client-ID/ Lease expiration Type State Interface
192.168.1.11 0063.6973.636f.2d63. Nov 09 2014 08:57 PM Automatic Active GigabitEthernet2/0.12
6130.392e.3031.3564.
2e30.3030.382d.4769.
302f.30
Из этой таблицы видно, что dhcp-сервис работает per-vrf, как нам и надо.
Проверка пингом:
Client2#ping 192.0.2.1 repeat 2 Type escape sequence to abort. Sending 2, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds: !! Success rate is 100 percent (2/2), round-trip min/avg/max = 80/86/92 ms ASBR# debug ip icmp *Nov 8 22:35:40.647: ICMP: echo reply sent, src 192.0.2.1, dst 198.51.100.1 *Nov 8 22:35:40.739: ICMP: echo reply sent, src 192.0.2.1, dst 198.51.100.1
Client1#ping 192.0.2.1 repeat 2 Type escape sequence to abort. Sending 2, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds: !! Success rate is 100 percent (2/2), round-trip min/avg/max = 40/46/52 ms ASBR# debug ip icmp *Nov 8 22:37:23.823: ICMP: echo reply sent, src 192.0.2.1, dst 198.51.100.0 *Nov 8 22:37:23.867: ICMP: echo reply sent, src 192.0.2.1, dst 198.51.100.0
Как видно, Client1 пронатился в 198.51.100.0, а Client2 в 198.51.100.1
Проверка проброса портов (для этого назначим на Client1 и Client2 статический адрес 192.168.1.10/24):
ASBR#telnet 198.51.100.0 23 Trying 198.51.100.0 ... Open User Access Verification Password: Client1>exit [Connection to 198.51.100.0 closed by foreign host] ASBR#telnet 198.51.100.1 23 Trying 198.51.100.1 ... Open User Access Verification Password: Client2>exit [Connection to 198.51.100.1 closed by foreign host]
И под конец, примеры как посмотреть таблицу трансляций (чтобы узнать к какому vrf относится трансляция нужно использовать verbose):
vCPEs#show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 198.51.100.0:23 192.168.1.10:23 --- --- icmp 198.51.100.0:1024 192.168.1.10:25 192.0.2.1:25 192.0.2.1:1024 tcp 198.51.100.1:23 192.168.1.10:23 --- --- ...
vCPEs#show ip nat translations verbose
Pro Inside global Inside local Outside local Outside global
tcp 198.51.100.1:1024 192.168.1.11:49179 192.0.2.1:23 192.0.2.1:23
create 00:00:03, use 00:00:01, left 00:00:58, Map-Id(In): 2,
flags:
extended, timing-out, use_count: 0, VRF : Client2, entry-id: 1, lc_entries: 0
...
Net-Labs.in 
Давно хотел посмотреть пример использования данного функционала. Спасибо за статью)
Вы серъезно ? Настраивать все это руками предлагаете ? Как минимум можно загружать настройки на порт через ISG.
Почему руками? Никто не запрещает всё это заливать скриптами.
Относительно ISG тут не очень понятно как реализовать сам процесс терминации. Если говорить про платформу asr1k, то первая проблема в том, что q-in-q termination с ambigious vlan не работает с vrf selection (когда вы из radius-а говорите какой это будет vrf), вторая, что subnet session не работает с vrf selection. На asr9k не пробовал.
По крайней мере, для B2B-кастомеров (т.е. не объёмах 100к+) это можно реализовать так как описано в этой статье (руками или скриптами это уже по вашему желанию)