- Routing
- Manage Static Routes
- Static Multicast Routes
- Static Routing via ip route
- Apply a Route Map for Route Updates
- Configure a Gateway or Default Route
- Supported Route Table Entries
- Forwarding Table Profiles
- Number of Supported Route Entries By Platform
- Mellanox Spectrum Switches
- Broadcom Tomahawk/Tomahawk+ Switches
- Broadcom Trident II/Trident II+/Trident3 Switches
- Broadcom Helix4 Switches
- TCAM Resource Profiles for Spectrum Switches
- Route Entry Takes Precedence Over Neighbor Entry
- Caveats and Errata
- Do Not Delete Routes through Linux Shell
- Using NCLU Commands to Delete Routing Configuration
- Add IPv6 Default Route with src Address on eth0 Fails without Adding Delay
- Use the Same Neighbor Cache Aging Timer for IPv4 and IPv6
- Static Multicast Routing
- Содержание
- Ссылки [ править ]
- Общие понятия [ править ]
- Подготовка шлюза [ править ]
- Конфигурация [ править ]
- Настройка маршрутизации [ править ]
- Проверка работы [ править ]
- Настройка статической маршрутизации [ править ]
Routing
This chapter discusses routing on switches running Cumulus Linux.
Manage Static Routes
Static routes are added to the FRRouting routing table and then the kernel routing table.
To add static routes:
The NCLU and vtysh commands save the configuration in the /etc/frr/frr.conf file. For example:
To delete a static route:
To view static routes, run the NCLU net show route static command or the vtysh show ip route command. For example:
Static Multicast Routes
To add a static multicast route (mroute):
The NCLU and vtysh commands save the configuration in the /etc/frr/frr.conf file. For example:
To delete an mroute:
To view mroutes, run the following command from the vtysh shell:
Static Routing via ip route
You can also create a static route by adding the route to a switch port configuration. For example:
The NCLU and vtysh commands save the configuration in the /etc/network/interfaces file. For example:
The ip route command allows you to manipulate the kernel routing table directly from the Linux shell. See man ip(8) for details. FRRouting monitors the kernel routing table changes and updates its own routing table accordingly.
To display the routing table:
Apply a Route Map for Route Updates
To apply a route map to filter route updates from Zebra into the Linux kernel:
The NCLU and vtysh commands save the configuration in the /etc/frr/frr.conf file. For example:
Configure a Gateway or Default Route
Consider creating a gateway or default route on each switch for traffic destined outside the switch’s subnet or local network. All such traffic passes through the gateway, which is a host on the same network that routes packets to their destination beyond the local network.
In the following example, you create a default route in the routing table 0.0.0.0/0, which indicates any IP address can be sent to the gateway, which is another switch with the IP address 10.1.0.1.
The NCLU and vtysh commands save the configuration in the /etc/frr/frr.conf file. For example:
The default route created by the gateway parameter in ifupdown2 is not installed in FRR, so cannot be redistributed into other routing protocols. See ifupdown2 and the gateway Parameter for more information.
Supported Route Table Entries
Cumulus Linux (via switchd) advertises the maximum number of route table entries that are supported on a given switch architecture, including:
- Layer 3 IPv4 LPM (longest prefix match) entries that have a mask less than /32
- Layer 3 IPv6 LPM entries that have a mask of /64 or less
- Layer 3 IPv6 LPM entries that have a mask greater than /64
- Layer 3 IPv4 neighbor (or host) entries that are the next hops seen in ip neighbor
- Layer 3 IPv6 neighbor entries that are the next hops seen in ip -6 neighbor
- ECMP next hops, which are IP address entries in a router’s routing table that specify the next closest/most optimal router in its routing path
- MAC addresses
In addition, switches on the Tomahawk, Trident II, Trident II+, and Trident3 platforms are configured to manage route table entries using Algorithm Longest Prefix Match (ALPM). In ALPM mode, the hardware can store significantly more route entries.
You can use either the NCLU net show system asic command or the cl-resource-query to determine the current table sizes on a given switch.
Forwarding Table Profiles
On Mellanox Spectrum and some Broadcom ASICs, you can configure the allocation of forwarding table resources and mechanisms. Cumulus Linux provides a number of generalized profiles for the platforms described below. These profiles work only with layer 2 and layer 3 unicast forwarding.
Cumulus Linux defines these profiles as default, l 2-heavy, v4-lpm-heavy and v6-lpm-heavy. Choose the profile that best suits your network architecture and specify the profile name for the forwarding_table.profile variable in the /etc/cumulus/datapath/traffic.conf file.
After you specify a different profile, restart switchd for the change to take effect. You can see the forwarding table profile when you run cl-resource-query .
Broadcom ASICs other than Maverick, Tomahawk/Tomahawk+, Trident II, Trident II+, and Trident3 support only the default profile.
For Broadcom ASICs, the maximum number of IP multicast entries is 8k.
Number of Supported Route Entries By Platform
The following tables list the number of MAC addresses, layer 3 neighbors, and LPM routes validated for each forwarding table profile for the various supported platforms. If you do not specify any profiles as described above, the default values are the ones that the switch will use.
The values in the following tables reflect results from testing on the different platforms that Cumulus Linux supports, which might differ from published manufacturer specifications.
Mellanox Spectrum Switches
L3 Neighbors
Broadcom Tomahawk/Tomahawk+ Switches
| Profile | MAC Addresses | L3 Neighbors | Longest Prefix Match (LPM) |
|---|---|---|---|
| default | 40k | 40k | 64k (IPv4) or 8k (IPv6-long) |
| l2-heavy | 72k | 72k | 8k (IPv4) or 2k (IPv6-long) |
| v4-lpm-heavy v6-lpm-heavy | 8k | 8k | 128k (IPv4) or 20k (IPv6-long) |
Broadcom Trident II/Trident II+/Trident3 Switches
| Profile | MAC Addresses | L3 Neighbors | Longest Prefix Match (LPM) |
|---|---|---|---|
| default | 32k | 16k | 128k (IPv4) or 20k (IPv6-long) |
| l2-heavy | 160k | 96k | 8k (IPv4) or 2k (IPv6-long) |
| v4-lpm-heavy v6-lpm-heavy | 32k | 16k | 128k (IPv4) or 20k (IPv6-long) |
Broadcom Helix4 Switches
Helix4 switches do not have profiles.
| MAC Addresses | L3 Neighbors | Longest Prefix Match (LPM) |
|---|---|---|
| 24k | 12k | 7.8k (IPv4) or 2k (IPv6-long) |
For Broadcom switches, IPv4 and IPv6 entries are not carved in separate spaces so it is not possible to define explicit numbers in the L3 Neighbors column of the tables shown above. An IPv6 entry takes up twice the space of an IPv4 entry.
TCAM Resource Profiles for Spectrum Switches
On the Mellanox Spectrum ASIC, you can configure TCAM resource allocation, which is shared between IP multicast forwarding entries and ACL tables. Cumulus Linux provides a number of general profiles for this platform: default, ipmc-heavy and acl-heavy. Choose the profile that best suits your network architecture and specify that profile name in the tcam_resource.profile variable in the /usr/lib/python2.7/dist-packages/cumulus/__chip_config/mlx/datapath.conf file.
After you specify a different profile, restart switchd for the change to take effect.
When nonatomic updates are enabled ( acl.non_atomic_update_mode is set to TRUE in the /etc/cumulus/switchd.conf file), the maximum number of mroute and ACL entries for each profile are:
| Profile | Mroute Entries | ACL Entries |
|---|---|---|
| default | 1000 | 500 (IPv6) or 1000 (IPv4) |
| ipmc-heavy | 8500 | 1000 (IPv6) or 1500 (IPv4) |
| acl-heavy | 450 | 2000 (IPv6) or 3500 (IPv4) |
| ipmc-max | 13000 | 1000 (IPv6) or 2000 (IPv4) |
When nonatomic updates are disabled ( acl.non_atomic_update_mode is set to FALSE in the /etc/cumulus/switchd.conf file), the maximum number of mroute and ACL entries for each profile are:
| Profile | Mroute Entries | ACL Entries |
|---|---|---|
| default | 1000 | 250 (IPv6) or 500 (IPv4) |
| ipmc-heavy | 8500 | 500 (IPv6) or 750 (IPv4) |
| acl-heavy | 450 | 1000 (IPv6) or 1750 (IPv4) |
| ipmc-max | 13000 | 500 (IPv6) or 1000 (IPv4) |
Route Entry Takes Precedence Over Neighbor Entry
On Broadcom switches with Cumulus Linux 4.0 and later, when there is a /32 IPv4 or /128 IPv6 route and the same prefix is also a neighbor entry in the linux kernel, the route entry takes precedence over the neighbor entry in the forwarding lookup. To change this behaviour, update the route_preferred_over_neigh variable to FALSE in the /etc/cumulus/switchd.conf file.
Caveats and Errata
Do Not Delete Routes through Linux Shell
Do not use the Linux shell to delete static routes added via FRRouting (with vtysh commands). Delete the routes with the vtysh commands; otherwise FRRouting might not be able to clean up its internal state completely, which can result in incorrect routing.
Using NCLU Commands to Delete Routing Configuration
When you use NCLU commands to delete routing (FRR) configuration, such as static routes or route map rules (multiples of which can exist in a configuration), commit ten or fewer delete commands at a time to avoid commit failures.
Add IPv6 Default Route with src Address on eth0 Fails without Adding Delay
Attempting to install an IPv6 default route on eth0 with a source address fails at reboot or when running ifup on eth0.
The first execution of ifup -dv returns this warning and does not install the route:
Running ifup a second time on eth0 successfully installs the route.
To work around this issue, either add a two second delay or exclude the src parameter to the ip route add that causes the need for the delay:
- Add a delay to the eth0 interface:
- Exclude the src parameter to the ip route add that causes the need for the delay. If the src parameter is removed, the route is added correctly.
Use the Same Neighbor Cache Aging Timer for IPv4 and IPv6
Cumulus Linux does not support different neighbor cache aging timer settings for IPv4 and IPv6.
Источник
Static Multicast Routing
Настройка статической multicast-маршрутизации на дистрибутивах ALT Linux.
Содержание
Ссылки [ править ]
Общие понятия [ править ]
Рассмотрим типичную схему multicast-маршрутизации с выделенным сервером, имеющим два сетевых интерфейса:
- eth0 — публичный интерфейс, на который придет поток от провайдера;
- eth1 — интерфейс в локальную сеть, в которой находятся клиенты.
Multicast-маршрутизация осуществляется по протоколу IGMP. IGMP (англ. Internet Group Management Protocol — протокол управления группами Интернета) — протокол управления групповой (multicast) передачей данных в сетях, основанных на протоколе IP. В данном руководстве используется IGMP версии 1.
На шлюзе должна быть разрешена пересылка сетевых пакетов (forwarding) и запущен демон multicast-маршрутизации. Мы рекомендуем использовать в качестве такого демона igmpproxy. При этом клиенты должны явно присоединиться к MC-группе. Вы можете явно назначить multicast-маршруты без этого требования к клиентам, если используете пакет smcroute.
Примечание: интерфейсы в дистрибутивах на базе Пятой платформы будут соответственно breth0 и breth1, однако мы не рекомендуем делать на них маршрутизацию.
Подготовка шлюза [ править ]
Для начала необходимо установить дистрибутив ALT Linux и пакет демон multicast-маршрутизации igmpproxy и программу настройки статических маршрутов smcroute из соответствующего репозитория:
Также необходимы пакеты iptables net-tools iproute2, в дистрибутивах ALT Linux они присутствуют по умолчанию.
Для мониторинга можно установить пакеты tcpdump, wireshark и iperf
Все манипуляции осуществляются под правами пользователя root.
Конфигурация [ править ]
Для дистрибутивов на базе Пятой платформы файл /etc/igmpproxy.conf вместо eth0 и eth1 исполь-зуйте breth0 и breth1 соответственно.
Настройка маршрутизации [ править ]
1. Шлюз должен быть настроен для маршрутизации сетевых пакетов:
- Находится в режиме «Шлюз» в модуле «Брандмауэр» в дистрибутивах на базе Пятой платформы;
- или настраиваем вручную: в файле /etc/net/sysctl.conf параметр net.ipv4.ip_forward должен быть установлен в «1»:
Также в файл /etc/net/sysctl.conf добавляем параметры: отключаем reverse path filtering для eth0 и для ядер 2.6.x указываем версию IGMP (igmpproxy поддерживает только IGMPv1 и IGMPv2 на внутреннем интерфейсе):
Примечание: после внесения изменений в этот файл необходимо перезагрузить компьютер.
2. Проверяем готовность к маршрутизации:
3. Настраиваем цепочки iptables для работы со специальными multicast-подсетями:
4. Прописываем маршрут:
5. Запускаем демона:
Журнал работы igmpproxy ведётся в /var/log/messages. Для отладки можно запустить командой igmpproxy -d /etc/igmpproxy.conf
Проверка работы [ править ]
После запуска igmpproxy должны появится соответствующие флаги:
В файлах состояния ядра появятся записи:
Маршруты можно найти в файлах:
Виртуальные интерфейсы для маршрутизации:
Настройка статической маршрутизации [ править ]
Для статической маршрутизации демон igmpproxy запускать не нужно.
1. Запускаем демон:
2. Настраиваем маршруты:
- eth0 — входящий интерфейс для трафика
- 10.1.0.18 — адрес интерфейса-источника трафика (можно получить по команде tcpdump -i eth0 dst host 224.2.2.2)
- 224.2.2.2 — MC-группа в сети 224.0.0.0/4
- eth1 — один или несколько внешних интерфейсов
Источник
