CCNP-Studies
Routing
5-VRF-Lite
2 Lab Scenario

Lab Scenario

In this lab environment, we'll explore setting up and configuring our network using Cisco routers on GNS3. In a lab environment, where anything can go wrong and everything is a learning opportunity, i'll take you through the process of creating and managing Virtual Routing and Forwarding (VRF), configuring BGP, and using EIGRP, all within our GNS3 LAB. The lab guide will walk you through the steps and considerations necessary to establish a well-segmented network, ensuring that different departments and entities can interact seamlessly while maintaining data security and integrity. Since it's a lab environment, we encourage you to explore, test, and learn from your experiences. So, let's begin our journey towards a robust and efficient network setup in the Cisco Virtual Lab Environment, where the possibilities are endless, and learning is boundless.

Topology

  • R2 will represent our Guests
  • R3 will represent the IT Department
  • R5 will represent the our Datacenter
  • R2 and R3 will have no idea they are configured in a VRF
  • SW1 will be were most of the heavy lifting is done we will configure each VRF with a Route-Distinguisher (RD) and a Route-target (RT) both will have the same values, EIGRP in named mode and BGP. We will then do mutual redistribution between all 3 of our EIGRP VRF address families and BGP
  • The SVIs will do the work, and the ports going downstream to the routers will be Access ports

We will enable EIGRP on R1-R7 on the Global routing table

VRF-Red (Datacenter)

  • VRF-RED (DC) going from SW1 to R5
  • VRF-RED (DC) will only go from R5 to R3 (We can say this is where the IT Dept is), and we only want DC traffic

VRF-Blue (Internet)

  • We want VRF-Blue (Internet) going from SW1 to R2

VRF-Purple (Management)

  • On SW1, which will have VRF-Purple (MGMT) and a loopback SVI
  • We only want this VRF to be internal as it's a Loopback interface on the switch

Details for SW1:

  • The VLANS (SVIs) are members of a VRF
    • We will create VLAN 12-13
    • VLAN 12 will belong to VRF BLUE (Internet)
    • VLAN 13 will belong to VRF RED (DC)
    • We will configure the ports that are downstream to R2 to belong to access VLAN 12
    • We will configure the ports that are downstream to R3 to belong to access VLAN 13
    • The VLANs themselves will not be associated with a VRF. They will be inside of a VRF, but the VLANs themselves are not the VRF.
  • The physical interfaces are pointing to the physical resources that we want access to
    • int e0/2 going towards R5's E0/3 will belong to VRF-RED and will be a routed port
    • int e0/3 going towards R4's E0/2 interface will belong to VRF-BLUE and will be a routed port
    • int lo0 will belong to VRF-PURPLE
  • We will Create SVIs for the VLANs. Addressing for the SVIs will be:
    • VLAN 12: 172.16.2.1/24 Going towards R2's E0/2 interface
    • VLAN 13: 172.16.3.1/24 Going towards R3's E0/2 interface
  • Loopback 0: 172.16.1.1/24
  • Now on SW1 we will configure EIGRP for each VRF using named mode (router eigrp VRF).
  • Router VRF RED on SW1 will have an adjacency with R5 e0/2 as VRF is configured on that interface and with R2's E0/2 interface as we have the SVI in the VRF and an access VLAN downstream to R2

Prefixes:

  • The prefix will be 10.1.4.0/24 for VRF-BLUE (Internet)
  • The prefix will be 10.1.5.0/24 for VRF-Red (DC)
  • The prefix will be 10.1.1.0/24 for VRF-Purple
    • Loopback 0 will be completely localized, but just imagine another network is connected to it

VRFs:

Creating VRFs

  • There are two ways to do it:

    1. ip vrf [name]
    2. vrf definition [name]

  • The newer way "vrf definition" is the recommended way as you can have IPv4 and IPv6 address-families

  • Will not work until address-family is activated. If you go to apply it to an interface without it, you will get an error.

Old way:

  • Rx(config)#ip vrf [name]

New way:

  • Rx(config)#vrf definition [name]
  • Rx(config-vrf)#rd AS:nn these are the options available in Cisco IOS [ASN:nn, IP-address:nn, or 4BASN:nn VPN Route Distinguisher]
  • Rx(config-vrf)#vrf definition [name]
  • Rx(config-vrf)#route-target ?
    • ASN:nn or IP-address:nn Target VPN Extended Community
    • both Both import and export Target-VPN community
    • export Export Target-VPN community
    • import Import Target-VPN community
  • Rx(config-vrf)#address-family ipv4 [unicast] you don't have to type unicast; it's the only option

Applying VRFs to interfaces

  • Make sure to take note of IP address currently on the interface. Very important
  • As soon as you apply the vrf forwarding [name] command, any IP address(es) on the interface will be wiped, and VRF [name] will be enabled

Configuring BGP to use Import export Values

  • What we are going to be doing is importing and exporting different VRFs within one another using the RD and RT
  1. Configure BGP on SW1 ASN 65000
  2. router-id 1.1.1
  3. We need to enable MP-BGP using address family ipv4 in the individual VRFs
  4. Within address-family vrf, redistribute connected and EIGRP 1 on VRF BLUE, PURPLE and RED
  5. So we are taking all the connected routes that are members of the VRF and the EIGRP routes that are in our EIGRP routing table and we are going to pump them into BGP. This will allow us to leverage the route target values (extended community values) in BGP to dictate what VRFs we want to import or export between one another.
  6. Step 5 will allow the PURPLE VRF to be allowed into R3
  7. Go into vrf definition blue and create an import and export value (make sure RD and RT are the same for simplicity)
  • i.e., route-target both 1:4 (Both means anytime we import and export any route)
  • If you don't enter both, it's the default anyway. It is a macro, and if you check "show run | se vrf," you won't see it
  • Export: so anytime BGP sends a route out, it will have 1:4 as a route-target
  • Import: Anytime it looks for routes to import into BGP, it will look for the route-target 1:4
  1. So this is our setup:
  • VRF BLUE with an import/export RT of 1:4 that goes to the Internet
  • VRF PURPLE with an import/export RT of 1:1, which is our MGMT
  • VRF RED with an import/export RT of 1:5 that goes to the DC
  1. Now we can use the import/export values to dictate who gets what
  2. You also have to import them in the other direction (other router) because the other direction may also need to know how to get there.
  3. Under vrf definition RED, we will add route-target import 1:1, which will import the VRF PURPLE routes into the DC routers.
  4. Under vrf definition PURPLE, we will add route-target import 1:5, which will import the VRF RED routes into our switch VRF.
  5. Now we need to redistribute BGP back into EIGRP (Mutual Distribution) for each VRF address family. Since it's another protocol into EIGRP, we need to apply a metric, i.e., 10000 10 255 1 1500.
  • When redistributing BGP, it's smart enough to know which VRFs, so you don't have to add them; just use "redistribute bgp 65000 metric."

  1. Now, if we check the routing table on R3, we see a route to 10.1.1.0 (PURPLE VRF) and DC routes from R5 through EIGRP on our Global RIB.

  2. So IT only has access to DC, no Internet, and the Guests only have the internet through R2.

  3. If you want to change a policy, run the command show run | se vrf and take a look at the route-target imports, which is the most important thing in all of this. a) Let's say if the IT department wanted the DC department to have access to the Internet, we would go into "VRF definition RED," which is the DC VRF, and do a route-target import 1:4, which are the values that represent the internet. b) On R3 since it's part of the DC VRF it also get's the routes but we do now want the IT department to have internet access so we can use a combination of a prefix-list, and distribute list on R3 to block those routes we can use the following commands on R3:

    • ip prefix-list NO_INT deny 10.1.4.0/24 # This will deny the internet routes
    • ip prefix-list NO_INT permit 0.0.0.0/0 le 32 # This will allow all other routes.
    • router eigrp 1
      • distribute-list prefix NO_INT in # This will filter the traffic based on our prefix-list from coming inbound into our Routing table. as we can see in the picture below the prefix 10.1.4.0/24 is removed from the RIB. Sorry IT Dept no Internet for now 😉.

    c) Now we get the DC routes and the 10.1.4.0 Internet route on R5 for the DC department but not on R3 (IT). But because of the design, we won't be able to get back. But this shows you the power of importing and exporting using route-targets under VRFs when combined with MP-BGP

1 Fundamentals3 Configurations