Options exist today for connections between an branch office and the core of an Enterprise network:
- private connectivity (provide an inherently private path): leased lines, Frame Relay, MPLS VPNs, Metro Ethernet.
- public connectivity. All public options use the Internet for connectivity regardless of the particular physical Internet access technology–typically DSL, cable, or wireless broadband–all these options use a public Internet to forward the packets.
Broadband Internet Access Basics
The term broadband - (today) has grown to become synonymous with high speed.
The hardware typically includes an IP router and either a cable modem or DSL modem.
The term modem has taken new meaning over the years compared to its original historic use. (a cable modem or DSL modem sits in the same location as a traditional analog modem,)
PPPoE
- LAN interface connected toward the ISP, the router uses a slightly different convention on the Ethernet called PPP over Ethernet (PPPoE).
The frames sent by the router still use an Ethernet header, but then include a PPP header, and then an IP header.
The PPP header gives the router and ISP the capability to use PPP features such as the Challenge Handshake Authentication Protocol (CHAP). CHAP allows the ISP to perform authentication, which allows the ISP to confirm the identity of the router that sent the packet.
- DSL uses a similar protocol, PPP over ATM (PPPoA), also in part to support PPP CHAP.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/xe-3s/bba-xe-3s-book/bba-pppoe-client-xe.pdf
- PPPoE is a commonly used application in the deployment of digital subscriber lines (DSLs).
- The PPP over Ethernet Client feature expands PPPoE functionality by providing support for PPPoE on the client and the server.
- PPP connections must be established between two endpoints over a serial link.
- The PPPoE Client feature provides PPPoE client support on routers at customer premises.
Restrictions for PPP over Ethernet Client
The PPPoE client does not support the following:
• More than ten clients per customer premises equipment (CPE)
• Quality of service (QoS) transmission with queueing on the dialer interface
• Dial-on-demand
• Easy VPN
• Native IPv6
• PPPoE client over ATM permanent virtual circuit (PVC)
• Coexistence of the PPPoE client and server on the same device
• Multilink PPP (MLP) on dialer interfaces
• Nonstop forwarding (NSF) with stateful switchover (SSO)
Consumer-class products enable by default most of the features such as DHCP client, server, and NAT/PAT.
Enterprise-class routers typically rely on explicit configuration by a network engineer for these same features.
Dial-on-Demand Routing (DDR) link
Until Cisco IOS Release 12.2(4)T, interesting traffic was used to bring up a DDR link. If there was no interesting traffic and the idle timeout interval was reached, the link was torn down. However, there are situations where a link needs to be up all the time. The Dialer Persistent feature provides the option to ignore idle timers and interesting traffic, thereby keeping the link up and maintaining DDR dialed calls indefinitely. The Dialer Persistent feature allows you to configure the intervals to be used for dial attempts, both initially on startup and when a persistent link is brought down due to external failures.
A new interface configuration command, dialer persistent, allows a dial-on-demand routing (DDR) dialer profile connection to be brought up without being triggered by interesting traffic. When configured, the dialer persistent command starts a timer when the dialer interface starts up and starts the connection when the timer expires. If interesting traffic arrives before the timer expires, the connection is still brought up and set as persistent. The command provides a default timer interval, or you can set a custom timer interval.
The Dialer Persistent feature allows the connection settings in the dialer profile to be configured as persistent, that is, the connection is not torn down until the shutdown interface command is entered on the dialer interface. If the persistent connection is torn down for some other reason, such as the ISDN line goes down, the system immediately tries to bring the connection back up, and will use any other settings configured for dialing on the dialer interface.
Router(config-if)# dialer persistent [ delay [ initial ] seconds | max-attempts number ]Forces a dialer interface to be connected at all times, even in the absence of interesting traffic.
Restrictions
- The Dialer Persistent feature is available only with dialer profiles and not with legacy dialers.
- The dialer idle-timeout interface configuration command cannot be configured when the dialer persistent command is configured.
Dialer Persistent Plus Failed Connection Delays Configuration Example (link)
- configure a 1-minute delay at boot-up,
- a 10-second delay for redialing after a failed connection with a maximum of five tries before stopping
!
interface dialer 1
ip address negotiated
encapsulation ppp
dialer pool 1
dialer remote-name remote1
dialer idle-timeout 0 either
dialer string 7135550199
dialer persistent delay initial 60
dialer persistent delay 10
dialer persistent max-attempts 5
ppp authentication chap
ppp chap hostname DDR
ppp chap password mysecret
!
ip classless
ip route 0.0.0.0 0.0.0.0 dialer 1
ip route 172.30.21.0 255.255.255.0 1.1.1.5
ip route 172.30.114.0 255.255.255.0 172.30.21.1
no ip http server
!
!
map-class dialer test
dialer isdn speed 56
access-list 183 permit ip host 10.239.28.2 host 10.239.28.128
access-list 183 permit ip host 10.239.28.128 host 10.239.28.2
!
VPDN - Virtual Private Dialup Network
A VPDN is a network that extends remote access to a private network using a shared infrastructure. VPDNs use Layer 2 tunnel technologies (L2F, L2TP, and PPTP) to extend the Layer 2 and higher parts of the network connection from a remote user across an ISP network to a private network. VPDNs are a cost effective method of establishing a long distance, point-to-point connection between remote dial users and a private network.
To enable virtual private dialup networking (VPDN) on the router and inform the router to look for tunnel definitions in a local database and on a remote authorization server (home gateway), if one is present, use the vpdn enable command in global configuration mode. To disable, use the no form of this command.
https://www.cisco.com/c/en/us/td/docs/security/asa/asa72/configuration/guide/conf_gd/pppoe.html
Branch Office Security
With a permanent Internet connection near the core of the Enterprise network, the Enterprise typically uses one or more border security products. These products include stateful firewalls such as the ASA appliance from Cisco, plus Intrusion Prevention Systems (IPS).
Again, for economic reasons, it makes more sense to implement those features on the same router platform already needed for so many other reasons. So, Cisco includes firewall and IPS features in IOS. These features include the older Context Based Access Control (CBAC) and newer IOS Zone-Based Firewall. Cisco also supplies the IOS IPS feature as well.
Although it may seem that running such features on a branch router might overload the router, Cisco designed its Integrated Services Routers (ISR) to have the power to concurrently run many services for exactly this type of application. ISRs include the older model
series 800, 1800, 2800, and 3800 ISR families, plus model series 1900, 2900, and 3900, introduced in 2009.
IPsec Tunnels
Typically the engineer configures a tunnel between the branch and the Enterprise core.
Then the branch router directs traffic destined for the Enterprise through the tunnel.
For such packets, the branch router will not translate the IP address of the original packet using NAT. Instead, the branch router will encrypt the IP packet and encapsulate the encrypted packet inside another IPv4 header, using public source and destination addresses in this new packet. Then, the branch router can forward this packet through the public Internet, with a device in the Enterprise core receiving and decrypting the packet.
IP Security (IPsec) defines the details of how this particular tunnel works. IPsec defines which security standards may be used to encrypt the packet–for example, IPsec allows the use of triple DES (3DES) and Advanced Encryption Standard (AES).
Branch Routing for the Small Branch
With the addition of an IPsec tunnel from the branch to the Enterprise core, the branch does have a kind of routing decision to make: to send a packet through the tunnel, or to send it to the local ISP after performing NAT
Routing in Medium and Large Branches
Another private WAN connection exists between the branch and the Enterprise core. So, the branch needs to make choices about when to use routes that use the private connection and when to use routes that use the public connection.
GRE
GRE is a tunneling protocol developed by Cisco.
It is capable of encapsulating a wide variety of network layer protocols packets inside IP tunnels. This creates virtual point-topoint links. It is a common option to use GRE to pass dynamic routing protocol traffic across an IPsec tunnel.
GRE tunnels do not provide encryption services. GRE is just an encapsulation protocol. It does not offer other services such as encryption. By default, the traffic leaves in clear text.
Two main routing options exist: using static routes and using an IGP.
Static routes can be used to forward traffic over the private connection and over the IPsec tunnel.
 |
| Routing Updates over GRE over IPSec |
With GRE, multicasts and broadcasts will be carried inside unicast packets, which IPsec can forward.
However, IPsec does not directly support IGP protocols, because the IPsec tunnel cannot natively forward IPv4 multicasts.
To overcome this restriction, you can use a GRE tunnel that actually runs over the IPsec tunnel. GRE supports multicasts by encapsulating them in unicast packets, so GRE supports IGPs.
GRE and IPSec create overhead
Configuring GRE
1. Create tunnel interfaces for GRE.
2. Change the crypto ACL to encrypt GRE traffic.
3. Configure routing protocols to route through the GRE tunnel.
A common best practice is to create a loopback interface, which is then used as the tunnel source IP address.
interface tunnel 0A GRE tunnel can be configured to operate within an IPv4, IPv6, or multipoint configuration using the tunnel mode gre command.
ip address 172.16.100.2 255.255.255.252
tunnel source 209.165.200.242
tunnel destination 209.165.200.226
access-list 110 permit gre host 209.165.200.242 host 209.165.200.226
router eigrp 1
network 192.168.1.0 0.0.0.255
network 172.16.100.0 0.0.0.3
no auto-summary
However, by default the encapsulation of GRE is within an IPv4 packet, and therefore the tunnel mode gre ip command is not required.
Optionally, the keepalive command could also be configured to provide a trigger mechanism to cause the line protocol to be changed from an up/up to an up/down state during a failure event.
GRE implementation plan to upgrade a branch office:
Step 1. Deployed broadband connectivity
Step 2. Configured static routing
Step 3. Verified other services
Step 4. Implemented and tuned the IPsec VPN
Step 5. Configured GRE tunnels
show interfaces tunnel 0
show crypto session detail
The IPSEC FLOW is permitting IP protocol 47, which is the protocol number for GRE
There are four options to route dynamic routing protocols through an IPsec tunnel:
■ Point-to-point generic routing encapsulation (P2P GRE)
■ Virtual tunnel interface (VTI)
■ Dynamic multipoint VPN (DMVPN)
■ Group encrypted transport VPN (GET VPN)
GRE features:
■ A GRE tunnel acts like a point-to-point link from a Layer 3 perspective.
■ A GRE tunnel supports many passenger protocols, including IPv4.
■ A GRE tunnel encapsulates/forwards broadcasts and multicasts, therefore supporting IPv4 IGPs.
■ A GRE tunnels can run through IPsec tunnels.
VTI
A major benefit of VTI is that the configuration does not require a static mapping of an IPsec session to a physical interface.
The IPsec endpoint is associated with an actual virtual interface. This is then a routable interface at the tunnel endpoint, and many common interface capabilities can be applied to the IPsec tunnel. They include the association of routing protocols and therefore routing across the VPN tunnel. In the end, VTI is a good alternative to IPsec over GRE tunnels.
GRE
Nowadays, with VoIP, branch offices expect to call other branch offices directly, without going through headquarters, which would only contribute latency.
DMVPN and GET VPN
Scalable alternatives to GRE when full-mesh connectivity is necessary between the branches are DMVPN and GET VPN.
These technologies combine multipoint GRE tunnels, dynamic resolutions of endpoints, and crypto profiles that overwrite the requirement for defining crypto maps.
VTI, DMVPN, and GET VPN are beyond the scope of CCNP
Floating Static Routes
Routing Using Floating Static Routes
A floating static route - ip route command configures a static route in which the command overrides the default AD value of 1.
For example, if the IGP learns a route for the same prefix as defined in the static route, the router does not use the static route with the higher AD, instead uses the dynamically learned route with the lower AD.
The term floating static refers to that the route may float in and out of the routing table.
Dynamic Routing over the GRE Tunnel
Simply configure an IGP to run as normal, over both the private WAN connection and over a GRE tunnel.
The design can then use all the usual tools to manipulate the choice of routes, including tuning the metrics and configuring variance to influence load sharing.
DSL
DSL uses the Telco local loop: the phone line that runs between the phone company’s nearby facility (called the central office, or CO) and the customer site.
From the customer premise perspective, the customer can still use the same old analog phones, which still use frequencies below 4000 Hz. The DSL router connects to another RJ-11 socket in the wall, just as if it were just another analog telephone. However, the
router sends digital signals at frequencies above 4000 Hz, which does not interfere with the voice traffic. So, both the voice and DSL electrical signals flow over the same cable, at the same time, just at different frequencies.
- some DSL installations require the use of filters on the lines connected to the phones. These filters prevent humans from hearing some of the higher frequency DSL tones.
From the telco perspective, the Telco has to separate the voice and DSL signals. To do so, the Telco uses a device called a DSL Access Multiplexor (DSLAM). It splits the analog signal off to the switch that handles traditional analog voice calls and splits the digital
traffic to a router.
 |
| DSL: Customer and Telco perspectives |
At Layer 1, the DSL uses digital signals that use some encoding.
At Layer 2, DSL uses two different data link protocols: Asynchronous Transfer Mode (ATM) and Point-to-Point Protocol (PPP).
DSL uses ATM in the traditional role of a data link protocol, and PPP for several reasons, but particularly for its CHAP authentication. For DSL, ATM controls the use of the Layer1 medium so that data can be successfully sent over the link and to the right device.
ATM defines the headers used on the link, the data link addresses, and the rules for passing Layer 3 data up and down the protocol stack. For instance, the ATM cell headers enable the DSLAM to know where to send the data received from a customer over a DSL link.
ATM uses a PVC concept similar to a Frame Relay PVC. With DSL, an ATM PVC would exist between the DSL router at the branch and the ISP router.
- ATM address identifies the PVC, but the address value is local, so the value used by one endpoint may be different than the address used on the other end of the PVC,
- Frame Relay uses the DLCI as the identifier of a PVC, whereas ATM uses a twopart address, called the Virtual Path Identifier/Virtual Connection Identifier (VPI/VCI).
When a packet needs to be sent out a Frame Relay interface, the router adds a Frame Relay header and trailer and sends the frame.
ATM adds a short extra header to the packet and then performs segmentation. The segmentation process breaks the data into 48-byte segments and adds a 5-byte header to each to create ATM cells. The cell header holds the VPI/VCI pair, which allows the network to forward the cells to the correct destination end of the PVC.
Encapsulation process also adds a PPP header to the IP packet before sending the data over the DSL link. The routers use the PPP header for several reasons, including PPP authentication with CHAP, and for dynamic address assignment and discovery. This convention to use both PPP and ATM protocols together is called PPP over ATM (PPPoA).
DSL Configuration
First consider that DSL is a switched connection. (is not always ON service- a router can start and stop the DSL connection).
The idea that DSL routers do something to dial the connection means that the connection is actually switched.
IOS implements DSL configuration using some older switched network commands, including dialer interfaces and virtual templates. (logic and features related to a dialed connection).
The main pieces of the DSL configuration as shown in this section are as follows:
■ The configuration creates a dialer interface.
■ The Layer 3 and PPP configuration related to DSL is applied to the dialer interface.
■ The ATM configuration is applied to the physical ATM interface.
■ The ATM interface is linked to the dialer interface.
■ An IP route forwards traffic out the dialer interface, which triggers the DSL encapsulation process.
interface ATM 0/0Configuring NAT
no ip-address
pvc 0/42
encapsulation aal5mux ppp dialer
dialer pool-member 1
interface dialer 2
encapsulation ppp
! Use PPP to Ask ISP the IP Address to Use
ip address negotiated
dialer pool 1
!
! Chap-Related Commands
hostname BO1
ppp authentication chap callin
ppp chap password reallysecret
!
!
ip route 0.0.0.0 0.0.0.0 dialer 2
NAT configuration easily supports the concept of performing NAT for traffic going to Internet destinations and not performing NAT for traffic in the tunnel.
! NAT overload exampleConfiguring DHCP Server
interface fastethernet 0/0
ip address 10.99.1.9 255.255.255.0
ip nat inside
interface dialer 2
ip nat outside
! source IP address is from the branch’s local LAN subnet (10.99.1.0/24)
ip nat inside source list local-lan interface dialer2 overload
ip access-list extended local-lan
permit ip 10.99.1.0 0.0.0.255 any
The branch router also may need to act as the DHCP server.
ip dhcp pool fredNote that no interface configuration is needed on the LAN interface–the router notices the incoming interface of the DHCP request, compares the connected subnets to the pool, and picks a pool that matches the correct address range.
network 10.99.1.0 255.255.255.0
default-router 10.99.1.9
ip dhcp exclude-address 10.99.1.9
dns-server 10.2.2.2 128.107.2.1
IPSec Configuration
IPsec tunnel unfortunately does not allow IGP traffic to flow directly over the IPsec VPN tunnel.
Solutions:
- GRE,
- Virtual Tunnel Interfaces:Similar in concept to GRE tunnels but it uses an encapsulation that does not add and extra 4-byte header. (GRE adds such a header.)
- Dynamic Multipoint VPN (DMVPN):Creates a multipoint VPN concept, allowing less configuration to add new sites.
- Group Encrypted Transport (GET) VPN:A more recent addition to IOS, also supporting multipoint VPNs with less configuration to add new sites.
Configuring an IPsec VPN
! Security details
crypto isakmp policy 1
encryption 3des
authentication pre-share
group 2
crypto isakmp key donttellitsasecret address 128.107.9.9
crypto ipsec transform-set name-i-chose esp-3des esp-sha-hmac
!
! Tunnel details
crypto map branchmap 10 ipsec-isakmp
set transform-set name-i-chose
set peer 128.107.9.9 <-destination (another end-point) of tunnel
match address 101
! The crypto map causes IOS to only encrypt and tunnel the packets that are matched by ACL 101
access-list 101 permit ip 10.99.1.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 101 permit gre any any
!
! enable the logic - causing IOS to consider applying IPsec to packets exitingDialer 2
interface dialer 2
crypto map branchmap
GRE Tunnels Configuration
interface tunnel 9The configuration also requires two main branches of logic for routing to work correctly:
ip address 10.99.2.1 255.255.255.255
tunnel source loopback 1
tunnel destination 10.12.1.9
! tunnel mode command is not needed, because IOS defaults to use IPv4 as the transport protocol
interface loopback 1
ip address 10.12.1.1 255.255.255.0
router eigrp 1
network 10.12.1.1 0.0.0.0
network 10.99.2.1 0.0.0.0
ip route 10.12.1.9 255.255.255.255 dialer2
- the tunnel destination must be reachable (a static route was added for this purpose),
- the routers need to exchange routes that will list the tunnel interface as the outgoing interface, which in turn directs
packets through the tunnel. (EIGRP configuration that enables EIGRP on tunnel 9)
Summary–Branch Routing from PC1 to Enterprise Server S1
R1
1. R1 receive packet with dst=10.1.1.1
2. R1’s best route for destination 10.1.1.1 uses outgoing interface tunnel 9
3. R1 adds a new private IPv4 header and GRE header to the original packet (tunnel destination is address 10.12.1.9)
4. R1 best route for 10.12.1.9 lists Dialer 2 as the outgoing interface. The crypto map on interface Dialer 2 refers to an ACL, and ACL matches this packet with a permit action. This combination of logic tells R1 to use IPsec to encrypt this packet for transmission over the IPsec tunnel.
5. R1 encrypts the packet the GRE-created packet (step 3).
6. R1 encapsulates the encrypted data, adding several IPsec headers, plus a new IPv4 header (src_ip=R1 Public IP, dst_ip= end of the IPsec tunnel == 128.107.9.9).
7. R1 routes packet to 128.107.9.9 matching a route (probably a default route) that lists Dialer 2 (again) as the outgoing interface.
However, the crypto map’s ACL does not match the packet with a permit action, so BO1 bypasses any further IPsec functions and simply tries to forward the packet.
8. Forwarding out the dialer interface then causes this DSL-connected router to forward the packet out the underlying ATM interface, which performs the encapsulation and segmentation.
Interestingly, this process drives the branch router to make comparisons to the routing table three separate times when forwarding this data.
IPsec Virtual Tunnel Interface (VTI)
- provide a routable interface type for terminating IPsec tunnels and an easy way to define protection between sites to form an overlay network.
- simplify configuration of IPsec for protection of remote links, support multicast, and simplify network management and load balancing.
- provides a simpler alternative to using generic routing encapsulation (GRE) or Layer 2 Tunneling Protocol (L2TP) tunnels for encapsulation and crypto maps with IPsec.
- configuration does not require a static mapping of IPsec sessions to a physical interface.
- allows for the flexibility of sending and receiving both IP unicast and multicast encrypted traffic on any physical interface, such as in the case of multiple paths.
VTI interfaces: static VTIs (SVTIs) and dynamic VTIs (DVTIs).
- SVTI configurations can be used for site-to-site connectivity in which a tunnel provides always-on access between two sites. The advantage of using SVTIs as opposed to crypto map configurations is that users can enable dynamic routing protocols on the tunnel interface without the extra 4 bytes required for GRE headers, thus reducing the bandwidth for sending encrypted data.
Additionally, multiple Cisco IOS software features can be configured directly on the tunnel interface and on the physical egress interface of the tunnel interface. This direct configuration allows users to have solid control on the application of the features in the pre- or post-encryption path.
- DVTIs can provide highly secure and scalable connectivity for remote-access VPNs. The DVTI technology replaces dynamic crypto maps and the dynamic hub-and-spoke method for establishing tunnels.
## Static IPsec Virtual Tunnel Interfaces
crypto IPsec profile <profile-name>
set transform-set <transform-set-name>
!
interface tunnel <number>
ip address <address mask>
tunnel mode ipsec ipv4
tunnel protection IPsec profile <profile-name> [shared]
! static config
tunnel source <interface>
tunnel destination <ip-address>
!
## Dynamic IPsec Virtual Tunnel Interfaces
crypto IPsec profile <profile-name>
set transform-set <transform-set-name>
!
interface virtual-template <number>
tunnel mode mode
tunnel mode ipsec ipv4
tunnel protection IPsec profile <profile-name> [shared]
!
crypto isakamp profile <profile-name>
virtual-template <template-number>
!