Cisco IOS-XE Vrf Route Leaking In Single Router using VASI interfaces

For a long time I missed one feature in Cisco IOS-XE routers while working with multiple Vrfs. If somehow I could have a logical/virtual point-to-point links connecting two Vrfs. The feature I am talking about exactly same as Fortigate firewalls offer - vdom-links; which connects two vdoms using a virtual p-to-p links.

It looks like Cisco has already implemented such feature which is called - VASI (VRF-Aware Software Infrastructure). With VASI-interfaces we can connect two vrfs (including global vrf); using a logical p-to-p link. One side of a VASI-link will called - vasileft (belongs to a vrf) and another side will be called vasiright (belongs to another vrf). If we assign an IP address to those left/right interfaces; we have connected the two Vrfs. After that we can easily implement route leaking between the vrfs using static routing, dynamic routing protocols (ospf, bgp) etc.

Enough theory; lets start configuring our topology which looks like below -

01 - Network Topology

Our topology is simple - we have one IOS-XE router and three Vrfs - Global, Blue and Red. For Vrf-Blue and Vrf-Red - external communication (outside of the Vrf) will always happen through Vrf-Global. IP addressing is given below - 

Vrf Name

IP Network

Global

10.1.0.0/16

Blue

10.2.0.0/16

Red

10.3.0.0/16

The router configuration looks like below -

!!! Define Vrf and enable ipv4 unicast address family
vrf definition Vrf-Blue
 rd 65535:1
 !
 address-family ipv4
 exit-address-family
!         
vrf definition Vrf-Red
 rd 65535:2
 !
 address-family ipv4
 exit-address-family
!

!!! Vrf-Global interfaces
interface Loopback1
 description Global-Loop-1
 ip address 10.1.1.1 255.255.255.255
!
interface GigabitEthernet1
 description Global-Pc-Net
 ip address 10.1.2.1 255.255.255.0
!
!!! Vrf-Blue interfaces
interface Loopback2
 description Vrf-Blue-Loop-2
 vrf forwarding Vrf-Blue
 ip address 10.2.1.1 255.255.255.255
!
interface GigabitEthernet2
 description Vrf-Blue-Pc-Net
 vrf forwarding Vrf-Blue
 ip address 10.2.2.1 255.255.255.0
!
!!! Vrf-Red interfaces
interface Loopback3
 description Vrf-Red-Loop-3
 vrf forwarding Vrf-Red
 ip address 10.3.1.1 255.255.255.255
!
interface GigabitEthernet3
 description Vrf-Red-Pc-Net
 vrf forwarding Vrf-Red
 ip address 10.3.2.1 255.255.255.0
!

Now we will create p-to-p vasi interfaces between Vrf-Global, Vrf-Blue and Vrf-Red. Our routing policy is that Vrf-Blue and Vrf-Red will always use Vrf-Global as transit Vrfs; no direct connection between Blue and Red vrfs will be enabled/created. The vasi-topology looks like below - 


02 - VASI Topology

Our vasi IP addressing looks like below -

Vrf Name

IP Address

Vasi Pair

Vasi Interface

Global

10.4.1.1/30

vasipair1

vasileft1

Blue

10.4.1.2/30

vasipair1

vasiright1

Global

10.4.1.5/30

vasipair2

vasileft2

Red

10.4.1.6/30

vasipair2
vasiright2
 
The configuration of vasi-pairs look like below - 

!!! vasipair1 between Global and Blue Vrf.
interface vasileft1
 description VASI-From-Global-To-Vrf-Blue
 ip address 10.4.1.1 255.255.255.252
!
interface vasiright1
 description VASI-From-Vrf-Blue-To-Global
 vrf forwarding Vrf-Blue
 ip address 10.4.1.2 255.255.255.252
!
!!! vasipair1 between Global and Red Vrf.
interface vasileft2
 description VASI-From-Global-To-Vrf-Red
 ip address 10.4.1.5 255.255.255.252
!
interface vasiright2
 description VASI-From-Vrf-Red-To-Global
 vrf forwarding Vrf-Red
 ip address 10.4.1.6 255.255.255.252
!

We will do some verification now -

!!! Verify the vasi-pairs; both side of the pair (left and right) should be up.
# show vasi pair status   

Pair name     Left state             Right state            Pair state
-------------------------------------------------------------------------
VASIPair1     up                       up                        up
VASIPair2     up                       up                        up

!!! Interface vr1 is a member of Vrf-Blue
# show vrf Vrf-Blue                
  Name                             Default RD            Protocols   Interfaces
  Vrf-Blue                         65535:1               ipv4          Lo2
                                                                                 Gi2
                                                                                 vr1
!!! Interface vasiright2 is a member of Vrf-Red and IP address is 10.4.1.6.
# show vrf ipv4 interfaces Vrf-Red 
Interface                  VRF                 Protocol   Address                   
Loopback3                Vrf-Red             up         10.3.1.1                  
GigabitEthernet3       Vrf-Red             up         10.3.2.1                  
vasiright2                 Vrf-Red             up         10.4.1.6      

!!! Basic ping test between vasipair1
# ping vrf Vrf-Blue 10.4.1.1 source 10.4.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.4.1.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

!!! Basic ping test between vasipair2
# ping vrf Vrf-Red 10.4.1.5 source 10.4.1.6 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.1.5, timeout is 2 seconds:
Packet sent with a source address of 10.4.1.6 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

At this stage we have successfully enabled communication between our vrfs using the vasi-links. We will enable routing between our three networks 10.1.0.0/16, 10.2.0.0/16 and 10.3.0.0/16 using ospf and ibgp. Ospf will be used to establish the reachability of loopback interfaces. Then ibgp sessions will be established over the loopback interfaces. The Vrf-Global will announce a default-route to both Red and Blue vrfs (using ibgp). And Vrf-Blue will announce 10.2.0.0/16 to Vrf-Global (using ibgp). Also Vrf-Red will announce 10.3.0.0/16 to Vrf-Global (using ibgp).

!!! ospf 1 for Vrf-Global
router ospf 1
 router-id 10.1.1.1
 log-adjacency-changes
!
!!! ospf 2 for Vrf-Blue
router ospf 2 vrf Vrf-Blue
 router-id 10.2.1.1
 capability vrf-lite
 log-adjacency-changes
!
!!! ospf 3 for Vrf-Red
router ospf 3 vrf Vrf-Red
 router-id 10.3.1.1
 capability vrf-lite
 log-adjacency-changes
!

!!! Vrf-Global interfaces in ospf 1.
interface Loopback1
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface vasileft1
 ip ospf 1 area 0
!
interface vasileft2
 ip ospf 1 area 0
!
!!! Vrf-Blue interfaces in ospf 2.
interface Loopback2
 ip ospf network point-to-point
 ip ospf 2 area 0
!
interface vasiright1
 ip ospf 2 area 0
!
!!! Vrf-Red interfaces in ospf 3.
interface Loopback3
 ip ospf network point-to-point
 ip ospf 3 area 0
!
interface vasiright2
 ip ospf 3 area 0
!

Let's verify our ospf configuration.

# show ip ospf 2 neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
!!! ospf neighborship established with Vrf-Global neighbor 10.4.1.1 (vasileft1).
10.1.1.1          0   FULL/  -        00:00:34    10.4.1.1        vasiright1

# show ip ospf 3 neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
!!! ospf neighborship established with Vrf-Global neighbor 10.4.1.5 (vasileft2).
10.1.1.1          0   FULL/  -        00:00:39    10.4.1.5        vasiright2

# show ip route vrf Vrf-Blue ospf
      10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks
!!! Vrf-Global loopback1 reachability in routing table. 
O        10.1.1.1/32 [110/2] via 10.4.1.1, 03:57:09, vasiright1
O        10.3.1.1/32 [110/3] via 10.4.1.1, 03:57:09, vasiright1
O        10.4.1.4/30 [110/2] via 10.4.1.1, 03:57:09, vasiright1

# show ip route vrf Vrf-Red ospf 
      10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks
!!! Vrf-Global loopback1 reachability in routing table.
O        10.1.1.1/32 [110/2] via 10.4.1.5, 03:57:17, vasiright2
O        10.2.1.1/32 [110/3] via 10.4.1.5, 03:57:11, vasiright2
O        10.4.1.0/30 [110/2] via 10.4.1.5, 03:57:17, vasiright2

From above we can see all the vrfs now know how to reach each others loopback interfaces. Let's enable ibgp between the vrfs so that route leaking though Vrf-Global will enable reachability between our client networks - 1.1.2.0/24, 1.2.2.0/24 and 1.3.2.0/24.

!!! Dummy default route in Vrf-Global for announcing that to Blue and Red Vrfs.
ip route 0.0.0.0 0.0.0.0 Null0
!
!!! Dummy 10.2.0.0/16 route in Vrf-Blue for announcing that to Global Vrf.
ip route vrf Vrf-Blue 10.2.0.0 255.255.0.0 Null0
!
!!! Dummy 10.3.0.0/16 route in Vrf-Blue for announcing that to Global Vrf.
ip route vrf Vrf-Red 10.3.0.0 255.255.0.0 Null0
!

router bgp 65535
 bgp router-id 10.1.1.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 !!! Vrf-Blue ibgp neighbor.
 neighbor 10.2.1.1 remote-as 65535
 neighbor 10.2.1.1 description Vrf-Blue-Neighbor
 neighbor 10.2.1.1 update-source Loopback1
 !!! Vrf-Red ibgp neighbor.
 neighbor 10.3.1.1 remote-as 65535
 neighbor 10.3.1.1 description Vrf-Red-Neighbor
 neighbor 10.3.1.1 update-source Loopback1
 !
 address-family ipv4
  !!! Announcing 0.0.0.0/0 (default-route) over ibgp.
  network 0.0.0.0
  neighbor 10.2.1.1 activate
  neighbor 10.3.1.1 activate
 exit-address-family
 !
 address-family ipv4 vrf Vrf-Blue
  bgp router-id 10.2.1.1
  !!! Announcing 10.2.0.0/16 over ibgp.
  network 10.2.0.0 mask 255.255.0.0
  !!! Vrf-Global ibgp neighbor.
  neighbor 10.1.1.1 remote-as 65535
  neighbor 10.1.1.1 description Vrf-Global-Neighbor
  neighbor 10.1.1.1 update-source Loopback2
  neighbor 10.1.1.1 activate
 exit-address-family
 !
 address-family ipv4 vrf Vrf-Red
  bgp router-id 10.3.1.1
  !!! Announcing 10.3.0.0/16 over ibgp.
  network 10.3.0.0 mask 255.255.0.0
  !!! Vrf-Global ibgp neighbor.
  neighbor 10.1.1.1 remote-as 65535
  neighbor 10.1.1.1 description Vrf-Global-Neighbor
  neighbor 10.1.1.1 update-source Loopback3
  neighbor 10.1.1.1 activate
 exit-address-family
!

We can verify our ibgp routing in below - 

# show bgp ipv4 unicast summary

Neighbor V AS      MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
!!! Vrf-Blue ibgp neighbor
10.2.1.1  4 65535 1110      1107        4         0     0      16:43:03        1
!!! Vrf-Red ibgp neighbor
10.3.1.1  4 65535 1106      1108        4         0     0      16:43:03        1

# show ip route bgp

      10.0.0.0/8 is variably subnetted, 11 subnets, 4 masks
!!! 10.2.0.0/16 and 10.3.0.0/16 received from Vrf-Blue and Vrf-Red 
B        10.2.0.0/16 [200/0] via 10.2.1.1, 16:46:31
B        10.3.0.0/16 [200/0] via 10.3.1.1, 16:46:31

# show ip route vrf Vrf-Blue bgp 

!!! Default route received from Vrf-Global
B*    0.0.0.0/0 [200/0] via 10.1.1.1, 16:46:41

# show ip route vrf Vrf-Red bgp 

!!! Default route received from Vrf-Global
B*    0.0.0.0/0 [200/0] via 10.1.1.1, 16:46:46

The only thing left is to do some ping testing between the actual clients.

!!! Ping from Vrf-Global client to Vrf-Blue client successful.
pc-global:~# ping 10.2.2.101 -I 10.1.2.101
PING 10.2.2.101 (10.2.2.101) from 10.1.2.101: 56 data bytes
64 bytes from 10.2.2.101: seq=1 ttl=62 time=1.112 ms
64 bytes from 10.2.2.101: seq=2 ttl=62 time=0.766 ms

!!! Ping from Vrf-Global client to Vrf-Red client successful.
pc-global:~# ping 10.3.2.101 -I 10.1.2.101
PING 10.3.2.101 (10.3.2.101) from 10.1.2.101: 56 data bytes
64 bytes from 10.3.2.101: seq=1 ttl=62 time=1.420 ms
64 bytes from 10.3.2.101: seq=2 ttl=62 time=1.355 ms

With that we can wrap up our blog for today.




Location: Täby, Sweden

Comments

Post a Comment

Popular posts from this blog

Fortigate firewall AAA Configuration for management with TACACS+ protocol and Cisco ISE

Image
In this blog I will write about how to implement AAA services in Fortigate firewalls using Cisco ISE as an authentication server with TACACS+ protocol. First good to know our limitations. AAA means - Authentication (supported by ISE TACACS+), Authorization (partially supported by ISE TACACS+; Fortigate implements Admin-Profiles; so what a user can/cannot do is defined locally in the firewall with "Admin Profiles"; ISE just instructs the firewall to allocate one of those profiles), Accounting (not supported; instead configure syslog to get accounting data, Fortigate firewalls generate syslog messages for configuration changes made by a user). Let's jump to our configuration. Our topology is very simple; one Fortigate firewall and Cisco ISE server connected with the same management network which looks like below -  01 - Network Topology We have a management network 192.168.199.0/24. The firewall is at  .230  and Cisco ISE is at  .49  IP address. We are running...
Read more

Stacking switches Part - VI (Dell OS10 VLT - Virtual Link Trunking)

Image
In this blog I will configure MLAG (multi chassis link aggregation) for Dell OS10 switches. As every other vendor choses a fancy name of their implementation of MLAG; Dell is no exception to this. Dell calls their implementation VLT - Virtual Link Trunking . Let's look at our network topology - Two Dell OS10 switches will run peering between them and will run VLT/MLAG between them. Two Debian 10 linux machine will be connected with LACP bonding with both switches. They will simulate the client connection. Our topology looks like below - 01 - Dell OS10 VLT Topology Let's look at some terminology before configuration - VLT peer – The two switches participating in VLT are peer to each other. In a VLT domain a maximum of two switches are allowed. VLT interconnect (VLTi) – VLTi synchronizes state information between VLT peers. It synchronizes layer 2 and layer 3 control-plane information. These state/control-plane information includes MAC table, ARP table, IPv6 neighbors etc. VLT ...
Read more

Arista EOS AAA configuration for management with Radius protocol and Cisco ISE

Image
Today I will write about AAA configuration (SSH authentication, authorization and accounting) for Arista EOS switches with Cisco ISE as authentication server and AAA protocol will be Radius . Our topology is very simple. One Arista switch and One Cisco ISE server is running on the same network. We are not focusing on network segmentation or security. We are focusing on configuration of AAA with radius protocol from switch management perspective (ssh/telnet). Our topology looks like below - 01 - Network Topology We have a management network 192.168.199.0/24. The switch is at .134 and Cisco ISE is at .49 IP address. We are running the latest version of ISE - version 3.0. Let's define our AAA requirements - Arista switches comes with two pre defined user roles - "network-admin" and "network-operator" . We will use those two roles. One user after successful authentication from radius server (ISE), will be authorized as "network-admin" and will get read-...
Read more