Appendix: Layer 3 Exit With eBGP Routing Protocol (Full Active/Active Peering)

Fabric Creation

The code block below shows the exported version of the switch template used in this fabric. This allows you to review our setup when importing. As you can see, we have a minimum of two VLANs per VRF. Remember that the L3 exit model requires one VLAN per WAN router and VRF).

Inside the campus fabric configuration dialogue there is a page called “Configure Networks”. This is where you will import your 3*2=6 VLANs from the switch template and the result in our case will look like the image below.

The next step is to create all three VRFs and attach two of the networks to each like that shown below.

Then, go to each VRF and delete all manual routes you may have. Make sure each VRF has a minimum of two VLANs attached as those are used to identify the VRF later.

This is for the second VRF.

This is for the third VRF.

Core1 Switch Configuration

In this example, the service block function is virtual and co-located on the core switch. Therefore, you must configure the two core switches. The following block of pseudocode describes what you need to configure on the core1 switch:

We are sharing a couple of screenshots below that illustrate a major portion of the configuration described above. The first screenshot shows the additional transport VLANs that were defined locally. Only the first two of the six are displayed in the screenshot below. Please note that overlay VLANs, such as VLAN1099, are inherited through the switch template.

Begin with the additional IP configuration. Note that the same VLAN is used between the two service block functions, but each uses different point-to-point IP addresses. Also remember that the transport VLAN serves as a reference to the corresponding VRF when defining the BGP peering.

Here is an example of one of the six transport VLANs to be defined.

In the port configuration, it is essential to use Layer 3 subinterfaces and associate them with the first set of subinterfaces that were defined.

In the second port configuration toward the other WAN router, the remaining subinterfaces are associated accordingly.

The next step is to add all transport VLANs to each VRF as custom networks, so they are recognized within the VRF. As shown, each VRF ultimately contains four networks: two used in the overlay and two additional transport VLANs added at the service block function.

An individual custom VRF would look like the example below.

Note:

When overlay VLANs are added or removed later through a switch template and the campus fabric configuration interface, the same changes must also be made in the custom VRF on the service block function. These VLANs are not added automatically, so if this step is overlooked they will not be advertised to the WAN router.

Now you need to enter the entire eBGP configuration with all six peers as you have three VRFs and two WAN routers. When finished, the overview page should look like the image below:

The next step is to define two routing policies.

In this example, the export route policies include the following terms:

• Term=exclude-default prevents the default route learned from the first WAN router from being exported to the second WAN router, and vice versa.
• Term=fabric-all-no-hosts automatically exports all routes from the fabric across all configured VRFs and their associated VLANs. However, point-to-point links and single-host routes are excluded. This is achieved by using the prefix 0.0.0.0/0-30, where specifying 0-30 in Junos OS represents an “orlonger” prefix range up to /30.
• Term=overlaylo0 exports the overlay loopback IP addresses used for DHCP relay down to the host prefix level, since they are typically assigned individually to lo0.x interfaces. To accomplish this, the prefix 172.16.192.0/24-32 is used, allowing the range to extend down to host-level prefixes, which is not done in the previous statement.

If desired, you can simplify the rule set by using a single term such as 0.0.0.0/0-32 which exports all routes—including those for individual clients in the fabric, represented by their host IP addresses. This approach can also be useful for debugging, as examining the AS path information on the WAN router will reveal which EVPN fabric switch is announcing a given host IP.

The downside, however, is that this approach may result in a large number of routes being exchanged with the WAN router, whereas the default setting of 0.0.0.0/0-30 limits route sharing to prefixes associated only with the configured VLANs.

The import policy imports the default route from the WAN router.

Figure 18 shows the configuration of a single BGP peering entry with the required entries called out.

You must also define the WAN router as a BGP neighbor.

You may see a warning message as shown in Figure 19. It is safe to ignore those.

Note:

When overlay VLANs are added or removed later through a switch template and the campus fabric configuration interface, the same changes must also be made in the custom VRF on the service block function. These VLANs are not added automatically, so if this step is overlooked they will not be advertised to the WAN router.

Core2 Switch Configuration

The following pseudocode represents the configuration you must apply to the core2 switch. The changes from the first WAN router are highlighted.

Aside from the point-to-point subnets and the BGP neighbors, the configuration on the core2 switch is the same as the configuration on the core1 switch.

Juniper MX as a WAN Router

The following code blocks show the Junos OS CLI configuration for the point-to-point interfaces, the complete eBGP configuration with all BGP neighbors, and the import and export route policies for each WAN router. You may need to add default routes and interfaces to complete the configuration, as these must be advertised to the fabric, but we do not know how your device learns those routes.

The CLI configuration for the first WAN router is as follows:

The following is the configuration for the second WAN router:

You can use the following CLI commands to assist with debugging on WAN router1.

You can use the following CLI commands to assist with debugging on WAN router2.

Juniper SRX Series Firewall as WAN Router

The following example table and configurations show the differences between using an SRX Series Firewall in cluster mode and an MX router as the WAN router. On the fabric side, only the interface names of the SRX cluster change from the MX router configuration. Because the SRX Series Firewall runs in active/active cluster mode, there is only a single WAN router configuration and a single ASN to consider. That single configuration also includes cluster management and trust-zone management commands that are not present in a similar MX router-based configuration.

This SRX Series Firewall-based approach is less complicated than configuring redundant ethernet (reth) interfaces and link aggregation groups (LAG) on the MX router. In addition, there is need for additional CLI on the fabric side to insert virtual gateways, and so on.

Preventing Potential Asymmetric Route Issues Using As-Path Prepending

When stateful firewalls are connected to a fabric, there's a potential risk of asymmetric routing. Consider the following scenario: a client outside the fabric initiates a TCP connection to a client inside the fabric via the WAN router. During the initial TCP three-way handshake, the SYN packet is handled by the first WAN router. However, the SYN-ACK response from the fabric client may be processed by the second WAN router since both routers advertise the same default route into the fabric. The fabric, unaware of any preference, may choose the second WAN router due to ECMP load balancing or other internal mechanisms. If the stateful firewalls (acting as WAN routers) do not share session state, the second WAN router may drop the return packet, as it has no record of the session initiated through the first WAN router.

To prevent this issue, you can make the default route advertised by the second WAN router less preferred, ensuring that return traffic, under normal conditions, is directed to the first WAN router. In BGP, this is typically achieved through AS-Path prepending, which makes the route to the second WAN router less attractive. In the SRX cluster configuration shown below, we use two export filters toward the fabric—one of which includes AS-path prepending for the default route. These filters are then applied to the fabric neighbors based on which WAN router should be less preferred.

Once BGP peering with the fabric is established, you can verify the default routes received by the fabric. In the example below, the core1 switch serves as the service block function.

A similar approach is recommended for the fabric configuration to ensure uplink traffic consistently prefers one WAN router. This is achieved by making the routes advertised to the second WAN router less attractive using AS-path prepending. Unlike the MX router example above, which uses a shared “export-vrfs” filter, we now use two separate filters—“export-vrfs0” and “export-vrfs1”—as shown in Figure 22.

They may look the same but all statements in “export-vrfs1” have AP-path prepending configured as in Figure 23.

Once BGP peering with the SRX cluster is established, verify that the AS-path prepends in the fabric are visible, as shown in the example below from the SRX cluster. Start by checking the configuration on the fabric’s service block function—in this case, the core1 switch.

Then, we also ensure that we receive those routes according to our configuration on the SRX cluster as in the example below.

Table 2 shows the configuration information for the core1 and core2 switches as service block function along with the WAN router configuration for the SRX cluster. We’ve marked the changes with respect to Table 1 (for MX WAN routers in bold).

Table 2: SRX Series Firewall WAN Router and Core Switch Configuration Summary

Switch	Switch AS	VRF	Core P2P IP	Core IF	WAN Router	WAN Router P2P IP	WAN Router AS	WAN Router IF	VLAN ID
core1	64911	customera	10.255.224.1/31	ge-0/0/5.101	node0	10.255.224.0/31	64901	ge-0/0/2.101	101
core1	64911	customerb	10.255.224.3/31	ge-0/0/5.102	node0	10.255.224.2/31	64901	ge-0/0/2.102	102
core1	64911	devices	10.255.224.5/31	ge-0/0/5.103	node0	10.255.224.4/31	64901	ge-0/0/2.103	103
core1	64911	customera	10.255.225.1/31	ge-0/0/6.101	node1	10.255.225.0/31	64901	ge-7/0/2.101	101
core1	64911	customerb	10.255.225.3/31	ge-0/0/6.102	node1	10.255.225.2/31	64901	ge-7/0/2.102	102
core1	64911	devices	10.255.225.5/31	ge-0/0/6.103	node1	10.255.225.4/31	64901	ge-7/0/2.103	103
core2	64911	customera	10.255.226.1/31	ge-0/0/5.201	node0	10.255.226.0/31	64901	ge-0/0/3.201	201
core2	64911	customerb	10.255.226.3/31	ge-0/0/5.202	node0	10.255.226.2/31	64901	ge-0/0/3.202	202
core2	64911	devices	10.255.226.5/31	ge-0/0/5.203	node0	10.255.226.4/31	64901	ge-0/0/3.203	203
core2	64911	customera	10.255.227.1/31	ge-0/0/6.201	node1	10.255.227.0/31	64901	ge-7/0/3.201	201
core2	64911	customerb	10.255.227.3/31	ge-0/0/6.202	node1	10.255.227.2/31	64901	ge-7/0/3.202	202
core2	64911	devices	10.255.227.5/31	ge-0/0/6.203	node1	10.255.227.4/31	64901	ge-7/0/3.203	203

The following pseudocode describes what you need to configure on the core1 switch for this example:

The following pseudocode describes what you need to configure on the core2 switch for this example:

When finished configuring the individual service block functions (here, the core1 and core2 switches) your overview table should be as shown in Figure 24.

Figure 24 shows an overview of how the BGP looks after you have configured the individual service block functions for the core1 and core2 switches.

The following Junos OS CLI represents the entire configuration needed on the SRX Series Firewall cluster for this example.