NAT - Notes

Consider that you always translate sources (there are exceptions, but forget about them for now) then most of the times when you have to translate a destination IP or port, look at the problem from the opposite direction:

• if you have to change the destination IP and/or port when going from inside to outside, then use ip nat outside source ...
• if you have to change the destination IP and/or port when going from outside to inside, then use ip nat inside source ...

Difference between static-routes with next-hop as exit-interface or next-hop as ip-address

https://supportforums.cisco.com/document/116711/static-routes-next-hop-exit-interface-or-ip-address

Install and Configure DNS in Windows Server 2012

•  Once you have access to windows server 2012, on the home screen search    for "Server Manager" as depicted below.      

•       Open Server Manager

•        Click on "Manage" and choose "Add roles and Features"

•        Choose "Role based or feature-based installation". Click on Next

•       On Server Roles select "DNS Server" and click on Next

•        Click on Next on all other installation steps by which the installation will start.

•        Once the DNS Server is installed, your Dashboard will depict DNS.

•     Click on Tools  and then click on DNS so that DNS Manager will be launched

•     Below is how a default DNS Manager configuration will look like

•     Now you can add an Authoritative Zone on this DNS Server. You can also add delegation which in our case is "gslb".

•  Click on "Action" and then click on "New Zone". Click on Next. Then click on "Primary   Zone" and then select "Forward Lookup Zone". Mention the Zone Name , Don't allow    Dynamic Updates and then click on Next and Finish.

•      Conditional Forwarders [to access resources in some other authoritative domain] and Global Forwarders [To access resources hosted in internet] can be added as suggested below.

DMVPN - Dynamic Multipoint VPN

DMVPN

Virtual Switching System - VSS on Cisco Catalyst 4500E

Introduction:

The Cisco Virtual Switching System is a clustering technology that pools two Cisco Catalyst 4500-E Series Switches with Cisco Catalyst Supervisor Engine 7-E or 7-LE or two Catalyst 4500-X Series Switches into a single virtual switch. In a VSS, the data plane of both clustered switches is active at the same time in both chassis. VSS members are connected by virtual switch links (VSLs) using standard Gigabit or 10 Gigabit Ethernet connections between the VSS members. VSLs can carry regular user traffic in addition to the control plane communication between the VSS members.

The Cisco VSS simplifies network configuration and operation by providing a loop-free Layer 2 topology using two Catalyst 4500 switches acting as one big Virtual switch. VSS reduces number of Layer 3 routing neighbors by providing a Layer 2 connectivity for access/distribution switches.

A VSS is a pair of combined 4500 switches acting as a single network element with redundancy and load balancing over port-channels (ether channels). One switch becomes the master or active chassis and the other one becomes the VSS standby.

VSS Switch Roles

VSS Active: 

The active chassis controls the VSS operation. It runs the control plane, L2 and L3 control protocols. It also runs the management plane functions like console interface, logs, file system and even power management.

VSS Standby: 

Listens to master, checks the status, forwards the ingress traffic but sends all control traffic to the VSS active chassis for processing. 

Virtual Switch Link:

To share control and data traffic between two chassis a VSL – Virtual Switch Link is required. VSL is implemented as a Port Channel. The control traffic gets higher priority over data on a VSL and never gets discarded.  

Physical vs Logical Topology in a VSS Configuration

This document describes how to configure a virtual switching system (VSS) for the Catalyst 4500 series switch (Supervisor Engine 7-E, Supervisor Engine 7L-E).

Some key point to be remembered for Cisco 4500 VSS:

1) Configuration/Capability Supported supervisors on Catalyst 4500-E: VSS support Supervisor Engine 7-E or 7-LE (identical pairs).For more information about hardware to support please refer 4500 VSS Hardware requirement

2) Software requirement: Cisco IOS XE 3.4.0SG and ROMMON IOS Version 15.0(1r) SG7 later released support VSS.(Also refer How to Upgrade Cisco 4500 SUP7-E & Sup7L-E ROMMON To support VSS).

3)license requirement : 

To know more on license requirement refer "Release Notes for the Catalyst 4500E Series Switch"

Feature	LAN Base	IP Base	Enterprise Service
Virtual Switching System (VSS	No	Yes (SUP7E only)	Yes
Support for Layer 3 MEC—VSS with Layer 3 Multichassis EtherChannel (MEC) at the aggregation layer Support for VSLP Fast Hello—With VSLP Fast Hello, the Catalyst 4500-X configured for VSS can now connect Access Switches that do not support the ePAgP protocol. Support for VSL Encryption Support for Asymmetrix chassis	No	Yes (SUP7E) No (SUP7LE)	Yes (SUP7E) Yes (SUP7LE)

For information about Software Activation Licensing please refer Cisco Catalyst 4500E Supervisor 7-E and 7L-E and Cisco Catalyst 4500-X Series Software Activation Licensing Deployment Guide.

4) Single-sup cross-chassis VSS support: Yes.

5) Quad-sup VSS configuration with in-chassis redundant sups: In-chassis redundant sups in rommon mode with active uplinks.

6) It also supports 10 Gigabit Ethernet Virtual Switch Link (VSL) and 1 Gigabit Ethernet VSL.

7) SSO and nonstop forwarding (NSF) must be configured on each switch. If a VSS does not meet the requirements for SSO redundancy; it will be incapable of establishing a relationship with the peer switch. Catalyst 4500/4500-X series switches' VSS does not support route processor redundancy (RPR) mode.

Prerequisite:

Before configuring VSS on Cisco 4500 please verify hardware and software requirement.

SW1#sh ver | in IOS
Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSAL-M), Version 03.04.00.SG RELEASE SOFTWARE (fc3)
Cisco IOS-XE software, Copyright (c) 2005-2010, 2012 by cisco Systems, Inc.
All rights reserved. Certain components of Cisco IOS-XE software are
documentation or "License Notice" file accompanying the IOS-XE software,
or the applicable URL provided on the flyer accompanying the IOS-XE

SW1#sh ver | in ROM
ROM: 15.0(1r)SG7
System returned to ROM by power-on 

SW1#sh license image levels 
Module name       Image level Priority Configured Valid license
--------------------------------------------------------------------
WS-X45-SUP7-E     entservices  1         YES        entservices            
                  ipbase       2         NO         ipbase                
                  lanbase      3         NO         lanbase  
 
Module Name     Role           Current Level     Reboot Level
--------------------------------------------------------------------
WS-X45-SUP7-E  Active         entservices       entservices

SW2#sh ver | in IOS
Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch Software (cat4500e-UNIVERSAL-M), Version 03.04.00.SG RELEASE SOFTWARE (fc3)
Cisco IOS-XE software, Copyright (c) 2005-2010, 2012 by cisco Systems, Inc.
All rights reserved. Certain components of Cisco IOS-XE software are
documentation or "License Notice" file accompanying the IOS-XE software,
or the applicable URL provided on the flyer accompanying the IOS-XE

SW2#sh ver | in ROM
ROM: 15.0(1r)SG7
System returned to ROM by power-on

SW2#sh license image levels
Module name       Image level Priority Configured Valid license
--------------------------------------------------------------------
WS-X45-SUP7-E     entservices  1         YES        entservices            
                  ipbase       2         NO         ipbase                
                  lanbase      3         NO         lanbase 

Module Name     Role           Current Level     Reboot Level
--------------------------------------------------------------------
WS-X45-SUP7-E   Active        entservices       entservices

Configuration Steps:

STEP1: Configure SSO [Statefull Switchover] and assign Virtual Switch Domain and Switch Numbers

SW1#conf t
SW1(config)#redundancy
SW1(config-red)#sso

You have to configure the same virtual switch domain number on both switches of the VSS. The virtual switch domain is a number between 1 and 255.After domain number you must configure one switch to be switch number 1 and the other switch to be switch number 2.

SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#switch virtual domain 10
Domain ID 10 config will take effect only
after the exec command 'switch convert mode virtual' is issued
SW1(config-vs-domain)#switch 1
SW1(config-vs-domain)#exit
SW1(config)#

SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#switch virtual domain 10
Domain ID 10 config will take effect only
after the exec command 'switch convert mode virtual' is issued
SW2(config-vs-domain)#switch 2
SW2(config-vs-domain)#exit
SW2(config)#

STEP2: Configuring VSL Port Channel:

Then you need to configure VSL with a unique port channel on each switch. During the conversion, the VSS configures both port channels on the VSS Active switch. If the VSS Standby switch VSL port channel number has been configured for another use, the VSS comes up in RPR[Route Processor Redudancy] mode. To avoid this situation, check that both port channel numbers are available on both of the switches.

SW1(config)#int port-channel 5
SW1(config-if)#switchport
SW1(config-if)#switch virtual link 1
SW1(config-if)#no shut
SW1(config-if)#exit
*Jan 24 05:19:57.092: %SPANTREE-6-PORTDEL_ALL_VLANS: Port-channel5 deleted from all Vlans

SW2(config)#int port-channel 10
SW2(config-if)#switchport
SW2(config-if)#switch virtual link 2
SW2(config-if)#no shut
SW2(config-if)#exit
SW2(config)#
*Jan 24 05:14:17.273: %SPANTREE-6-PORTDEL_ALL_VLANS: Port-channel10 deleted from all Vlans

STEP3: configure the VSL ports

You need to add the VSL physical ports to the port channel. In the following example, interfaces Gigabit Ethernet 7/3 and 7/4 on Switch 1 are connected to interfaces Gigabit Ethernet 4/45 and 4/46 on Switch 2.

SW1(config)#int range gig7/3 - 4
SW1(config-if-range)#switchport mode trunk
SW1(config-if-range)#channel-group 5 mode on
WARNING: Interface GigabitEthernet7/3 placed in restricted config mode. All extraneous configs removed!
WARNING: Interface GigabitEthernet7/4 placed in restricted config mode. All extraneous configs removed!
SW1(config-if-range)#exit

SW2(config)#int range gig4/45 - 46
SW2(config-if-range)#switchport mode trunk
SW2(config-if-range)#channel-group 10 mode on
WARNING: Interface GigabitEthernet4/45 placed in restricted config mode. All extraneous configs removed!
WARNING: Interface GigabitEthernet4/46 placed in restricted config mode. All extraneous configs removed!
SW2(config-if-range)#exit

Note: Once the interfaces are put into VSL port-channel with “channel-group"command, then the interfaces goes into “notconnect” status. Interface status will show UP, but the line protocol will be down. The interface will be in UP/down (not connect) status, till the switch is rebooted in step 4.

STEP4: Converting the Switch to Virtual Switch Mode:

You need to enter the “switch convert mode virtual” command on Switch 1 for Converting to Virtual Switch Mode .After you enter this command it will prompted to confirm the action. Enter yes. The system creates a converted configuration file, and saves the file to the bootflash:

SW1#switch convert mode virtual 

This command will convert all interface names
to naming convention "interface-type switch-number/slot/port",
save the running config to startup-config and
reload the switch.
Do you want to proceed? [yes/no]: yes
Converting interface names
Building configuration...
Compressed configuration from 6551 bytes to 2893 bytes[OK]
Saving converted configuration to bootflash: ...
Destination filename [startup-config.converted_vs-20130124-062921]?
Please stand by while rebooting the system...
Restarting system. 

Rommon (G) Signature verification PASSED  

Rommon (P) Signature verification PASSED  

FPGA   (P) Signature verification PASSED

Similarly you need to enter the “switch convert mode virtual” command on Switch 2 for converting to Virtual Switch Mode.

SW2#switch convert mode virtual​ 

This command will convert all interface names
to naming convention "interface-type switch-number/slot/port",
save the running config to startup-config and
reload the switch.
Do you want to proceed? [yes/no]: yes
Converting interface names
Building configuration...
Compressed configuration from 6027 bytes to 2774 bytes[OK]
Saving converted configuration to bootflash: ...
Destination filename [startup-config.converted_vs-20130124-052526]?
Please stand by while rebooting the system...
Restarting system. 

Rommon (G) Signature verification PASSED  

Rommon (P) Signature verification PASSED  

FPGA   (P) Signature verification PASSED 

************************************************************
*                                                          *
* Welcome to Rom Monitor for   WS-X45-SUP7-E System.       *
* Copyright (c) 2008-2012 by Cisco Systems, Inc.           *
* All rights reserved.                                     *
*                                                          *
************************************************************

After you confirm the above commands on both switches, the running configuration is automatically saved as the startup configuration and the switch reboots. After the reboot, the switch is in virtual switch mode, so you must specify interfaces with three identifiers (switch/module/port).

When switches are being converted to VSS, you should not set them to ignore startup-config. If done, the switch can be enabled to parse the startup-config at the rommon prompt. Ignoring startup-config in VSS mode causes a switch to boot in a semi-VSS mode, which can only be corrected by a reboot and by enabling the parsing of startup-config.

Verification:

1) To displays the virtual switch domain number, and the switch number and role for each of the switches you can use “show switch virtual” command.

SW1#sh switch virtual 

Executing the command on VSS member switch role = VSS Active, id = 1 


Switch mode                  : Virtual Switch
Virtual switch domain number : 10
Local switch number          : 1
Local switch operational role: Virtual Switch Active
Peer switch number           : 2
Peer switch operational role : Virtual Switch Standby 

Executing the command on VSS member switch role = VSS Standby, id = 2  


Switch mode                  : Virtual Switch
Virtual switch domain number : 10
Local switch number          : 2
Local switch operational role: Virtual Switch Standby
Peer switch number           : 1
Peer switch operational role : Virtual Switch Active

2) Once both switches cluster in single virtual switch, you will only have Active switch console and your Standby switch console appears as follow:

SW2-standby> 

Standby console disabled

3) To displays the role, switch number, and priority for each of the switch in the VSS use “show switch virtual role” command.

SW1#sh switch virtual role 

Executing the command on VSS member switch role = VSS Active, id = 1 

RRP information for Instance 1 

--------------------------------------------------------------------
Valid Flags   Peer     Preferred Reserved
               Count     Peer       Peer  

--------------------------------------------------------------------
TRUE   V       1           1         1  

Switch Switch Status Preempt       Priority Role     Local   Remote
       Number         Oper(Conf)   Oper(Conf)         SID     SID
--------------------------------------------------------------------
LOCAL   1     UP     FALSE(N )     100(100) ACTIVE   0       0
REMOTE  2     UP     FALSE(N )     100(100) STANDBY 6834   6152  

Peer 0 represents the local switch  

Flags : V - Valid
In dual-active recovery mode: No  

Executing the command on VSS member switch role = VSS Standby, id = 2 

RRP information for Instance 2  

--------------------------------------------------------------------
Valid Flags   Peer     Preferred Reserved
               Count     Peer       Peer  

--------------------------------------------------------------------
TRUE    V       1           1         1  

Switch Switch Status Preempt       Priority Role     Local   Remote
       Number         Oper(Conf)   Oper(Conf)         SID     SID
--------------------------------------------------------------------
LOCAL   2     UP     FALSE(N )     100(100) STANDBY  0       0
REMOTE  1     UP     FALSE(N )     100(100) ACTIVE   6152   6834 

Peer 0 represents the local switch

Flags : V - Valid
In dual-active recovery mode: No

4) To Displays information about the VSL use “show switch virtual link”command.

SW1#sh switch virtual link  

Executing the command on VSS member switch role = VSS Active, id = 1 

VSL Status : UP
VSL Uptime : 3 minutes
VSL Control Link : Gi1/7/4  

Executing the command on VSS member switch role = VSS Standby, id = 2 

VSL Status : UP
VSL Uptime : 3 minutes
VSL Control Link : Gi2/4/45

5) You can also verify information about the VSL port channel using “show switch virtual link port-channel”command.

SW1#sh switch virtual link port-channel 

Executing the command on VSS member switch role = VSS Active, id = 1 

Flags: D - down       P - bundled in port-channel
       I - stand-alone s - suspended
       H - Hot-standby (LACP only)
       R - Layer3     S - Layer2
       U - in use     N - not in use, no aggregation
       f - failed to allocate aggregator         

       M - not in use, no aggregation due to minimum links not met
       m - not in use, port not aggregated due to minimum links not met
       u - unsuitable for bundling
       d - default port  
       
       w - waiting to be aggregated  


Group Port-channel Protocol   Ports
------+-------------+-----------+-------------------
5     Po5(SU)          -       Gi1/7/3(P) Gi1/7/4(P)
10    Po10(SU)         -       Gi2/4/45(P) Gi2/4/46(P)  

Executing the command on VSS member switch role = VSS Standby, id = 2  

Flags: D - down       P - bundled in port-channel
       I - stand-alone s - suspended
       H - Hot-standby (LACP only)
       R - Layer3     S - Layer2
       U - in use     N - not in use, no aggregation
       f - failed to allocate aggregator         
       
       M - not in use, no aggregation due to minimum links not met
       m - not in use, port not aggregated due to minimum links not met
       u - unsuitable for bundling
       d - default port  
       
       w - waiting to be aggregated 

Group Port-channel Protocol   Ports
------+-------------+-----------+-------------------
5     Po5(SU)          -       Gi1/7/3(P) Gi1/7/4(P)
10    Po10(SU)         -       Gi2/4/45(P) Gi2/4/46(P) 

SW1#

Anycast DNS - Using BGP

In this article on Anycast DNS, we provide some examples of deploying Anycast using Border Gateway Protocol or BGP, the core routing protocol of the Internet. While BGP is mostly used by Internet Service Providers (ISPs), it is also used in some of the larger enterprise environments that must interconnect networks that span geographical and/or administrative regions and boundaries. Since BGP is a very complex routing protocol, we will provide only a basic recipe using Cisco and Quagga host-based routing software. A detailed discussion of the BGP protocol is beyond the scope of this article.

BGP is an Exterior Gateway Protocol (EGP), which means that it exchanges routing information between Autonomous Systems (AS). BGP is quite different from other IGPs, such as RIP and OSPF. BGP uses a different routing algorithm that uses a path vector algorithm, causing it to keep a list of every AS that the path passes through.

Our recipe will demonstrate how to configure Quagga to peer with a Cisco router using BGP. Suppose our Anycast design consists of an Autonomous System 65500 and AS 64555 as shown below. AS 64555 will contain our Anycast DNS servers and we'll establish peering between the two as shown below:

The recipe calls for configuring an Anycast DNS server each with two physical network connections on different subnets or VLANs. Two upstream routers are configured with BGP routing and will peer with our Anycast DNS server. The Anycast DNS servers will be configured with BGP routing protocol for originating our two Anycast VIPs of 192.168.0.1/32 and 192.168.1.1/32. The configuration is shown in the graphic below:

We could advertise two (2) Anycast VIPs from within the same netblock 192.168.0.0/24, such as 192.168.0.1/32 and 192.168.0.2/32. This would save address space, but we're simply trying to show by example by using VIPs from different netblocks.

Recipe - Multihomed Anycast DNS using BGP

Step 1 - Configure Anycast VIPs on "Server A"

Add two (2) Anycast VIPs to the host's loopback interface as a virtual loopback device or sub-interface. This is performed using the following command:

ifconfig lo:0 192.168.0.1 netmask 255.255.255.255
ifconfig lo:1 192.168.1.1 netmask 255.255.255.255

NOTE: The command above shows the syntax for performing this on Linux. The loopback devices are named slightly different on Sun Solaris. The loopback devices on Solaris are called lo0:0 and lo0:1 respectively.

Step 2 - Configure Zebra (component of Quagga) on "Server A"

The typical location of the zebra configuration file is /etc/quagga/zebra.conf, unless you have built Quagga with non-default file locations. Create the /etc/quagga/zebra.conf file as follows:

!
hostname server_a
!
password zebra
enable password zebra
!
interface eth0
ip address 10.0.1.10/24
!
interface eth1
ip address 10.0.2.10/24
!
interface lo
!
line vty
!

Once the zebra.conf file is built, start the zebra process and configure it to start automatically at boot time. With zebra running, we can access the running configuration interactively using the vty or vtysh. Please consult the Quagga on-line help for usage athttp://www.quagga.net

Step 3 - Configure BGP on "server_a"

In order to configure BGP routing on server_a, we need to configure the server to run the bgpd routing daemon. The Quagga BGP routing daemon is configured through the /etc/quagga/bgpd.conf file as follows:

!
hostname server_b
password zebra
log stdout
!
router bgp 64555
bgp router-id 10.0.3.10
network 192.168.0.1/32
network 192.168.1.1/32
timers bgp 4 16
neighbor 10.0.1.1 remote-as 65500
neighbor 10.0.1.1 next-hop-self
neighbor 10.0.1.1 prefix-list DEFAULT in
neighbor 10.0.1.1 prefix-list ANYCAST out
neighbor 10.0.2.1 remote-as 65500
neighbor 10.0.2.1 next-hop-self
neighbor 10.0.2.1 prefix-list DEFAULT in
neighbor 10.0.2.1 prefix-list ANYCAST out
!
ip prefix-list ANYCAST seq 5 permit 192.168.0.1/32
ip prefix-list ANYCAST seq 10 permit 192.168.1.1/32
ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
line vty
!

Start the BGPD routing daemon and enable the service to start automatically at boot time. Similar to zebra, the BGP process can be maintained and configured by using the vty or vtysh. The only interfaces in our configuration that are actively participating using BGP are eth0 and eth1. They will "peer" with their respective upstream BGP neighboring router. The eth0 peers with router R1-A, and the eth1 interface will peer with the R1-B router.

In our configuration above, we used some of the more advanced BGP configuration directives. Here is a summary of what some of them do:

• "timers bgp 4 16" - this command adjusts the network timers for keepalive and holddown timers. On Cisco routers, this defaults to 60 and 180 respectively. This means that a keepalive is sent every 4 seconds, and the router should wait 16 seconds for keepalive messages before it declares the peer dead.
• "neighbor 10.0.1.1 next-hop-self" - This configures "peering" by forcing routing updates to this upstream neighbor
• "neighbor 10.0.1.1 prefix-list DEFAULT in" - this allows the ip prefix-list called "DEFAULT" to propogate the default route to this device.
• "neighbor 10.0.1.1 prefix-list ANYCAST out" - this enables our outbound ANYCAST prefix-list to be advertised to our upstream peer

Step 4 - Configure "Server A" upstream router R1-A and R1-B with BGP

The following Cisco configuration were applied to the upstream router R1-A:

interface FastEthernet0/0
description link to BGP AS 65500
 ip address 192.168.2.31 255.255.255.0
!
interface FastEthernet0/1
description link to BGP AS 64555
 ip address 10.0.1.1 255.255.255.0
!
router bgp 65500
 bgp log-neighbor-changes 
 network 10.0.1.0 mask 255.255.255.0
 network 192.168.2.0 
 network 0.0.0.0
timers bgp 4 16
 neighbor 10.0.1.10 remote-as 64555
 neighbor 10.0.1.10 next-hop-self
 maximum-paths 4

Perform a similar configuration to router R1-B:

interface FastEthernet0/0
description link to BGP AS 65500
 ip address 192.168.2.32 255.255.255.0
!
interface FastEthernet0/1
description link to BGP AS 64555
 ip address 10.0.2.1 255.255.255.0
!
router bgp 65500
 bgp log-neighbor-changes
 network 10.0.2.0 mask 255.255.255.0
 network 192.168.2.0
 network 0.0.0.0
timers bgp 4 16
 neighbor 10.0.2.10 remote-as 64555
 neighbor 10.0.2.10 next-hop-self
 maximum-paths 4

At this point, BGP routing should be operational, and our Anycast VIPs should be advertised.

Step 5 - Create Failover Mechanism

In the event that our DNS server process on "Server A" or "Server B" fails, it is desirable to remove the Anycast VIPs from the global routing table. To do that, we must stop the routes from being advertised at their point of origination. A small script can be used to accomplish this by performing cursory checks on the health of the DNS server, and its ability to respond to queries. A simple script is used to detect issues with DNS. The script will issue queries and as soon as they fail, it will simply shutdown our routing daemon(s) or remove the routes from being advertised. The following is an example of what a script might look like:

#!/bin/bash
 
DNSUP=`/usr/sbin/dig @192.168.0.1 localhost. A +short`
if [ "$DNSUP" != "127.0.0.1" ];
then
echo "Stopping Anycast...."
    /etc/init.d/bgpd stop
    /etc/init.d/zebra stop
    /etc/init.d/named stop
else 
    echo "Everything's good... Do nothing..."
fi

The script should be scheduled in cron or at to minimize downtime and provide quick failover.

Step 6 - Repeate Steps 1-5 for all other Anycast Servers that are part of this Anycast Group.

Key BGP Troubleshooting Commands

BGP is a complex routing protocol to deploy and maintain, especially in larger enterprise network environments. A great amount of planning time is needed to achieve an efficient routing architecture that provides high availability and fast convergence. As you work with BGP, you will need to rely on a bevy of tools for troubleshooting and validating your BGP routed network. Here are some Cisco IOS commands used in configuring and/or troubleshooting BGP:

show ip bgp summary - shows BGP neighbors in summary mode

R1-A# show ip bgp summary
BGP router identifier 192.168.2.31, local AS number 65500
BGP table version is 1, main routing table version 1
6 network entries using 582 bytes of memory
6 path entries using 216 bytes of memory
2 BGP path attribute entries using 120 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 942 total bytes of memory
BGP activity 6/0 prefixes, 6/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.1.10       4 64555       4       3        0    0    0 00:00:02        2
10.0.2.10       4 64555       3       3        0    0    0 00:00:00        0

The output shown above by the show ip bgp summary displays a lot of useful information, including the local router identifier for router R1-A as 192.168.2.31, the local AS of 65500, and the BGP table version of 1. (An increasing version number indicates a network change is occurring; if no changes occur, this number remains the same.) It also shows six network paths on R1-A, using 582 bytes of memory. Memory is important in BGP because in a large network, such as the Internet, memory can be a limiting factor. As more BGP entries populate the IP routing table, more memory is required. The above output displays two configured remote peers: both are EBGP (because the AS is 64555 and are different the same as the local AS).

show ip bgp - displays the BGP topology table

R1-A# show ip bgp
BGP table version is 7, local router ID is 192.168.2.31
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
*> 0.0.0.0          192.168.2.1              0         32768 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 192.168.0.1/32   10.0.2.10                0             0 64555 i
*                   10.0.1.10                0             0 64555 i
*> 192.168.1.1/32   10.0.2.10                0             0 64555 i
*                   10.0.1.10                0             0 64555 i
*> 192.168.2.0      0.0.0.0                  0         32768 i

The BGP table version is displayed as 7 and the local router ID is 192.168.2.31. The various networks are listed along with the next hop address, metric (MED), local preference (Locpref), weight, and the path. The i on the left side (part of the status codes) indicates an internal BGP route and the i on the right side of our example indicates the origin. (i is for IGP, part of the origin codes.)

show ip bgp neighbors - displays BGP neighbors in detail

R1-A# show ip bgp neighbors
BGP neighbor is 10.0.1.10,  remote AS 64555, external link
  BGP version 4, remote router ID 10.0.1.10
  BGP state = Established, up for 00:05:07
  Last read 00:00:02, hold time is 16, keepalive interval is 4 seconds
  Configured hold time is 16, keepalive interval is 4 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                2          1
    Keepalives:            79         63
    Route Refresh:          0          0
    Total:                 82         65
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  BGP table version 7, neighbor version 7
  Index 3, Offset 0, Mask 0x8
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               6          2 (Consumes 72 bytes)
    Prefixes Total:                 6          2
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          2

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 4, min 0

  Connections established 1; dropped 0
  Last reset never
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.1.1, Local port: 179
Foreign host: 10.0.1.10, Foreign port: 48101

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x5E1F8):
Timer          Starts    Wakeups            Next
Retrans            84          0             0x0
TimeWait            0          0             0x0
AckHold            67         64             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0

iss:  915421219  snduna:  915422937  sndnxt:  915422937     sndwnd:   5840
irs: 4113695520  rcvnxt: 4113696868  rcvwnd:      15037  delrcvwnd:   1347

SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs

Datagrams (max data segment is 1460 bytes):
Rcvd: 152 (out of order: 0), with data: 67, total data bytes: 1347
Sent: 148 (retransmit: 0, fastretransmit: 0), with data: 83, total data bytes: 1717

BGP neighbor is 10.0.2.10,  remote AS 64555, external link
  BGP version 4, remote router ID 10.0.1.10
  BGP state = Established, up for 00:05:19
  Last read 00:00:04, hold time is 16, keepalive interval is 4 seconds
  Configured hold time is 16, keepalive interval is 4 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          1
    Keepalives:            82         65
    Route Refresh:          0          0
    Total:                 84         67
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  BGP table version 7, neighbor version 7
  Index 4, Offset 0, Mask 0x10
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               4          2 (Consumes 72 bytes)
    Prefixes Total:                 4          2
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          2
    Used as multipath:            n/a          2

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Bestpath from this peer:              2        n/a
    Total:                                2          0
  Number of NLRIs in the update sent: max 4, min 0

  Connections established 1; dropped 0
  Last reset never
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.2.1, Local port: 179
Foreign host: 10.0.2.10, Foreign port: 39231

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x60E88):
Timer          Starts    Wakeups            Next
Retrans            88          0             0x0
TimeWait            0          0             0x0
AckHold            69         51             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0

iss: 2991828195  snduna: 2991829917  sndnxt: 2991829917     sndwnd:   5840
irs: 4144867550  rcvnxt: 4144868936  rcvwnd:      14999  delrcvwnd:   1385

SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs

Datagrams (max data segment is 1460 bytes):
Rcvd: 157 (out of order: 0), with data: 69, total data bytes: 1385
Sent: 139 (retransmit: 0, fastretransmit: 0), with data: 87, total data bytes: 1721

Our output above shows the BGP neighbors in greater detail.

This concludes our high-level recipe on using BGP to configure Anycast DNS services.

CDN - Content Delivery Networks

A CDN (Content Delivery Network) is a global cluster of caches that can serve as local caches for static files (objects).

If a visitor of a website or a user of an application request certain files (e.g. images, pdfs, javascript, CSS files, etc), instead of the hosting server responding with these objects, the CDN takes care of serving them. Because a CDN takes the geo-location of the user in account, the file will be served from the caching-node closest to the visitor. This means data can become available to the user with lightning speed, independent of the location of the website or application.

If the caching-node that is assigned with serving the data to the visitor, doesn't have the requested object available, it will ask other nodes in the CDN first. If the object is not in the CDN, then the object will be requested from the Origin Server (the server or object store container where the source files reside).

In order for a CDN provider to know which objects belong to which request, a hostname / Origin Server combination needs to be registered with the CDN provider. A hostname is a subdomain of a domain controlled by the customer, like images.mydomain.com for instance. The Origin Server reflects the internet path to the objects that are to be served from the CDN. After registering both pieces of information with the CDN, it knows which objects belong to what subdomain.

At the end of the registration process for the hostname / Origin Server combination, a CNAME is sent back by the CDN provider. A CNAME links one subdomain (the hostname) to another subdomain (an entry point into the CDN) at the DNS level. To actually make the connection, the acquired CNAME must be implemented in the DNS record for the domain (mydomain.com).

If the CNAME returned by the CDN is abcdefghijk.a.b.cdn.com and the hostname is images.mydomain.com, than the CNAME record in mydomain.com should be similar to:

images.mydomain.com. IN CNAME abcdefghijk.a.b.cdn.com.

Only after the DNS is updated and the name servers have incorporated the change, the link with the CDN is ready. A request for http://images.mydomain.com/ will subsequently be served by the CDN.

If we continue the example for http://images.mydomain.com/logo.png, the first time the CDN receives a request for logo.png, it will collect it from the Origin Server and put it in it's cache. Every subsequent request for logo.png will be significantly faster.

Be aware that, in order to gain the maximum benefit of the CDN, some changes to your site could be needed. Static files that can be used in the CDN might be combined and dynamic elements might have to be separated and loaded at a later stage.

Request Flow with a CDN

1. Client requests logo.png on images.mydomain.com

2. The DNS system finds the CNAME and redirects the request to the CDN

3. If logo.png is not found or expired in the CDN, it is requested from the Origin Server and put in the CDN

4. The CDN responds to the Client request with the file logo.png

During the time the file logo.png is in the CDN, step 3 is skipped from the request flow and the response will be significantly faster.

CDN Cache control and Invalidations

A CDN stores a copy of your objects in a global network of caching servers. Upon request your objects will be served from these caches. Objects that are not requested for a period of a year will be cleaned out of the caching servers, but if there is a continuous demand for certain objects then they could remain in the cache indefinitely.

The problem with this is that new versions of these objects on the Origin server are not automatically replacing old versions of objects in the cache. For that reason we advise to assign a maximum lifespan to an object. This can be done through the use of Cache Control Headers.

Cache-Control HTTP Header

Cache-Control headers are HTTP headers that tell the cache how long an object should remain cached for. These headers are normally set by the Origin server, by Apache or Nginx in the case of a hosting server or by values in the meta-data for an object in the case of an object store.

RFC 2616 (section 14.9) has the full details on the Cache-Control header. Below we list the values that are most important in determining the lifespan of an object.

max-age=$seconds

The max-age value is the most important value for the cache-control header to determine the maximum lifespan of an object in the cache. It will always overrule any directives set by an Expires header for example (see RFC 2616 section 14.9.3).

The assigned variable is the age in seconds, so when an object should remain in the cache for a maximum of 15 minutes, the header should read: Cache-Control: max-age=900. We recommend maximum lifespans between one minute and one hour depending on the situation.

must-revalidate

We also recommend to add the must-revalidate flag to the Cache-Control header. This flag tells the cache to strictly follow any maximum lifespan information you give it about an object. We like to include this because caches somtimes take liberties with the maximum lifespans of objects.

public

This flag forces an object to always be cached, even if it normally would not.

Conclusion

When we want an object to be cached for a maximum of 15 minutes, the best header to set is:

Cache-Control: public, max-age=900, must-revalidate

Configuring the Cache-Control headers

Here we will provide an example on where and how to set the Cache-Control headers. For web servers we have an example for the Apache web servers. Please read the web server documentation for implementation details. We have an example concerning the object store: setting the cache control headers through the interface and setting them through a command line API call.

Apache2 web server

In order to be able to set the cache-control header, the mod_headers module must be installed and loaded into the Apache web server. Together with the FilesMatch directive, you can control the cache control header for specific file extensions. 

The example below is valid in both a .htaccess file or a VirtualHost segment.

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">

  Header set Cache-Control "public, max-age=900, must-revalidate"

</FilesMatch>

The ObjectStore (API)

In order to update HTTP Headers via the API, a POST request must be sent to the full path of the object you wish to update. A POST request replaces current headers on the object so it is imperative to resend important headers. An important header to resend is the Content-Type header, this header determines, in for instance a browser, what type (image/jpeg, video/mp4, text/plain, etc)  the object is and how to display it. In the below example we will update a jpeg image using the command line and the cURL binary:

curl -X POST -H "X-Auth-Token: $keystone_token"  \

-H "Cache-Control: public, max-age=900, must-revalidate" \

-H "Content-type: image/jpeg" \

https://$container.$projectid.objectstore.eu/photo-1.jpg