Задача
Необходимо создать внутри одного физического роутера отдельную роутинг таблицу для одного клиента и двух его апстримов.
Иными словами нужно что бы эти три пира «жили» в своей таблице маршрутизации и не имели отношения к основной таблице маршрутизации.
Каждая таблица будет «жить» по своим законам и трафик будет ходить по своим маршрутам.
Имеем
- Juniper M10i
- JUNOS 10.1R1.8
Решение
Решить эту задачу нам поможет routing-instances.
Благодаря им мы можем создать несколько таблиц маршрутизации и явным образом указать для каких интерфейсов роутера её использовать.
Читаем доку: Configuring Routing Instances
Первый возникающий вопрос это какого типа routing-instances нам нужен ? Смотрим описание:
- forwarding—Provide support for filter-based forwarding, where interfaces are not associated with instances. All interfaces belong to the default instance. Other instances are used for populating RPD learned routes. See Configuring Filter-Based Forwarding.
- l2vpn—Provide support for Layer 2 VPNs. For more detailed information about configuring VPNs, see the JUNOS VPNs Configuration Guide.
- layer2-control—(MX Series routers only) Provide support for RSTP or MSTP in customer edge interfaces of a VPLS routing instance. For more detailed information about configuring RSTP and MSTP, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide
- no-forwarding—This is the default routing instance. Do not create a corresponding forwarding instance.
- virtual-router—Similar to a VPN routing and forwarding instance type, but used for non-VPN-related applications. There are no VRF import, VRF export, VRF target, or route distinguisher requirements for this instance type.
- virtual-switch—(MX Series routers only) Provide support for Layer 2 bridging. Use this routing instances type to isolate a LAN segment with its Spanning Tree Protocol (STP) instance and separates its VLAN identifier space. For more detailed information about configuring a virtual switch, see the JUNOS MX Series Ethernet Services Routers Layer 2 Configuration Guide and the JUNOS MX Series Ethernet Services Routers Solutions Guide.
- vpls—Virtual private local-area network (LAN) service. Use this routing instance type for point-to-multipoint LAN implementations between a set of sites in a VPN. For more information about configuring VPLS, see the JUNOS VPNs Configuration Guide.
- vrf—VPN routing and forwarding instance. Provides support for Layer 3 VPNs, where interface routes for each instance go into the corresponding forwarding table only. For more information about configuring VPNs, see the JUNOS VPNs Configuration Guide.
To configure a routing instance type, include the instance-type statement:
routing-instances {
routing-instance-name {
interface interface-name;
instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf);
}
}
Если вы общались с железом от Cisco, то первое что вам бросится в глаза, так это знакомое слово VRF (либо вы уже слышали/настраивали VRF-lite).
В моем случае мне походит тип virtual-router, т.к. VPN`а у меня нет, а все что мне нужно это создать вторую, отдельную от основной, таблицу маршрутизации, которая будет действовать только в пределах данного роутера.
Приступим
Исходные данные для нашего VRF:
VRF апстрим #1:
- подключен к физическому интерфейсу: ge-0/0/1.0
- ASN: 100
- IP-адрес: 1.1.1.1/30
VRF апстрим #2:
- подключен к физическому интерфейсу: ge-0/0/2.0
- ASN: 200
- IP-адрес: 2.2.2.1/30
VRF клиент #1:
- подключен к физическому интерфейсу: ge-0/1/0.0
- ASN: 300
- IP-адрес: 3.3.3.2/30
Назовем наш VRF именем test, а наш номер AS будет 400.
Обращаю ваше внимание так это на то, что конфигурацию протокола BGP у основного роутера мы не трогаем, т.е. никаких изменений туда вносить не надо.
Подмечу, что конфигурацию самих физических интерфейсов и policy-statement (роут мапов) для пиров в нашем VRF нужно производить в режиме конфигурирования основного роутера, а не в routing-instances test.
Заходим в режим конфигурирования:
root@juniper> configure
Затем перейдем в уровень routing-instances:
root@juniper# edit routing-instances
После чего нам нужно задать имя нашего routing-instance (допустим test) и задать в нем остальные настройки, в том числе настройки протокола BGP.
[edit routing-instances]
root@juniper# set test description «test routing table»
Зададим тип routing-instance:
[edit routing-instances]
root@juniper# set test instance-type virtual-router
Затем укажем какие интерфейсы роутера помещать в данный instance (в моем случае это будет три интерфейса, т.к. три пира и каждый в своем интерфейсе, это могут быть как целиком физические интерфейсы, так и вланы):
[edit routing-instances]
root@juniper# set test interface ge-0/0/1.0
root@juniper# set test interface ge-0/0/2.0
root@juniper# set test interface ge-0/1/0.0
Дальнейшая настройка routing-instance ничем не отличается от настройки основного роутера. Те же секции, те же команды. Не буду далее описывать каждую команду и покажу что мы должны получить на выходе по нашему routing-instance test:
[edit]
root@juniper# show routing-instances test
test {
description "test routing table";
instance-type virtual-router;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
interface ge-0/1/0.0;
routing-options {
router-id 1.1.1.2;
autonomous-system 400;
}
protocols {
bgp {
path-selection always-compare-med;
traceoptions {
file bgp_vrf.log size 1m files 10;
}
log-updown;
remove-private;
local-as 400;
group upstreams {
type external;
no-advertise-peer-as;
neighbor 1.1.1.1 {
description VRF_Upstream_1;
import vrf-upstream-1-in;
export vrf-customer;
remove-private;
peer-as 100;
}
neighbor 2.2.2.1 {
description VRF_Upstream_2;
import vrf-upstream-2-in;
export vrf-customer;
peer-as 200;
}
}
group customers {
neighbor 3.3.3.2 {
description VRF_client_1;
import vrf-client-in;
export vrf-client-out;
peer-as 300;
}
}
}
}
}
Собственно на этом конфигурация VRF и закончена. Как видно из конфига мы настроили BGP протокол внутри VRF`а где апстримов поместили в группу upstreams, а нашего клиента в группу customers.
Теперь остается настроить сами физические интерфейсы и создать полиси-мапы (vrf-upstream-1-in, vrf-customer, vrf-upstream-2-in, vrf-customer, vrf-client-in, vrf-client-out).
Напоминаю, что это делается в режиме «глобального» конфигурирования роутера, а не в routing-instance test.
Что мы должны увидеть после коммита данного конфига ?
По команде:
[edit]
root@juniper# run show bgp summary
мы увидим что появилась ещё одна роутинг таблица, в которой перечислены наши VRF пиры.
Так же можно посмотреть что там с маршрутами в нашей routing-instance test:
[edit]
root@juniper# run show route table test.inet.0
Несколько заметок, например запустив пинг до нашего VRF клиента командой:
[edit]
root@juniper# run ping 3.3.3.2
не удивляйтесь что пинга нет, даже при наличии линка на физическом интерфейсе и не торопитесь с выводами, что физика не работает или с той стороны не настроен IP-адрес, просто вы забыли о том, что вы выполняете эту команду из основного роутера, а ведь физический интерфейс в сторону VRF-клиента принадлежит routing-instance test и основной роутер действительно не знает маршрут в эту подсеть.
Меняем команду на:
[edit]
root@juniper# run ping 3.3.3.2 routing-instance test
и вот он наш пинг:
PING 3.3.3.2 (3.3.3.2): 56 data bytes 64 bytes from 3.3.3.2: icmp_seq=0 ttl=255 time=0.660 ms 64 bytes from 3.3.3.2: icmp_seq=1 ttl=255 time=0.647 ms ^C --- 3.3.3.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.647/0.653/0.660/0.007 ms
т.е. мы явно сказали роутеру какой instance использовать для отправки пакетов до хоста 3.3.3.2.
З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.
Автор: Николаев Дмитрий (virus (at) subnets.ru)
(голосов: 3, среднее: 5,00 из 5)
Загрузка...
Отправить на почту
