EdgeRouter - IPsec Route-Based Site-to-Site VPN to AWS VPC (BGP over IKEv1/IPsec)

Overview


Readers will learn how to configure a Route-Based Site-to-Site IPsec VPN between an EdgeRouter and the Amazon Web Services (AWS) Virtual Private Cloud (VPC). A Route-Based VPN is characterized by the usage of Virtual Tunnel Interfaces (vti) and routing entries. This example uses dynamic routing with BGP but is also possible to use static routing.

book_25x25white.png

NOTES & REQUIREMENTS:

Applicable to the latest EdgeOS firmware on all EdgeRouter models. Knowledge of the Command Line Interface (CLI) and advanced networking knowledge is required. Please see the Related Articles below for more information and see the attachments for the configuration used in this article.

 

Equipment used in this article:

EdgeRouter-4 (ER-4)

- AWS Virtual Private Gateway (VGW)

- Test clients behind the peers

 

AWS Requirements:

- Static public IP address on the ER

- If behind NAT forward UDP ports 4500 (NAT-T) and 500 (IKE) on the NATting device, as well as configure Approach #2 in this article.

- Active AWS subscription

 

More information about Amazon VPC and customer requirements can be found in the AWS Managed VPN Connections article.

Table of Contents


  1. Network Diagram
  2. Steps: Route-Based VPN
  3. Steps: Amazon Virtual Private Gateway
  4. Steps: Testing & Verification
  5. Related Articles

Network Diagram


Back to Top

The network topology is shown below. 

EdgeRouter (ER)

  • eth0 - 203.0.113.1
  • eth1 - 192.168.1.1/24
  • vti0 - 169.254.x.x/30
  • vti1 - 169.254.x.x/30
  • asn - 65000

AWS

  • vgw - 192.0.2.1
  • vgw - 198.51.100.1
  • vpc cidr - 172.16.0.0/22
  • vpc subnet - 172.16.1.0/24
  • asn - 65515

info_i_25x25white.png

NOTE: Amazon uses two tunnels for VPN connections, with each tunnel using a unique virtual private gateway public IP address (192.0.2.1 and 198.51.100.1 in this example). This means that two IPsec peers need to be configured on the EdgeRouter.


Steps: Route-Based VPN


Back to Top

For the purpose of this article, it is assumed that the routing and interface configurations are already in place and that reachability has been tested. The AWS peer IP addresses can be found under 'VPC Dashboard > VPN Connections > Tunnel Details'.

CLI: Access the Command Line Interface. You can do this using the CLI button in the GUI or by using a program such as PuTTY.

1. Enter configuration mode.

configure

2. Create the IKE / Phase 1 (P1) Security Associations (SAs) and enable Dead Peer Detection (DPD).

set vpn ipsec ike-group FOO0 key-exchange ikev1
set vpn ipsec ike-group FOO0 lifetime 28800
set vpn ipsec ike-group FOO0 proposal 1 dh-group 2
set vpn ipsec ike-group FOO0 proposal 1 encryption aes128
set vpn ipsec ike-group FOO0 proposal 1 hash sha1
set vpn ipsec ike-group FOO0 dead-peer-detection action restart
set vpn ipsec ike-group FOO0 dead-peer-detection interval 15
set vpn ipsec ike-group FOO0 dead-peer-detection timeout 30

3. Create the ESP / Phase 2 (P2) SAs.

set vpn ipsec esp-group FOO0 lifetime 3600
set vpn ipsec esp-group FOO0 pfs enable
set vpn ipsec esp-group FOO0 proposal 1 encryption aes128
set vpn ipsec esp-group FOO0 proposal 1 hash sha1

4. Define the first AWS peer address (replace <secret> with the AWS generated passphrase).

set vpn ipsec site-to-site peer 192.0.2.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.0.2.1 authentication pre-shared-secret <secret>
set vpn ipsec site-to-site peer 192.0.2.1 connection-type initiate
set vpn ipsec site-to-site peer 192.0.2.1 description IPsecAWS
set vpn ipsec site-to-site peer 192.0.2.1 local-address 203.0.113.1

5. Link the SAs created above to the first AWS peer and bind the VPN to a virtual tunnel interface (vti0).

set vpn ipsec site-to-site peer 192.0.2.1 ike-group FOO0
set vpn ipsec site-to-site peer 192.0.2.1 vti bind vti0
set vpn ipsec site-to-site peer 192.0.2.1 vti esp-group FOO0

6. Repeat the process for the second AWS peer address using a different virtual tunnel interface (vti1)

set vpn ipsec site-to-site peer 198.51.100.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 198.51.100.1 authentication pre-shared-secret <secret>
set vpn ipsec site-to-site peer 198.51.100.1 connection-type initiate
set vpn ipsec site-to-site peer 198.51.100.1 description IPsecAWS
set vpn ipsec site-to-site peer 198.51.100.1 local-address 203.0.113.1

set vpn ipsec site-to-site peer 198.51.100.1 ike-group FOO0
set vpn ipsec site-to-site peer 198.51.100.1 vti bind vti1
set vpn ipsec site-to-site peer 198.51.100.1 vti esp-group FOO0

7. Configure the RFC 3927 IP addresses on the virtual tunnel interfaces.

set interfaces vti vti0 address 169.254.x.x/30
set interfaces vti vti1 address 169.254.x.x/30
info_i_25x25white.png

NOTE: The IP addresses used above can be found in the downloaded 'Vyatta Network OS' configuration file. You can also calculate them based on the 169.254.x.x/30 addresses listed under 'VPC Dashboard > VPN Connections > Tunnel Details'.

8. Lower the TCP Maximum Segment Size (MSS) on the vti interfaces to 1379.

set firewall options mss-clamp interface-type vti
set firewall options mss-clamp mss 1379

9. (Optional) Create a prefix-list for BGP that will be used to filter advertised and received prefixes.

set policy prefix-list BGP rule 10 action deny
set policy prefix-list BGP rule 10 description 'deny local wan'
set policy prefix-list BGP rule 10 prefix 203.0.113.1/32

set policy prefix-list BGP rule 20 action deny
set policy prefix-list BGP rule 20 description 'deny aws vgw1'
set policy prefix-list BGP rule 20 prefix 192.0.2.1/32

set policy prefix-list BGP rule 30 action deny
set policy prefix-list BGP rule 30 description 'deny aws vgw2'
set policy prefix-list BGP rule 30 prefix 198.51.100.1/32

set policy prefix-list BGP rule 100 action permit
set policy prefix-list BGP rule 100 description 'permit local lan'
set policy prefix-list BGP rule 100 prefix 192.168.1.0/24

set policy prefix-list BGP rule 110 action permit
set policy prefix-list BGP rule 110 description 'permit aws vpc'
set policy prefix-list BGP rule 110 prefix 172.16.0.0/22
info_i_25x25white.png

NOTE: In this example, the same prefix-list is used for filtering the advertised and received prefixes. You may choose to split this up into a BGPout and BGPin prefix-list.

 

Note that AWS advertises the entire IPv4 CIDR block associated with the vpc and not individual subnets. 

10. Define the BGP neighbors and peering options.

set protocols bgp 65000 timers holdtime 30
set protocols bgp 65000 timers keepalive 10
set protocols bgp 65000 network 192.168.1.0/24

set protocols bgp 65000 neighbor 169.254.x.x prefix-list export BGP
set protocols bgp 65000 neighbor 169.254.x.x prefix-list import BGP
set protocols bgp 65000 neighbor 169.254.x.x remote-as 65515
set protocols bgp 65000 neighbor 169.254.x.x soft-reconfiguration inbound

set protocols bgp 65000 neighbor 169.254.x.x prefix-list export BGP
set protocols bgp 65000 neighbor 169.254.x.x prefix-list import BGP
set protocols bgp 65000 neighbor 169.254.x.x remote-as 65515
set protocols bgp 65000 neighbor 169.254.x.x soft-reconfiguration inbound
info_i_25x25white.png

NOTE: The BGP neighbor IP addresses are listed under 'VPC Dashboard > VPN Connections > Tunnel Details'. There is no need to configure ebgp-multihop as the peers are directly connected and there is no update-source configured.

11. Advertise the local prefix into BGP.

set protocols bgp 65000 network 192.168.1.0/24

12. Commit the changes and save the configuration.

commit ; save

Steps: Amazon Virtual Private Gateway


Back to Top

The names of the AWS gateway connections and subnets are randomly generated and unique for each environment. For your reference, the names used in this example are:

  • vpc: vpc-f8e99891
  • sbn: subnet-fb400392
  • rtbl: rtb-389cd051
  • cgw: cgw-4e2ca07e
  • vgw: vgw-d5c945e5
  • vpn: vpn-2704cf10

GUI: Access the AWS Management Console.

1. If not already created, create a new virtual private cloud (vpc).

Services > VPC > VPC Dashboard > Your VPCs > Create VPC

IPv4 CIDR Block: 172.16.0.0/22
IPv6 CIDR Block: No IPv6 CIDR Block
Tenancy: default

 

2. If not already created, create a new subnet in the vpc address range. 

VPC Dashboard > Subnets > Create Subnet

VPC: vpc-f8e99891
VPC CIDRs: 172.16.0.0/22
Availability Zone: No Preference
IPv4 CIDR Block: 172.16.1.0/24

3. Create a new customer gateway (cgw) and enter the EdgeRouter's public IP address.

VPC Dashboard > Customer Gateways > Create Customer Gateway

Name: IPsecER
Routing: Dynamic
BGP ASN: 65000

IP Address: 203.0.113.1

4. Create a new virtual private gateway (vgw).

VPC Dashboard > Virtual Private Gateways > Create Virtual Private Gateway

Name: IPsecER
ASN: Custom ASN
ASN: 65515

5. Attach the vgw to the vpc created earlier.

VPC Dashboard > Virtual Private Gateway > IPsecER > Actions > Attach to VPC

6. Propagate the routes that will be received on the vgw to the vpc.

VPC Dashboard > Route Tables > Route Propagation > Edit

Check Propagate: IPsecER Virtual Private Gateway

info_i_25x25white.png

NOTE: This step ensures that the AWS virtual hosts receive a route for the 192.168.1.0/24 network after the VPN establishes.

7. Create a new VPN connection and associate the previously created vgw and cgw.

VPC Dashboard > VPN Connections > Create VPN Connection

Name tag: IPsecER
Virtual Private Gateway: vgw-d5c945e5
Customer Gateway: Existing
Customer Gateway ID: cgw-4e2ca07e
Routing Options: Dynamic
Tunnel Options: Generated by Amazon

8. Download the configuration which contains all the SAs, pre-shared keys and IP addresses.

VPC Dashboard > VPN Connections > IPsecER > Download Configuration

Vendor: Vyatta
Platform: Vyatta Network OS
Software: Vyatta Network OS 6.5+


Steps: Testing & Verification


Back to Top

1. Verify that both tunnels are up for the VPN connection.

VPC Dashboard > VPN Connections > Tunnel Details

2. Verify that the remote EdgeRouter subnet is propagated to the vpc route table.

VPC Dashboard > Route Tables > Route Table

info_i_25x25white.png

NOTE: The output shows that the 192.168.1.0/24 network is reachable via the vgw and not via the default route (igw).

3. Verify that the customer gateway is available.

VPC Dashboard > Customer Gateways

4. Verify the IPsec Security Associations (SAs) and tunnel status.

show vpn ipsec sa
peer-192.0.2.1-tunnel-vti: #2, ESTABLISHED, IKEv1, 2e95d14d87b77239:727fcd2a809b88fc
  local  '203.0.113.1' @ 203.0.113.1
  remote '192.0.2.1' @ 192.0.2.1
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  established 181s ago, reauth in 27989s
  peer-192.0.2.1-tunnel-vti: #6, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_1024
    installed 181 ago, rekeying in 2612s, expires in 3420s
    in  c534961b,  13656 bytes,   164 packets,    25s ago
    out dac7cc75,  13168 bytes,   158 packets,    26s ago
    local  0.0.0.0/0
    remote 0.0.0.0/0
peer-198.51.100.1-tunnel-vti: #1, ESTABLISHED, IKEv1, 2b77d65c21c6762a:a08e6fee029e7a95
  local  '203.0.113.1' @ 203.0.113.1
  remote '198.51.100.1' @ 198.51.100.1
  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  established 200s ago, reauth in 27723s
  peer-198.51.100.1-tunnel-vti: #5, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_1024
    installed 200 ago, rekeying in 2554s, expires in 3400s
    in  cc40e8b9,  12420 bytes,   114 packets,    50s ago
    out ca59c2c7,  12992 bytes,   120 packets,    49s ago
    local  0.0.0.0/0
    remote 0.0.0.0/0
info_i_25x25white.png

NOTE: If there is no (or only partial) output, the tunnel is not established. Verify that the in and out traffic counters are increasing at the same time and that the remote and local subnets are listed as 0.0.0.0/0 in the output.

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):
  uptime: 6 minutes, since Oct 04 11:28:15 2017
  malloc: sbrk 376832, mmap 0, used 286576, free 90256
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 6
Listening IP addresses:
  203.0.113.1
  192.168.1.1
Connections:
peer-198.51.100.1-tunnel-vti:  203.0.113.1...198.51.100.1  IKEv1, dpddelay=15s
peer-198.51.100.1-tunnel-vti:   local:  [203.0.113.1] uses pre-shared key authentication
peer-198.51.100.1-tunnel-vti:   remote: [198.51.100.1] uses pre-shared key authentication
peer-198.51.100.1-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart
peer-192.0.2.1-tunnel-vti:  203.0.113.1...192.0.2.1  IKEv1, dpddelay=15s
peer-192.0.2.1-tunnel-vti:   local:  [203.0.113.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-vti:   remote: [192.0.2.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart
remote-access:  203.0.113.1...%any  IKEv1, dpddelay=15s
remote-access:   local:  [203.0.113.1] uses pre-shared key authentication
remote-access:   remote: uses pre-shared key authentication
remote-access:   child:  dynamic[udp/l2f] === dynamic[udp] TRANSPORT, dpdaction=clear
Routed Connections:
peer-192.0.2.1-tunnel-vti{6}:  ROUTED, TUNNEL
peer-192.0.2.1-tunnel-vti{6}:   0.0.0.0/0 === 0.0.0.0/0
peer-198.51.100.1-tunnel-vti{5}:  ROUTED, TUNNEL
peer-198.51.100.1-tunnel-vti{5}:   0.0.0.0/0 === 0.0.0.0/0
Security Associations (2 up, 0 connecting):
peer-192.0.2.1-tunnel-vti[2]: ESTABLISHED 3 minutes ago, 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
peer-192.0.2.1-tunnel-vti[2]: IKEv1 SPIs: 2e95d14d87b77239_i* 727fcd2a809b88fc_r, pre-shared key reauthentication in 7 hours
peer-192.0.2.1-tunnel-vti[2]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-192.0.2.1-tunnel-vti{6}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c534961b_i dac7cc75_o
peer-192.0.2.1-tunnel-vti{6}:  AES_CBC_128/HMAC_SHA1_96, 13656 bytes_i (164 pkts, 39s ago), 13168 bytes_o (158 pkts, 39s ago)
peer-192.0.2.1-tunnel-vti{6}:   0.0.0.0/0 === 0.0.0.0/0
peer-198.51.100.1-tunnel-vti[1]: ESTABLISHED 3 minutes ago, 203.0.113.1[203.0.113.1]...198.51.100.1[198.51.100.1]
peer-198.51.100.1-tunnel-vti[1]: IKEv1 SPIs: 2b77d65c21c6762a_i* a08e6feee7a95_r, pre-shared key reauthentication in 7 hours
peer-198.51.100.1-tunnel-vti[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-198.51.100.1-tunnel-vti{5}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cc40e8b9_i ca59c2c7_o
peer-198.51.100.1-tunnel-vti{5}:  AES_CBC_128/HMAC_SHA1_96, 420 bytes_i (5 pkts, 208s ago), 992 bytes_o (11 pkts, 62s ago)
peer-198.51.100.1-tunnel-vti{5}:   0.0.0.0/0 === 0.0.0.0/0

5. Verify the IPsec strongSwan configuration file.

sudo cat /etc/ipsec.conf
# generated by /opt/vyatta/sbin/vpn-config.pl

config setup

conn %default
        keyexchange=ikev1

conn peer-198.51.100.1-tunnel-vti
        left=203.0.113.1
        right=198.51.100.1
        leftsubnet=0.0.0.0/0
        rightsubnet=0.0.0.0/0
        ike=aes128-sha1-modp1024!
        keyexchange=ikev1
        ikelifetime=28800s
        dpddelay=15s
        dpdtimeout=30s
        dpdaction=restart
        esp=aes128-sha1-modp1024!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        compress=no
        authby=secret
        mark=9437185
        auto=route
        keyingtries=%forever
#conn peer-198.51.100.1-tunnel-vti

conn peer-192.0.2.1-tunnel-vti
        left=203.0.113.1
        right=192.0.2.1
        leftsubnet=0.0.0.0/0
        rightsubnet=0.0.0.0/0
        ike=aes128-sha1-modp1024!
        keyexchange=ikev1
        ikelifetime=28800s
        dpddelay=15s
        dpdtimeout=30s
        dpdaction=restart
        esp=aes128-sha1-modp1024!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        compress=no
        authby=secret
        mark=9437186
        auto=route
        keyingtries=%forever
#conn peer-192.0.2.1-tunnel-vti

6. Capture the IKE traffic on the WAN interface.

sudo tcpdump -i eth0 -n udp dst port 500   
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident[E]
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick[E]

IP 203.0.113.1.500 > 198.51.100.1.500: isakmp: phase 1 I ident
IP 198.51.100.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 198.51.100.1.500: isakmp: phase 1 I ident[E]
IP 198.51.100.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident[E]
IP 203.0.113.1.500 > 198.51.100.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 198.51.100.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick[E]
info_i_25x25white.png

NOTE: This is a live capture. If there is no output that means that the traffic is either not being generated by the peer(s), or there is something blocking the traffic upstream.

7. Capture and analyze the IPsec VPN log messages.

sudo swanctl --log
[KNL] creating acquire job for policy 203.0.113.1/32[ipencap] === 198.51.100.1/32[ipencap] with reqid {5}
[IKE] initiating Main Mode IKE_SA peer-198.51.100.1-tunnel-vti[1] to 198.51.100.1
[NET] sending packet: from 203.0.113.1[500] to 198.51.100.1[500] (244 bytes)
[NET] received packet: from 198.51.100.1[500] to 203.0.113.1[500] (228 bytes)
[IKE] remote host is behind NAT
[NET] sending packet: from 203.0.113.1[4500] to 198.51.100.1[4500] (108 bytes)
[NET] received packet: from 198.51.100.1[4500] to 203.0.113.1[4500] (76 bytes)
[IKE] IKE_SA peer-198.51.100.1-tunnel-vti[1] established between 203.0.113.1[203.0.113.1]...198.51.100.1[198.51.100.1]
[IKE] CHILD_SA peer-198.51.100.1-tunnel-vti{5} established with SPIs and TS 0.0.0.0/0 === 0.0.0.0/0

[KNL] creating acquire job for policy 203.0.113.1/32[ipencap] === 192.0.2.1/32[ipencap] with reqid {6}
[IKE] initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-vti[2] to 192.0.2.1
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (156 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (124 bytes)
[IKE] remote host is behind NAT
[NET] sending packet: from 203.0.113.1[4500] to 192.0.2.1[4500] (108 bytes)
[NET] received packet: from 192.0.2.1[4500] to 203.0.113.1[4500] (76 bytes)
[IKE] IKE_SA peer-192.0.2.1-tunnel-vti[2] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
[IKE] CHILD_SA peer-192.0.2.1-tunnel-vti{6} established with SPIs and TS 0.0.0.0/0 === 0.0.0.0/0
info_i_25x25white.png

NOTE: This is also live capture. If there is no output that means that the traffic is either not being allowed through the firewall. Alternatively, you can use the show vpn log | no-more command to view the entire IPsec log history.

8. Verify the state of the BGP connections and reception / advertisement of the BGP prefixes.

show ip bgp summary 
BGP router identifier 192.168.1.1, local AS number 65000
BGP table version is 6
2 BGP AS-PATH entries
0 BGP community entries
Neighbor                 V   AS      MsgRcv   MsgSen   TblVer   InQ   OutQ    Up/Down   State/PfxRcd
169.254.x.x              4   65515   33       34       5        0     0       00:00:16             1
169.254.x.x              4   65515   12       11       6        0     0       00:01:23             1
info_i_25x25white.png

NOTE: You should see a number (amount of prefixes) under the State/PfxRcd state. Any other state, such as 'connect’ means that the BGP session is not established.

show ip bgp 
BGP table version is 6, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
    Network          Next Hop            Metric    LocPrf       Weight  Path
*>  172.16.0.0/22    169.254.x.x         100                    0       65515 i
*                    169.254.x.x         200                    0       65515 i
*>  192.168.1.0      0.0.0.0                       100          32768   i

9. Display the detailed BGP neighborship information and reception / advertisement of the BGP prefixes.

show ip bgp neighbors 169.254.x.x 
BGP neighbor is 169.254.x.x, remote AS 65515, local AS 65000, external link
  BGP version 4, remote router ID 169.254.x.x
  BGP state = Established, up for 00:02:03
  Last read 00:02:03, hold time is 30, keepalive interval is 10 seconds
  Configured hold time is 30, keepalive interval is 10 seconds
  Neighbor capabilities:
    Route refresh: advertised and received (old and new)
    4-Octet ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
  Received 16 messages, 0 notifications, 0 in queue
  Sent 15 messages, 0 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds
 For address family: IPv4 Unicast
  BGP table version 6, neighbor version 6
  Index 2, Offset 0, Mask 0x4
  Inbound soft reconfiguration allowed
  Community attribute sent to this neighbor (both)
  Inbound path policy configured
  Outbound path policy configured
  Incoming update prefix filter list is *BGP
  Outgoing update prefix filter list is *BGP
  1 accepted prefixes
  1 announced prefixes
 Connections established 1; dropped 0
Local host: 169.254.x.x, Local port: 52222
Foreign host: 169.254.x.x, Foreign port: 179
Nexthop: 169.254.x.x
Nexthop global: ::
Nexthop local: ::
BGP connection: non shared network

show ip bgp neighbors 169.254.x.x advertised-routes
BGP table version is 7, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
    Network          Next Hop            Metric    LocPrf       Weight  Path
*>  192.168.1.0      169.254.x.x         100                    32768   i

Total number of prefixes 1

show ip bgp neighbors 169.254.x.x received-routes
BGP table version is 7, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
    Network          Next Hop            Metric    LocPrf       Weight  Path
*>  172.16.0.0/22    169.254.x.x         100                    0       65515 i

Total number of prefixes 1

10. Verify the BGP table and the routing table.

show ip bgp 192.168.1.0/24
BGP routing table entry for 192.168.1.0/24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  169.254.x.x 169.254.x.x
  Local
    0.0.0.0 from 0.0.0.0 (192.168.1.1)
      Origin IGP, localpref 100, weight 32768, valid, sourced, local, best
      Last update: Wed Oct  4 12:19:48 2017

show ip bgp 172.16.0.0/22
BGP routing table entry for 172.16.0.0/22
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  169.254.x.x
  65515
    169.254.x.x from 169.254.x.x (169.254.x.x)
      Origin IGP, metric 100, localpref 100, valid, external, best
      Last update: Wed Oct  4 12:26:33 2017
  65515
    169.254.x.x from 169.254.x.x (169.254.x.x)
      Origin IGP, metric 200, localpref 100, valid, external
      Last update: Wed Oct  4 12:27:40 2017
info_i_25x25white.png

NOTE: Only one of these prefixes is the 'best' route and will be placed in the routing table. In this case, the prefix from the first neighbor is flagged as the best route because the metric is lower (100). The metric or MED (Multi-Exit Discriminator) is added to BGP session on the AWS side to prefer one tunnel over the other.

show ip route
> - selected route, * - FIB route, p - stale info
IP Route Table for VRF "default"
C    *> 169.254.x.x/30 is directly connected, vti1
C    *> 169.254.x.x/30 is directly connected, vti0
B    *> 172.16.0.0/22 [20/100] via 169.254.x.x, vti0, 00:02:01

11. If configured, verify the counters on the BGP prefix-list.

show ip prefix-list detail 
Prefix-list with the last deletion/insertion: BGP
ip prefix-list BGP:
   count: 5, range entries: 0, sequences: 10 - 110
    bgpd:
     seq 10 deny 203.0.113.1/32 eq 32 (hit count: 0, refcount: 5)
     seq 20 deny 192.0.2.1/32 eq 32 (hit count: 0, refcount: 5)
     seq 30 deny 198.51.100.1/32 eq 32 (hit count: 0, refcount: 5)
     seq 100 permit 192.168.1.0/24 eq 24 (hit count: 5, refcount: 0)
     seq 110 permit 172.16.0.0/22 eq 22 (hit count: 5, refcount: 0)

12. Capture the BGP messages on the virtual tunnel interfaces.

sudo tcpdump -i vti0 -n tcp dst port 179 or src port 179
12:27:39.252145 IP 169.254.x.x.36236 > 169.254.x.x.179: Flags [.], ack 1, win 437
12:27:39.252642 IP 169.254.x.x.36236 > 169.254.x.x.179: Flags [P.], seq 1:54, ack 1, win 437
12:27:39.333234 IP 169.254.x.x.179 > 169.254.x.x.36236: Flags [.], ack 54, win 210
12:27:39.333432 IP 169.254.x.x.179 > 169.254.x.x.36236: Flags [P.], seq 1:73, ack 54, win 210

Related Articles


Back to Top