Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configure Campus Fabric IP Clos

Juniper Networks campus fabrics provide a single, standards-based EVPN-VXLAN solution that you can deploy on any campus.

The campus fabric IP Clos architecture pushes VXLAN L2 gateway functionality to the access layer. This model is also called end-to-end, given that VXLAN tunnels terminate at the access layer.

The campus fabric IP Clos architecture supports Group Based Policies (GBPs) that enable you to achieve micro segmentation in the network. The GBP option gives you a practical way to create network access policies that are independent of the underlying network topology. In a GBP, you match a user group tag to a resource group tag to provide the specified users access to the specified resources. See Create a Switch Configuration Template to learn how to configure GBP on switches.

In a campus fabric IP Clos architecture, Mist provisions layer 3 (L3) integrated routing and bridging (IRB) interfaces on the access layer. All the access switches are configured with the same IP address for each L3 subnet. The end users terminating on the access layer have the default gateway set to the IRB address shared by all access layer devices. This deployment model utilizes anycast addressing for all devices participating in the L3 subnet. This deployment model provides a smaller blast radius for broadcast traffic and is ideal for east-west traffic patterns and IP Multicast environments.

For more detailed information about IP Clos architecture and its deployment, see Campus Fabric IP Clos Using Mist Wired Assurance—Juniper Validated Design (JVD).

To configure campus fabric IP Clos:

  1. Click Organization > Campus Fabric.
  2. If you want to create the campus fabric for a site, select the site from the drop-down list beside the page heading. If you want to create the campus fabric for the entire organization, select Entire Org from the drop-down list.
    You can use an organization-level campus fabric topology to build a campus-wide architecture with multiple buildings. Otherwise, build a site-specific campus fabric with a single set of core, distribution, and access switches.
  3. Click whichever option is relevant. Click the:
    • Configure Campus Fabric button (displayed if the site doesn't have a campus fabric configuration associated with it).

    • Create Campus Fabric button (displayed if the site already has at least one campus fabric configuration associated with it).

    The Topology tab is displayed.
  4. Select the topology type Campus Fabric IP Clos.
  5. Configure the topology name and other settings on the Topology tab, as described below:
    Note:

    We recommend that you use the default settings on this screen unless they conflict with any networks attached to the campus fabric. The point-to-point links between each layer utilize /31 addressing to conserve addresses.

    1. In the CONFIGURATION section, enter the following:
      • Topology Name—Enter a name for the topology.

    2. (If you don't want to use the default settings) In the TOPOLOGY SETTINGS section, enter the following:
      • BGP Local AS—Represents the starting point of private BGP AS numbers that are automatically allocated to each device. You can use any private BGP AS number range that suits your deployment. Mist provisions the routing policy so that only the loopback IP addresses are exchanged in the underlay of the fabric.

      • Underlay—Select an internet protocol for the underlay. Options are IPv4 and IPv6.

      • Subnet— The range of IP addresses that Mist uses for point-to-point links between devices. You can use a range that suits your deployment. Mist breaks this subnet into /31 subnet addressing per link. You can modify this number to suit the specific deployment scale. For example, a /24 network would provide up to 128 point-to-point /31 subnets.

      • IPv6 Loopback Interface—Specify an IPv6 loopback interface subnet, which is used to autoconfigure IPv6 loopback interface on each device in the fabric.

      • IPv4 Auto Router ID Subnet / Loopback Interface—Mist uses this subnet to automatically assign a router ID to each device in the fabric (including access devices irrespective of whether they are configured with EVPN or not). Router IDs are loopback interfaces (lo0.0) used for overlay peering between devices. For new topologies, this field auto-populates a default subnet value (172.16.254.0/23), which you can modify. When you edit an existing topology, this field doesn’t populate a default value. The router ID is used as an identifier when deploying routing protocols such as BGP.

        You can overwrite the automatically assigned router ID by manually configuring a loopback interface in the Router ID field on the Routing tile on the switch configuration page (Switches > Switch Name). However, if you modify the campus fabric configuration afterwards, Mist performs the automatic assignment of the router ID again, replacing the manually configured loopback interface.

      • Loopback per-VRF subnet—Mist uses this subnet to automatically configure loopback interfaces (lo0.x) per virtual routing and forwarding (VRF) instance that is used for services such as DHCP relay. For new topologies, this field auto-populates a default subnet value (172.16.192.0/24), which you can modify. This field supports a /19 or smaller subnet (for example, /24). When you edit an existing topology, this field doesn’t populate a default value.

  6. Click Continue to go to the Nodes tab, where you can select devices that form part of the campus fabric IP Clos deployment.
  7. Add switches to the Core, Distribution, and Access layer sections.

    To add the switches:

    1. Click Select Switches in the section to which you want to add switches.

    2. Select the switches that you want to add to the campus fabric.

    3. Click Select.

    We recommend that you validate the presence of each device in the switch inventory before creating the campus fabric.

    By default, Mist configures the core switches to function as border nodes that run the service block functionality. In a campus fabric topology, border nodes interconnect external devices such as firewalls, routers, or critical devices. External services or devices (for example, DHCP and RADIUS servers) connect to the campus fabric through border nodes. If you want to offload this task from the core switches and use dedicated switches as border nodes, clear the Use Core as border checkbox on the upper left of the page. You can then add up to two switches as dedicated border nodes. The minimum number of dedicated border nodes required is one.

    Also, Mist provides pods for improved scalability. Your access and distribution devices are grouped into pods. A pod could represent a building. For example, you can create a pod for each of the buildings in your site and create connections between the access and the distribution devices in that pod. You do not have to connect the same set of access devices to the distribution devices across multiple buildings. You can create multiple pods by clicking +Add Nodes.

    You need only one connection between a pod and the core switch. You do not have to connect each distribution switch in a pod to all the core switches used. In an IPClos topology, you need only one connection between each core and distribution pair and between each distribution and access pair.

  8. After selecting the switches, click Continue to go to the Network Settings tab, where you can configure the networks.
  9. Configure the network settings, as described below.
    1. From the NETWORKS tile, add networks or VLANs to the configuration. You can either create a new network or import the network from the switch template defined in the Organization > Switch templates page.

      To add a new VLAN, click Create New Network and configure the VLANs. The settings include a name, VLAN ID, and a subnet. You can specify IPv4 or IPv6 addresses for the subnet.

      To import VLANs from the template:

      1. Click Add Existing Network.

      2. Select a switch template from the Template drop-down list to view the VLANs available in that template.

      3. Select the required VLAN from the displayed list, and click the ✓ mark.

      VLANs are mapped to Virtual Network Identifiers (VNIs). You can optionally map the VLANs to VRF instances to logically separate the traffic.

    2. Review the settings on the OTHER IP CONFIGURATION tile. This tile populates the settings automatically after you specify the networks in the NETWORKS section.

      Mist provides automatic IP addressing of IRB for each of the VLANs. Then, the port profile associates the VLAN with the specified ports.

    3. Optionally, configure VRF instances in the VRF tile. By default, Mist places all VLANs in the default VRF. The VRF option allows you to group common VLANs into the same VRF or separate VRFs depending on traffic isolation requirements. All VLANs within each VRF have full connectivity with each other and with other external networking resources. A common use case is the isolation of guest wireless traffic from most enterprise domains except Internet connectivity. By default, a campus fabric provides complete isolation between VRFs, forcing inter-VRF communications to traverse a firewall. If you require inter-VRF communication, you need to include extra routes to the VRF. The extra route could be a default route that instructs the campus fabric to use an external router. It could also be a firewall for further security inspection or routing capabilities.

      To create a VRF:

      1. Click Add VRF Instance and specify the settings. The settings include a name for the VRF and the networks to be associated with the VRF.

      2. To add extra routes, click the Add Extra Routes link on the New VRF Instance page and specify the route. You can specify IPv4 or IPv6 addresses.

    4. On the DHCP RELAY tile, configure the DHCP relay settings. You have the following options:
      • Enabled—Configures DHCP relay on all the IRB-enabled devices in campus fabric. This option allows you to enable DHCP Relay on networks that you selected. The network will be populated inside the DHCP Relay tile as long as it is listed on the Networks tab on the same page.

      • Disabled—Disable DHCP relay on the devices in campus fabric. When you select this option, the DHCP relay is disabled on all the IRB-enabled devices. You should carefully select this option as this will remove the locally defined DHCP Relay on the Switch Detail page.

      • None—This option is automatically selected when the campus fabric topology has a mix of devices in terms of the DHCP relay configuration; that is, some devices have the DHCP relay enabled, some have it disabled, and some do not have it defined.

      If you want to remove all locally defined DHCP Relay networks, select Enabled and then choose Remove all existing device level DHCP Networks. You can simplify your DHCP Relay deployment by centralizing any configuration change from the campus fabric workflow.

      If you enable DHCP relay in a campus fabric configuration, it is enabled on all the IRB-defined devices in the fabric and disabled on the rest of the devices. For example, in Campus Fabric IP Clos edge topologies, DHCP is enabled on access devices and disabled on the rest.

  10. Click Continue to go to the Ports tab, where you can configure the ports and create a connection between the core, distribution, and access layer switches.
  11. Configure the switch ports in the core layer as described below:
    1. Select a switch in the Core section to open the switch port panel.
    2. From the port panel of the core switch, select a port that you want to configure.
    3. Specify a port type (for example, ge or xe).
    4. Choose the distribution switch on which the link should terminate. You need to configure all the ports that need to be part of the campus fabric.

    To configure switch ports in the distribution layer:

    1. Select a switch in the Distribution section to open the switch port panel.
    2. From the port panel of the switch, select a port that you want to configure.
    3. Specify a port type (example: ge or xe).
    4. Select:
      • Link to Core to connect the port to a core switch.

      • Link to Access to connect the port to an access switch.

    5. Select the core or access switch (based on the selection in the previous step) on which the link should terminate. You need to configure all the ports that need to be part of the campus fabric.

    To configure switch ports in the access layer:

    1. Select a switch in the Access section to open the switch port panel.
    2. From the port panel of the switch, select a port that you want to configure.
    3. Specify a port type (example: ge and xe).
    4. Choose the distribution switch on which the link should terminate. You need to configure all the ports that need to be part of the campus fabric.

    If you want to view the configuration and status information of a specific port, hover over the numbered box representing that port in the port panel UI.

  12. Click Continue to go to the Confirmation tab.
  13. Click each switch icon to view and verify the configuration.
  14. After verifying the configuration, click Apply Changes > Confirm.
    The campus fabric configuration is saved to the Mist cloud. The configuration is immediately applied to the switches if they are online. If the switches are offline, the configuration will be applied to them when they come online next time. A switch might take up to 10 minutes to complete the configuration.
  15. Click Close Campus Fabric Configuration.

    Once the campus fabric is built or is in the process of being built, you can download the connection table, which represents the physical layout of the campus fabric. You can use this table to validate all switch interconnects for the devices participating in the physical campus fabric build. Click Connection Table to download it (.csv format).

  16. Verify the campus fabric configuration. To verify, follow the steps listed in the Verification section of Campus Fabric IP Clos Wired Assurance.

For a demo of the configuration steps, watch the following video:

Hello and welcome to this edition of Wired Assurance. My name is Rohan Chadha and I'm a part of the product management team at MIST. Today we're going to talk about deployment of Campus Fabric IP Clos with Wired Assurance.

IP Clos is one of the three topologies supported by Juniper for campus environments. There are different benefits of using IP Clos, it depends on your network environment needs and today we're going to talk about how to deploy it in four steps. I assure you that none of these four steps will involve any CLI configuration and we'll do everything through the UI to quickly build this Campus Fabric in just four steps.

So let's jump right into it and see how to deploy Campus Fabric IP Clos. So before I talk about the building blocks of Campus Fabric IP Clos, I want to give you a heads up that if you are here and you do not know what IP Clos topology is, I recommend you go watch the other video by Rick Bartosik in which he clearly explains the building blocks of IP Clos. Is IP Clos a suitable topology for your environment or should you go with something different like an EVP multi-homing or a Campus Fabric co-distribution? One of the benefits of IP Clos is that you can extend EVPN VXLAN configuration to the edge and what that means is that if you have devices that need EVPN VXLAN or if they're supported, then you can tunnel your devices directly to the access layer.

One other benefit and a great one is GBP. You can use segmentation using tags on the access layer. In this video, we're not going to talk about GBP.

This is purely about the deployment of IP Clos using Wired Assurance. So let's jump right into it and look at the devices we're going to use today for IP Clos. So I'm going to use two QFX 10000 IIs as my core devices and I'm also going to use two QFX 5120 48Y as distribution devices and just for the purposes of this video, I'll be using one access device which is a virtual chassis and virtual chassis is supported by the way for a few platforms like EX4400 in EVPN VXLAN and so we're going to use that virtual chassis as an access switch.

Let's jump right into it. Let's click on organization and under the wire tab, I see campus fabric. So I'll go ahead and click on that.

As I see that in this particular topology, I do not have a campus fabric that's configured for the site. There are two kinds of EVPN configurations that you can build, two kinds of campus fabrics basically, one is a site-based, the other one is an organization-based topology. A site-based topology is where you use a handful of devices, but all of the devices are in a certain site.

In an org-based topology that you can come in and build here, you build topologies on an organization level. So you have one big topology that have different pods from multiple sites. Each pod represents a site and there are core devices that are common to the entire organization and they can be from any site.

But for the purposes of this video to keep things simple, my plan today is to just talk about IP flow on a site-based level. So I'll go back and I'll help you configure a campus fabric IP flow topology. So let's configure campus fabric as usual and as you've seen before, a campus fabric IP flow is option number three that's presented.

At the time of making this video, this topology is still in beta phase. So let's give IP flow topology or configuration name here. So I'll just call it EVPN-IPflow, any name is fine.

There are two options that I have. Do I want to route at distribution or do I want to route at edge? Before I actually get into the details of routing, let's talk about how an IP flow topology looks like or how it could possibly look like for different customers. If you can see my cursor being hovered over this particular little diagram on the left side next to campus fabric IP flow, you'll see that there are three layers and a full mesh.

What that represents is every core device is connected to every distribution device and every distribution device is connected to every access device. And we are traditionally, the L3 is at the edge and edge basically means the access device. However, there is also an option that you can route at distribution.

And what that means is that your gateways, your IRB slash SVI interfaces will reside on the distribution. By default, if you do not make any changes, your IRB slash SVI interfaces will be on your access devices. There are different benefits as I mentioned earlier of using IP flow.

It's primarily used for east-west traffic. But as I said, if you want the details of what IP flow really is, go and watch Rick's video and he explains that in great detail and why you should use it. So once you've selected the topology name and you've made sure that you want to route at the edge, there are a few default settings like overlay and underlay.

These values that you see here are default and you do not have to change it if there isn't a need. At the time of making this video, we are doing a few things. IBGP for overlay and EBGP for underlay.

So 65,000 will be your AS for all the devices that are part of the fabric for overlay and then 65,001 and an incremental sequence. We'll have devices that will be given the AS number going forward. As a user, you do not have to configure any of these changes in the CLI.

The campus fabric feature will take care of everything. The next step is to ensure that this is the loopback prefix that you want. This is slash 24.

This is basically the prefix that we assign to the loopback interfaces for all the devices participating in IP flow. This loopback interface is used to peer with every other device in the overlay. Essentially, every device that is a VTEP for EVPNVX LAN has to peer with the other device for the control plane.

And the next step that you see is the subnet that's required for the underlay IP addressing. This is basically if I have two core devices, two distribution and three IP flow. As a user, you do not have to do any manual IP addressing.

And that's the best part about this feature. Campus fabric will take care of all of the IP addressing. Just provide us a subnet and we'll take care of that.

So let's click continue and move on to the next step. This next step includes selecting campus fabric nodes. As you can see, the step one is selecting a service block border.

So what exactly is a service block? Well, if you are someone who wants to keep your spines, your core devices lean spines, meaning you do not want your core devices to connect to the router, the firewall, or you do not want to use any services connected to the core, such as DHCP, DNS, etc. You can have a separate service block. And in that service block, you can have one to two border switches and you can make all of that connectivity in the service block.

However, this is not a requirement. This is an added feature wherein if you want to have a service block, you can do that. For the purposes of this video and to make things simple, I will be using the core as the border device, meaning that any services or any sort of WAN or firewall connectivity will be on the core device.

So as you see, I get this validation error that says that at least one distribution switch is required. So what this means is that having the core layer is not mandatory. And what that means is that you can have a smaller IP cloud design.

If you're someone who is interested in IP cloud because you want GBP or you want your access points or your other devices are VXLAN capable and you want to form a tunnel, but you want to keep the topology small, you can skip the core layer and have just distribution and access layer. But if all of those requirements are there, but you still would want to have a bigger topology, have a core layer, click on the core devices and select a few switches. So I'm going to select core one and core two.

As I mentioned earlier, for the core layer, for distribution, I'm going to be selecting distribution one and distribution two. As you can see, with just a click of a button, I have this nice little pop-up that gives me the inventory of the site and also tells me which devices are suitable for every layer. The last step is to select the access switches.

I'm just going to be using just one access switch for the purposes of this video. Once you've ensured that you've selected these devices, you can always, before going on to the next step, you have to ensure that you select the router ID and you've selected the access switches. And ensure that they are connected.

And one thing that I'd like to mention here is before we proceed is you can always come back and expand your topology horizontally. And what that means is that as your network needs grow, you can always come in and add access switches and you can add distribution switches to expand your topology. So let's hit continue and go to the next step.

At this step, you will be configuring networks. Networks are basically your VLANs slash bridge domains. You can either create a new network or you can add an existing network.

I'll go ahead and create a new network. And in this case, I will be calling the network EVPNVLAN10. This is just a name.

Do a VLAN ID and I'll go ahead and create a subnet along with a virtual gateway. You can always come and add an existing network as well. And what that means is that if you have networks that you configured on a site level, under site switch configuration, if you configure a VLAN slash network there, it will be propagated to all the devices on a certain site.

So if this particular site has other VLANs, you can always come in and inherit those. You do not have to manually configure a VLAN again. And that's the best part about this.

So I'll go ahead and I'll select these two VLANs. What you can also do is you can import a few VLANs from a certain template. If you have a few templates that you built in the past, however, those templates are either not being used or even if they are being used, you can always inherit a few VLANs from those particular templates.

So I'll go ahead and select this. There is only one VLAN that's part of this particular template. I'll go ahead and select that as well.

And so I'm being told that VLAN 130 doesn't have a subnet. So I'll go ahead and assign a subnet. So at the time of making this video, we are doing a centrally routed and bridged topology.

And what that means is that even though I'm routing at the access, we're still using a virtual gateway. There is also another way that I'm not going to talk about this video, but it is there, which is you can do any cast. What that means is that if you have multiple access switches, every VLAN will have the same IP address on all the devices.

We can talk about that in another video, but to keep things simple, I'll just do what's being shown here and every VLAN will have a virtual gateway. This particular virtual gateway will reside on all the access switches. However, since we have only one access switch in this case, that will be the case.

So the second step is to use VRF configuration, which is basically you can segregate your networks using VRFs. What that means is that if you're someone who wants more security between bridge domains, you want to keep the routing tables separate. You can use virtual routing and forwarding.

You very simply use click on add a VRF instance, give it a name and just assign a VLAN. To keep the configuration simple, I will use only one VLAN for a VRF and I'll keep the rest in the default routing instance. However, there is no limit to how many VLANs you can add to a routing instance.

Let's click continue and let's go to the last step. The last and final step is the selection of ports, wherein you'll be telling us how these devices are connected to each other and how we should be doing the mapping in the backend. So while I go ahead and do the connection for all these devices, sit tight and I'll be fast forwarding this video and get back to you soon.

So I've selected all these ports and I have told Campus Fabric how to connect quota distribution and then distribution to access. As you can see, this is a virtual chassis and it's very well supported. So now that we've selected it and all the requirements are complete and we see some green lights here, let's go ahead and hit continue and just confirm that everything that you wanted to do is straightforward.

So if I click on any device, I'll see the VLANs and the corresponding names. I do not see any IP addresses here, of course, because the IP addresses exist at the access layer. So I can see that VLAN 10 has this particular IP assigned to it and similarly other VLANs as well.

I can always verify my connections, the distribution as well at this layer. So what I also see is I see a little blob here that says remote shell. Before hitting continue and applying changes, you can always click on the remote shell and you can always, rather than logging out of band or logging in out of band or having an SSH connection, we provide you this option where you can verify anything that you'd like.

You want to verify that your connections are the way they look or if you're running a brownfield environment, what that means is if you have an existing Campus Fabric, before you hit apply changes and you want to ensure that none of your configurations are overwritten, if you're moving from an existing manually CLI-configured Campus Fabric to a MIST-configured Campus Fabric, this is the place for you. Hit remote shell, ensure that this is everything that you wanted and then go and hit apply changes. So I'll hit apply changes.

I'm being asked if everything is okay and I'll hit confirm. So at this point, my EVPN IP cloud topology is complete. All the configurations will be pushed at this point.

All of my devices that were a part of the EVPN configuration that I used in the Campus Fabric are being managed as I can see. And what that basically means is that as soon as I hit confirm on Campus Fabric, all of the configuration will be pushed right away. It will be configured.

It probably takes a few seconds for Junos to commit and then a few seconds to a few minutes for BGP, underlay and overlay to come up and form tunnels between all of these devices from core to distribution and then to access. So you may ask, how do I know what configuration has been pushed? I want to ensure that everything that I wanted on the device is there and we have an answer for you. So you can always come in here, click on utilities, and look at download Junos config.

It basically downloads a file locally on your system and on this file, you can, you can see everything that has been pushed by Campus Fabric. As you can see, I have the BGP configuration, underlay as well as overlay. I also have the interface configuration that was wanted.

I also see the policies that are defined along with the switch options for EVPN configuration as well. Now, this is the core device, device of interest in an IP cloud is an access switch. So let's look at the access switch.

This is a virtual chassis, as I mentioned earlier. Click on utilities, download the Junos config and let's look at what's being pushed over here. So as I see, I have the underlay and overlay configuration.

I have the EVPN configuration. I also have all the gateways that I wanted. As we see the routing instances, the VRF configuration has been pushed as well, along with the other VLANs that we wanted.

There are a few other VLANs as well. And those VLANs were basically, that were already a part of the device configured through the Mist UI as you can see here. So all in all, what we noticed is that as a user, everything that you were supposed to do in a day or something that would take two to four days has been done automatically by Campus Fabric.

All you had to do was provide just a few steps and given a few information about the networks, the connectivity between the devices and if you intend to use VRF or not. So now that we've defined how to build the Campus Fabric, we've also seen what the configuration looks like. We want to ensure and go back and see that how does it look from a monitoring standpoint.

So as we can see on this screen, I see the last configuration timer, everything seems updated. I know that there were no failures here between these devices. My distribution devices look good and that tells me that the configuration has been pushed and has been reported back to the cloud.

So click on organization, let's go to Campus Fabric and let's click on this topology that we just created. I have a topology ID, I have a name and then I have a date and time that it was created at. Let's click on it and see what we see here.

So I see two core devices and then the distribution devices as well. When I click on it, I see some green links. Now these green links are not just your link status.

If there is a BGP issue and what I mean by that is if there is a flap in your environment, you're going to see some EVPN insights wherein you'll be told that, you know, there is a neighbor change. Also, if you have connected the devices wrongly, as in if distribution was connected to access via G000 and if you were to say G001, you'll be told about it right away and I'll try to give an example of that very soon. Okay.

So we know that everything looks good. Let's click on switch insights and see if we see any events here. So as I can see, I see a BGP peer state change.

This tells me that, you know, BGP went from open component to established even though I know looking at the green links, I just wanted to come in here and see that is one of the ways to verify that BGP indeed came up. Okay. So now that we've built the topology, you've seen how the configuration looks like.

Let's talk about the day two of Campus Fabric. What happens when you build the topology? So I'm going to show you some Campus Fabric insights that we've built. This is not all-encompassing, but this is what we support today and with a plan to support much more.

So this is our topology that we built earlier. What I did earlier was after I showed you the topology, I went in and I selected some ports that won't correct, meaning that I connect from the link from code to distribution was XE, but I selected that as GE and similarly I selected the wrong port between the distribution axis. And what that tells us is that the Campus Fabric is very smart.

It tells us that the selected port that I configured is not the right port and it knows that through the LLDP neighbors. It can read it and it tells you that I know that the distribution 2 to core 1 port is a different port and what you've told me in your configuration when you selected the ports in step 4 is the wrong port. So please go ahead and fix it and that's exactly what it is.

I see the same thing here. I see a BGP flap because BGP was working earlier and now BGP went from established to idle. A similar scenario wherein the selected port is not the right port.

This is one of the things within EVPan insights. One of the other things that I want to show you is the difference between the thick green links and the thin green links. What that basically tells you is the traffic flow.

If there is more traffic flowing between a core and two distribution devices, you will see thicker links there versus thinner links between distribution 2 and core 2 versus distribution 2 and core 1. Similarly, we can also look at the RX and the TX bytes here. If I look at the RX bytes and distribution, I see that 75 gigs and 163 gigs versus distribution. So I see that there's more traffic being received between distribution and access.

There is more traffic that is being received on distribution 1 versus distribution 2. Well, for now, we know that the link is down but if the link was up, we know that the distribution 1 is receiving more traffic than distribution 2. So this concludes our session for EVPN IP cloud topology. Today, we reviewed how to build a topology in four steps. We also reviewed the configuration of one or two devices and I showed you how a user doesn't have to manually configure anything.

If you provide us the right topology type, if you tell us what nodes you'd like to be a part of the canvas fabric. Also, if you give us some information about the VLAN IDs and if you would like VRFs, we configure the fabric for you. As a user, you do not have to configure the policy options.

You do not have to configure the route target or the route distinguisher. So this concludes our session. Thank you so much and I hope you were able to take away some great things from this topic.

Thank you.

After building an IP Clos campus fabric, you can integrate it with a third party gateway (such as a router or firewall) by using BGP groups. Watch the following video for more information:

Juniper's campus fabric series. Today we're going to focus on how to integrate a current campus fabric IP class with a third-party gateway, whether it be a router, firewall, etc. In this case we will be leveraging an SRX345 firewall.

So the fabric class has been built, you see that here. We've got our services block up top here, we've got our core devices, we've got our distribution devices, and we can see that we've got our telemetry coming in from all different devices. So what we're going to do is we're going to go to the services block and we are going to build the configuration requisite to pull up that BGP peering relationship.

We're going to apply the policies on a per-verse basis. We actually have three routing instances here, guest Wi-Fi, developers, and core IT. So because we have three routing instances, we build three specific sub-interfaces from the services block to the firewall.

So let's jump in and show what that looks like and then we apply BGP on top of that. Now for the sake of brevity, we've gone ahead and built these configurations already. We're going to focus the video on BGP enablement, building the policies and the peering statements and validating that.

So this is what we have. We have our IP configuration. We've added three specific addresses.

Each address is associated with a VLAN, 99 for core IT, 88 for developers, and of course, 33 for guest Wi-Fi. So those are all built through this tab. I could have already built these from a pre-configuration staging perspective.

You could also build the requisite VLAN identifiers through the add IP configuration tab if you'd like, or you can have them built down here. Either one works well. And you'll see all three of these built with the requisite VLANs.

Now once that's done, then we come over to each of the routing instances. Notice we've got the override site templates because what we're going to do here is we're going to add the new WAN core IT to core IT. We're going to add WAN developers to developers.

And of course, we're going to add WAN guest Wi-Fi to guest Wi-Fi. But we only care at the services block. We're not pushing this VLAN across the network. So that's really important to understand that. Okay, so now we've done three things. We've built the IP config.

We've applied a VLAN tag to each of those configs. And then we've added those networks into each of the routing instances. And we're overriding the system template.

At the interface, it's a layer three sub-interface. And we had all three of those interfaces here. So now we've actually built a system where I should have IP connectivity between the services block and the firewall.

So let's take a look at this. That's a good thing. If I come back here, I should hit guest Wi-Fi.

We do. And then let's hit developers. Okay, cool.

And so one last thing, I want to make sure we just don't have any straggler BGP sessions here. And all we have is we've got our underlain overlay to the core, to the fabric itself. So no BGP configuration is built to the firewall.

Okay, so that's our pre-built system. Let's come down and focus on enabling BGP here. We're going to add three groups.

We're going to add a core IT, a guest Wi-Fi, and a developer group. These are all going to have relatively straightforward configurations. They're all going to be external.

They're going to use their specific VLAN that's created. They're all going to use local AS of 65001, excuse me, 7. And then each one is going to build out a policy. And that policy is going to be requisite with the particular subnets that we are passing from the core out to the BGP-enabled SRX device here, 10.9.9.0.24. Notice we've got an accept by default.

So that's our first policy. So core IT, basic information, export policy as core IT, and now we build our neighbor. Our neighbor is going to be 10.9.1.1 and 6.5.1.0.0. Now, neighbor AS could be the same across all subinterfaces because we're going to the same device.

Okay, now I've built, there it is, I've already built one neighbor. I'm going to build two more here. Okay, developers.

And we'll build guest Wi-Fi. Now, what's interesting, well, certainly very important to understand is that by default, the Campus Fabricat-PCLOS isolates traffic in the routing instances that you build. So by default, there is no leaking of routes.

There is no shenanigans such as that. Most customers like to keep the fabric at a point where it is isolating traffic natively and then passing traffic onto a firewall or a security device to allow for inter-VIRF communications. Okay, and that's what we're doing right here effectively.

So the firewall is going to be our trusted source of communication to allow these three VIRFs to communicate if needed. And we come down here and add this. Okay, boom.

So we're just about done. Let's go ahead and add the last guest Wi-Fi external. We're going to look at guest Wi-Fi here.

So this stuff should be relatively, you know, you guys are, I'm sure you're picking up on this real easy, real quick. Policies are pretty straightforward as well. And by the way, one thing I didn't mention is, and we'll see this when we look at the routing information, the firewall is sending us a default route, so, which is very common.

That would be preferred. And so you'll see the default route in each of the routing instances. And that is a really very popular recommendation configuration for most customers.

Last type of information here. Okay, so we actually have relatively straightforward information, a neighbor for each routing instance, the same AS because we're talking to the same device, export policies that are pushing the prefixes. And we are good to go.

So before I do that, let's go into the particular device itself. We saw this earlier, and we want to make sure that we're only seeing the local sub interfaces there. So here's what we're going to do.

We're going to refresh this every five seconds. I'm going to go ahead and hit save here. And the save shows us the difference in what we're pushing.

And then we'll come back here to this remote shell. Pull the remote shell over. And we'll just take a look and see the push of the configuration to the services block.

And actually it happens relatively quickly. Sometimes a remote shell asks us to re-login because the configuration push kind of pushed us out of that remote shell. So let's go back into the shell here.

And let's take a look around. In fact, what I want to do is refresh my screen here. And then we'll look at how things look within the device itself.

Okay. So let's look at show BGP summary. And voila.

We actually have our three established peers. Now, what I should expect to see would be show routes, receive, yeah, route receive protocol BGP. So let's look at each individual route instance.

I should be getting a default route. Very good. I'm getting a default route for the SRX for 10.3.3.1.1. I should get that for 10.8.8.1.1. I do. And 10.9.9.1.1. I do. Good. So now let's make sure that we are sending, we should be sending only the prefix that we designated. Perfect. That's what I want to see. Very good. And I hope that's, man, that looks pretty good. Let's go back to BGP once again. Establishment.

Okay. So what we went through in this setup is basic configuration of BGP, enabling BGP, setting up a peering from a VRF perspective, VRF to SRX, three-verse, three particular peers. Each peer is sending its own prefix and it's receiving a default route from the SRX.

We verified all that. And it looks like the configuration is relatively stable and we're happy to go. Hopefully this has been educational and you find this series valuable for you.

Have a great day.