🥇VxLAN factory. Part 3

Hey Habr. Finishing a series of articles dedicated to the launch of the course "Network engineer" by OTUS, using VxLAN EVPN technology for routing inside the factory and using Firewall to restrict access between internal services

The previous parts of the cycle can be found at the links:

Today we will continue to study the routing logic inside the VxLAN factory. In the previous part, we considered routing within the factory within a single VRF. However, there can be a huge number of client services in the network, and all of them must be distributed to different VRFs in order to differentiate access between them. In addition to network segregation, a business may need to enable a Firewall to restrict access between these services. Yes, this is not the best solution, but modern realities require "modern solutions".

Consider two options for routing between VRFs:

Routing without leaving the VxLAN factory;
Routing on external equipment.

Let's start with the routing logic between VRFs. There is a certain amount of VRF. To route between VRFs, it is necessary to select a device in the network that will know about all VRFs (or parts between which routing is needed). For example, one of the Leaf switches (or all at once) can become such a device. Such a topology would look like this:

What are the disadvantages of such a topology?

That's right, each Leaf needs to know about all the VRFs (and all the information that they contain) on the network, which leads to memory loss and increased network load. After all, quite often each Leaf switch does not need to know about everything that is on the network.

However, let's consider this method in more detail, since for small networks this option is quite suitable (if there are no specific business requirements)

At this point, you may have a question about how to transfer information from VRF to VRF, because the meaning of this technology is precisely that the dissemination of information should be limited.

And the answer lies in such functions as export and import of routing information (the configuration of this technology was considered in second part of the cycle). Let me repeat briefly:

When setting VRF in AF, you must specify route-target for import and export routing information. You can set it automatically. Then ASN BGP and L3 VNI bound to VRF will get into the value. This is handy when you have only one ASN in your factory:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

However, if you have more than one ASN and need to pass routes between them, then manual configuration is more convenient and scalable. route-target. Recommendation in manual setting - the first number, use the one that is convenient for you, for example, 9999.
The second should be made equal to the VNI for that VRF.

Let's set it up like this:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

How it looks in the routing table:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Consider the second option for routing between VRFs - through external equipment, such as a Firewall.

We can assume several options for working through an external device:

The device knows what VxLAN is and we can add it to the factory part;
The device knows nothing about VxLAN.

We will not dwell on the first option, since the logic will be almost the same as shown above - we bring all VRFs to the Firewall and configure routing between VRFs on it.

Consider the second option, when our Firewall knows nothing about VxLAN (now, of course, equipment with VxLAN support appears. For example, Checkpoint announced its support in version R81. You can read about it here, however, this is all at the testing stage and there is no confidence in the stability of the work).

When connecting an external device, we get the following scheme:

As you can see from the diagram, a bottleneck appears at the junction with the Firewall. It is necessary to take this into account in the future when planning a network and optimizing network traffic.

However, let's return to the original task of routing between VRFs. As a result of adding the Firewall, we come to the fact that the Firewall must know about all VRFs. To do this, all VRFs must also be configured on the border Leaf, and we connect the Firewall to each VRF with a separate link.

As a result, the scheme with the Firewall:

That is, on the Firewall, you need to configure an interface to each VRF that is on the network. In general, the logic does not look complicated, and the only thing that you might not like here is the huge number of interfaces on the Firewall, but then it's time to think about automation.

Fine. Connected Firewall, added it to all VRFs. But how now to force traffic from each Leaf to go through this Firewall?

On a Leaf connected to the Firewall, there will be no problems, since all routes are local:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

However, what about deleted Leafs? How to pass them a default external route?

That's right, through EVPN route-type 5, like any other prefix over the VxLAN factory. However, this is not so simple (if we are talking about cisco, as I have not checked with other vendors)

It is necessary to announce the default route from the Leaf to which the Firewall is connected. However, in order to transmit a route, Leaf must know it. And here some problem arises (maybe only for me), the route must be registered as static in the VRF where you want to announce such a route:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Next, in the BGP configuration, set this route to AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

However, this is not all. Thus, the default route will not fall into the family l2vpn evpn. In addition to this, you need to configure redistribution:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Specify which prefixes will get into BGP through redistribution

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Now prefix 0.0.0.0/0 falls into EVPN route-type 5 and is transmitted to the rest of the Leaf:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

In the BGP table, we can also observe the received route-type 5 with the default route through 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

This concludes the series of articles on EVPN. In the future, I will try to consider the work of VxLAN in conjunction with Multicast, since this method is considered more scalable (currently a controversial statement)

If you still have questions / suggestions on the topic, consider any EVPN functionality - write, we will consider it additionally.

Source: habr.com

VxLAN factory. Part 3

Add a comment Отменить ответ