“Penny wise, pound foolish”, you might say about the proposal to use internal GRE tunnel to forward traffic between global router (GRT) and a virtual one within the same physical device. Well, it works well to a certain extent – performance is being halved but money for interface ports well saved.

We want to achieve the following:

  • traffic between servers A and servers B will use the green direct path between AS A and AS B
  • no other traffic must follow this green path
  • servers A and servers B will communicate via dashed backup path via internet in case the green path fails
  • servers A communicate with all other clients via blue paths and internet
  • servers A can only use router A for the gateway
  • no additional physical interfaces on router A can be used


Local connectivity between servers A in B via the green link is easily achieved by putting both interfaces towards the servers on router A into a common VRF. Next step is to connect this VRF localy to the router A and use its global routing table to reach the rest of the internet.

Tunnels to the rescue! Within router A we configure an IP-link between two GRE tunnel interfaces built upon two internal loopbacks. Both loopbacks are part of the physical router, but the tunnel, which is constructed between the two loopbacks, sets one side into the global router (GRT) and another into the logical one (VRF). Here is the schema (please click for details):


Here we’ve configured two tunnel interfaces in the common subnet 100.0.0.0/30. A default route in GRT points to some upstream router C (37.0.0.2). A default for VRF points to interface Tunnel1 with next-hop 100.0.0.2 which is part of GRT:

ip vrf A
 rd 2107:2
!
interface Loopback69
 description transporting the tunnel end-point in VRF
 ip address 1.2.3.4 255.255.255.255
!
interface Loopback96
 description transporting the tunnel end-point in GRT
 ip address 4.3.2.1 255.255.255.255
!
interface Tunnel1
 description tunnel end-point in VRF
 bandwidth 10000000
 ip vrf forwarding A
 ip address 100.0.0.1 255.255.255.252
 no ip redirects
 ip mtu 9000
 tunnel source Loopback69
 tunnel destination 4.3.2.1
!
interface Tunnel2
 description tunnel end-point in GRT
 bandwidth 10000000
 ip address 100.0.0.2 255.255.255.252
 no ip redirects
 ip mtu 9000
 tunnel source Loopback96
 tunnel destination 1.2.3.4
!
interface TenGigabitEthernet1/1
 description toward internet (to router C)
 mtu 9000
 ip address 37.0.0.1 255.255.255.252
!
interface TenGigabitEthernet1/2
 description toward servers A in our AS A (65001)
 mtu 9000
 ip vrf forwarding A
 ip address 6.6.6.6 255.255.255.0
!
interface GigabitEthernet2/1
 description toward servers B in neighbor AS B (65002)
 mtu 9000
 ip vrf forwarding A
 ip address 10.0.0.1 255.255.255.252
!
! default route to internet
ip route 0.0.0.0 0.0.0.0 TenGigabitEthernet1/1 37.0.0.2
! routes for subnets in the VRF
ip route 6.6.6.0 255.255.255.0 Tunnel2 100.0.0.1
ip route 10.0.0.0 255.255.255.0 Tunnel2 100.0.0.1
! default route in the VRF
ip route vrf A 0.0.0.0 0.0.0.0 Tunnel1 100.0.0.2
!

Of course, BGP can be used to leak the routes from VRF into the GRT. Here is an example. We’ve setup an internal BGP session within AS 65001 between the GRT and VRF and an external session with neighbor autonomous system B (AS 65002):

router bgp 65001
 bgp router-id vrf auto-assign
 no bgp default ipv4-unicast
 neighbor 100.0.0.1 remote-as 65001
 neighbor 100.0.0.1 update-source Tunnel2
 !
 address-family ipv4
  neighbor 100.0.0.1 activate
  neighbor 100.0.0.1 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf A
  neighbor 10.0.0.2 remote-as 65002
  neighbor 10.0.0.2 activate
  neighbor 100.0.0.2 remote-as 65001
  neighbor 100.0.0.2 update-source Tunnel1
  neighbor 100.0.0.2 activate
  neighbor 100.0.0.2 next-hop-self
 exit-address-family
!


What about the performance? It is obvious that a packet originating from the VRF and destined to the GRT is processed twice, first encapsulated by Tunnel1, then de-encapsulated by Tunnel2. This is done by hardware (at least on Cisco Cat6500 or similar devices) and doesn’t affect the CPU, but it comes with the huge penalty. Performance is halved!
We will have a closer look into the performance issues in the following post.

Advertisements