• Arista Any Cloud Platform – Destination NAT (IP Anycast) in vEOS Router

 
 
Print Friendly, PDF & Email

Overview

Purpose of this post is to test and validate Destination NAT (IP Anycast) support on vEOS Router.  We built the following topology in AWS to validate this setup: 

 AWS-VPC-with-Arista

Here is the link to the EOS Central article that can be referenced to help build this topology – https://eos.arista.com/arista-any-cloud-platform-hybrid-cloud-veos-router-in-aws-deployment-guide/

Objectives

We hope to accomplish  the following in this article:

  • Create a Loopback interface on vRouter-1a and vRouter-1b with an IP address of 1.1.1.1/32
  • Advertise 1.1.1.1/32 as an equal cost route to vRouter-Transit.  At any given moment vRouter-Transit could take the path to vRouter-1a or vRouter-1b.  In this setup we utilized BGP without ECMP.
  • Create a Destination NAT statement on the vRouter-1a and vRouter-1b to NAT 1.1.1.1 to 10.1.11.10 and 10.1.21.10 respectively.
  • Generate a flow from Host-Transit (10.100.11.10) destined to 1.1.1.1.  This should either route to vRouter-1a or vRouter-1b depending on the route we will prefer on vRouter-Transit.
  • Upon failure of the primary link being utilized to reach 1.1.1.1 connectivity to 1.1.1.1 should fail over to the other link.

Configuration and Validation

Review and validate configurations on vRouter1a and vRouter1b:

  1. vRouter-1a Configuration:

    interface Loopback0
       ip address 1.1.1.1/32
    !
    interface Tunnel1
       ip address 10.0.0.1/31
       ip nat destination static 1.1.1.1 10.1.11.10
    !
    router bgp 65101
       router-id 10.1.1.6
       network 1.1.1.1/32
  2. vRouter-1b Configuration:

    interface Loopback0
       ip address 1.1.1.1/32
    !
    interface Tunnel2
       mtu 8973
       ip address 10.0.0.3/31
       ip nat destination static 1.1.1.1 10.1.21.10
    !
    router bgp 65101
       router-id 10.1.2.6
       network 1.1.1.1/32
  3. vRouter-Transit Route Lookup:

    vRouter-Transit#sh ip bgp 1.1.1.1
    BGP routing table information for VRF default
    Router identifier 10.100.1.6, local AS number 65100
    BGP routing table entry for 1.1.1.1/32
     Paths: 2 available
      65101
        10.0.0.1 from 10.0.0.1 (10.1.1.6)
          Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:13:14 ago, valid, external, best
          Rx SAFI: Unicast
      65101
        10.0.0.3 from 10.0.0.3 (10.1.2.6)
          Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:43:46 ago, valid, external
          Rx SAFI: Unicast
    

As its evident we clearly prefer vRouter-1a for connectivity to 1.1.1.1/32

Reachability Test

Lets make sure that the Anycast IP (1.1.1.1) is reachable via vRouter1a:

  1. Source an ICMP frame from Host-Transit:

    [ec2-user@ip-10-100-11-10 ~]$ ping 1.1.1.1
    PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=253 time=1.54 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=253 time=1.53 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=253 time=1.54 ms
  2. Validate that ICMP frame arrived on vRouter-1a with a destination IP of 1.1.1.1 and gets NAT’d to 10.1.11.10:

    vRouter-1a#show ip nat translation kernel detail
    Source IP             Destination IP        Translated IP         TGT Type Intf   Proto              Packets        Packets Reply
    ---------------------------------------------------------------------------------------------------------------------------------
    10.100.11.10:0        1.1.1.1:0             10.1.11.10:0          DST DYN  -      ICMP                     3                    3
  3. Capture traffic on Host-1a and validate the same frame arrives on 10.1.11.10:

    [ec2-user@ip-10-1-11-10 ~]$ sudo tcpdump -nvvi eth0 host 10.100.11.10
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    02:49:26.918012 IP (tos 0x0, ttl 253, id 21891, offset 0, flags [DF], proto ICMP (1), length 84)
        10.100.11.10 > 10.1.11.10: ICMP echo request, id 3191, seq 1, length 64
    02:49:26.918041 IP (tos 0x0, ttl 255, id 51356, offset 0, flags [none], proto ICMP (1), length 84)
        10.1.11.10 > 10.100.11.10: ICMP echo reply, id 3191, seq 1, length 64
    02:49:27.919646 IP (tos 0x0, ttl 253, id 22136, offset 0, flags [DF], proto ICMP (1), length 84)
        10.100.11.10 > 10.1.11.10: ICMP echo request, id 3191, seq 2, length 64
    02:49:27.919669 IP (tos 0x0, ttl 255, id 51378, offset 0, flags [none], proto ICMP (1), length 84)
        10.1.11.10 > 10.100.11.10: ICMP echo reply, id 3191, seq 2, length 64

 

Failover Test

We will now failover the Anycast IP (1.1.1.1) from vRouter1a to vRouter1b:

  1. While the ICMP test is running on 10.100.11.10 shut the L0 interface on vRouter-1a and validate that the NAT translation is no longer there:

    vRouter-1a(config)#int l0
    vRouter-1a(config-if-Lo0)#shut
    vRouter-1a(config-if-Lo0)#
    vRouter-1a(config-if-Lo0)#show ip nat translation kernel detail
    Source IP             Destination IP        Translated IP         TGT Type Intf   Proto              Packets        Packets Reply
    ---------------------------------------------------------------------------------------------------------------------------------
  2. Ensure traffic gets routed to vRouter-1b for destination IP of 1.1.1.1/32:

    vRouter-Transit#sh ip bgp 1.1.1.1
    BGP routing table information for VRF default
    Router identifier 10.100.1.6, local AS number 65100
    BGP routing table entry for 1.1.1.1/32
     Paths: 1 available
      65101
        10.0.0.3 from 10.0.0.3 (10.1.2.6)
          Origin IGP, metric 0, localpref 100, IGP metric 1, weight 0, received 00:55:40 ago, valid, external, best
          Rx SAFI: Unicast
  3. Verify NAT translation on vRouter-1b to ensure that destination IP of 1.1.1.1 gets NAT’d to 10.1.21.0:

    vRouter-1b#show ip nat translation kernel detail
    Source IP             Destination IP        Translated IP         TGT Type Intf   Proto              Packets        Packets Reply
    ---------------------------------------------------------------------------------------------------------------------------------
    10.100.11.10:0        1.1.1.1:0             10.1.21.10:0          DST DYN  -      ICMP                     8                    8
  4. Traffic destined to 1.1.1.1/32 now shows up on 10.1.21.10:

    [ec2-user@ip-10-1-21-10 ~]$ sudo tcpdump -nvvi eth0 host 10.100.11.10
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    
    02:57:57.825430 IP (tos 0x0, ttl 253, id 4141, offset 0, flags [DF], proto ICMP (1), length 84)
        10.100.11.10 > 10.1.21.10: ICMP echo request, id 3217, seq 27, length 64
    02:57:57.825456 IP (tos 0x0, ttl 255, id 29846, offset 0, flags [none], proto ICMP (1), length 84)
        10.1.21.10 > 10.100.11.10: ICMP echo reply, id 3217, seq 27, length 64
    02:57:58.827060 IP (tos 0x0, ttl 253, id 4348, offset 0, flags [DF], proto ICMP (1), length 84)
        10.100.11.10 > 10.1.21.10: ICMP echo request, id 3217, seq 28, length 64
    02:57:58.827085 IP (tos 0x0, ttl 255, id 29950, offset 0, flags [none], proto ICMP (1), length 84)
        10.1.21.10 > 10.100.11.10: ICMP echo reply, id 3217, seq 28, length 64
    02:57:59.828623 IP (tos 0x0, ttl 253, id 4397, offset 0, flags [DF], proto ICMP (1), length 84)
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: