Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Appendix: Layer 3 Exit With OSPF Routing Protocol

Note:

When doing any VLAN or VRF creation with campus fabric, use the following best practices:

  1. All overlay VLANs should be created only through a switch template and then imported into the campus fabric configuration. Creating overlay VLANs in other places, such as directly on a switch, can eventually lead to inconsistencies that make troubleshooting more difficult.

  2. Two additional transport VLANs must be created for each VRF. Refer to the guidance below for further recommendations.

  3. ADo not create VRFs manually, either in the switch template or directly on a switch. If required, the fabric will create them automatically, so it is important not to interfere with this process.

  4. Port profiles are also best created through switch templates to ensure that any changes remain synchronized across all switches in the fabric.

Before starting, a design must be created to determine how the routing protocol exchange will be implemented, how the point-to-point links will be configured, and how VLAN assignments will be distributed to indirectly identify the VRF. Even if a VRF is already created elsewhere in the fabric, such as on an access switch in an IP Clos design, the system will automatically recreate it on all service block functions when a Layer 3 exit is configured.

For each WAN router connection, an additional transport VLAN must be added to the VRF and then configured as a custom VRF on the service block function. Because this design uses two WAN routers, each VRF requires two additional transport VLANs on the service block function to establish OSPF peering. When using transport VLANs, they must not be included in the overlay network definition of the EVPN fabric. These VLANs can be added to the switch template as long as they are not selected in the campus fabric configuration dialogue when defining networks. As an alternative, they can be created only on the service block function where they are locally required. All transport VLANs should be created with only a network name and a VLAN ID.

When defining point-to-point links, choose IP addresses from a range that does not overlap with the range used by the fabric, which by default is 10.255.240.0/20. A /31 subnet mask is commonly used, assigning the even IP address to the WAN router and the odd IP address to the fabric as a convention.

The system requires a VLAN to be defined for each point-to-point link over a physical connection. This approach allows multiple VRFs to be multiplexed over a single uplink cable, with the VLAN internally referencing the associated VRF.

When using OSPF, each VRF and service block function must have its own OSPF router ID to exchange routes with the redundant WAN routers. On the WAN routers, a global OSPF router ID can be used, as shown in this example. Do not confuse these with the EVPN fabric router IDs displayed in the Juniper Mist portal for each EVPN fabric switch. Those router IDs are controlled by the EVPN fabric and cannot be modified in this configuration

.

Figure 1: Router-ID Router-ID

The use of individual OSPF router IDs on the EVPN fabric is necessary because a single global router ID shared across VRFs can lead to missed route updates from the WAN router to certain VRFs. When a global router ID is used on the EVPN fabric, the WAN router may assume that it has already sent the route update to the OSPF neighbor, the fabric, and may therefore skip sending updates over other links where different VRFs of the EVPN fabric are connected. Assigning a unique OSPF router ID to each VRF and service block function ensures that route updates are properly exchanged across all established point-to-point links.

To provide unique router IDs for OSPF neighbor relationships toward the WAN router, the Juniper Mist cloud uses the loopback per-VRF IPv4 subnet pool defined in the campus fabric configuration dialogue. This pool is typically used to generate individual IP addresses for DHCP relay. For OSPF, the same IP addresses assigned as lo0.x loopback interfaces are also used as the individual OSPF router IDs.

Figure 2: Overlay Loopback IP-Address Pool Overlay Loopback IP-Address Pool

The default pool range is 172.16.192.0/24. You can review what your service block function will use as an OSPF Router ID in the Juniper Mist portal on the statistics pane. Please note that lo0.0 is always the EVPN router ID managed by a different pool and cannot be modified.

Figure 3: Individual overlay Loopback IP assignments Individual overlay Loopback IP assignments

The picture below shows how the two service block functions of the fabric connect to the first WAN router.

Figure 4: OSPF to WAN Router 1 OSPF to WAN Router 1

The picture below shows how the two service block functions of the fabric connect to the second WAN router. Notice that we now use the second block of VLANs from each VRF.

Figure 5: OSPF to WAN Router 2 OSPF to WAN Router 2

Below is the full configuration table between core1 and core2 as the service block function and the two WAN routers. OSPF area 0.0.0.0 was used among all peers.

Table 1: OSPF Configuration Table
Switch VRF OSPF Router ID Core P2P IP Core IF WAN Router OSPF Router ID WAN Router P2P IP WAN Router IF VLAN ID
core1 customera Mist managed 10.255.224.1/31 ge-0/0/3.101 wanrouter1 10.23.42.1 (global) 10.255.224.0/31 ge-0/0/1.101 101
core1 customerb Mist managed 10.255.224.3/31 ge-0/0/3.102 wanrouter1 10.23.42.1 (global) 10.255.224.2/31 ge-0/0/1.102 102
core1 devices Mist managed 10.255.224.5/31 ge-0/0/3.103 wanrouter1 10.23.42.1 (global) 10.255.224.4/31 ge-0/0/1.103 103
core1 customera Mist managed 10.255.225.1/31 ge-0/0/4.201 wanrouter2 10.23.42.2 (global) 10.255.225.0/31 ge-0/0/1.201 201
core1 customerb Mist managed 10.255.225.3/31 ge-0/0/4.202 wanrouter2 10.23.42.2 (global) 10.255.225.2/31 ge-0/0/1.202 202
core1 devices Mist managed 10.255.225.5/31 ge-0/0/4.203 wanrouter2 10.23.42.2 (global) 10.255.225.4/31 ge-0/0/1.203 203
core2 customera Mist managed 10.255.226.1/31 ge-0/0/3.101 wanrouter1 10.23.42.1 (global) 10.255.226.0/31 ge-0/0/2.101 101
core2 customerb Mist managed 10.255.226.3/31 ge-0/0/3.102 wanrouter1 10.23.42.1 (global) 10.255.226.2/31 ge-0/0/2.102 102
core2 devices Mist managed 10.255.226.5/31 ge-0/0/3.103 wanrouter1 10.23.42.1 (global) 10.255.226.4/31 ge-0/0/2.103 103
core2 customera Mist managed 10.255.227.1/31 ge-0/0/4.201 wanrouter2 10.23.42.2 (global) 10.255.227.0/31 ge-0/0/2.201 201
core2 customerb Mist managed 10.255.227.3/31 ge-0/0/4.202 wanrouter2 10.23.42.2 (global) 10.255.227.2/31 ge-0/0/2.202 202
core2 devices Mist managed 10.255.227.5/31 ge-0/0/4.203 wanrouter2 10.23.42.2 (global) 10.255.227.4/31 ge-0/0/2.203 203

Fabric Creation

Below, we are sharing the exported version of the switch template used in this fabric. This will allow you to review our setup when importing. The two transport VLANs for each VRF were created on the service block function itself.

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.

Figure 6: Network import from Switch Template A screenshot of a computer Description automatically generated

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

Figure 7: Create 3 VRF's A screenshot of a computer Description automatically generated

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.

Figure 8: Networks assign to first VRF A screenshot of a computer Description automatically generated

This is for the second VRF.

Figure 9: Networks assign to second VRF A screenshot of a computer Description automatically generated

This is for the third VRF.

Figure 10: Networks assign to third VRF A screenshot of a computer Description automatically generated

Core1 Switch Configuration

In our case, the service block function is virtual and colocated on the core switch, hence we must configure the two core switches. Below is a description of what you need to configure on the core1 switch:

Below are several screenshots that illustrate key parts of the configuration described above. The first screenshots show the additional transport VLANs that were defined locally. In the example below, only the first two of the six transport VLANs are displayed. Note that overlay VLANs, such as VLAN1099, are inherited from the switch template.

Figure 11: Local Networks on service block function Local Networks on service block function

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.

Figure 12: Additional IP-Address for transport Networks Additional IP-Address for transport Networks

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

Figure 13: Peering IP-Address for transport VLAN Peering IP-Address for transport VLAN

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

Figure 14: Transport VLANs Port configuration for first WAN-Router Transport VLANs Port configuration for first WAN-Router

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

Figure 15: Transport VLANs Port configuration for second WAN-Router Transport VLANs Port configuration for second WAN-Router

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.

Figure 16: Customized VRFs with transport and overlay VLANs Customized VRFs with transport and overlay VLANs

An individual custom VRF would look like the example shown below.

Figure 17: VRF1 with added transport VLANs VRF1 with added transport VLANs
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.

The next step is to define two routing policies.

Figure 18: Routing Policies 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.
Figure 19: Export Policy Export Policy

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

Figure 20: Import default route Import default route

The next step is to create the OSPF area and assign the six transport VLANs to it.

Figure 21: OSPF Area creation OSPF Area creation

Here is a review of one of the configured VLANs.

Figure 22: Single P2P Transport VLAN in OSPF Single P2P Transport VLAN in OSPF

Finally, enable OSPF, map the two filters, and add the area you just defined.

Figure 23: Remaining OSP configuration Remaining OSP configuration

Core2 Switch Configuration

Below is a description of what you also need to configure on the core2 switch:

On core2, only the local IP addresses used for the peering subnets differ from those configured on core1, which were defined earlier.

Figure 24: Core2 Router has different additional IP-Addresses for OSPF Peering Core2 Router has different additional IP-Addresses for OSPF Peering

Juniper MX as WAN Router

Note:

An OSPF example using an SRX Series Firewall is not included here. If you decide to implement this, ensure that different metrics are used so that traffic remains directed to a specific firewall unless a failure occurs. Since the traffic is stateful, it should not be distributed randomly across WAN routers that advertise identical metrics. When using BGP, this behavior can be controlled through AS-path prepending as described in the chapter Juniper SRX Series Firewall as WAN Router.

Below is the configuration of the point-to-point interfaces, the OSPF config and import and export routing policies. You may need to add default routes and interfaces to complete the configuration. We start with the first WAN router:

Here is the configuration of the second WAN router:

Here are some additional debugging commands from WAN router1:

Here are some additional debugging commands from WAN router2: