Advanced_Routing_Services_Lab_Documentation

Advanced Routing and Services

Program Introduction
This Training intensive will focus on the GNS3 topology found here You will be tasked
with designing the IP scheme for a large network, implementing dynamic routing
protocols, and configuring overlay and customer segmentation technologies.

Section 1: Building the Transport Network

Progress Expectation
Before completing this section you will have working GNS3 deployment and will have
downloaded and loaded the GNS3 portable project advanced_routing_and_services
.gns3.

Section Outline
In this section you will start by addressing the interfaces of 14 routers within a topology
to provide basic connectivity. You will then configure OSPF as an IGP and use it to
advertise the loopbacks of all routers within the routing domain. You will complete this
section by configuring BGP neighbor relationships for all routers within the topology
and advertising a default route.

Section 1.1: IP Addressing

Section Goal
Build an IP addressing scheme for the network depicted below. Document the IP
scheme in the IP address matrix. Build configurations for all routers in the topology and
test connectivity between routers.

Section Expectations
The configurations for section 1.1 will satisfy the following requirements.

1. All subnets within the OSPF topology will fall with within a single /24

1 / 89
 Advanced_Routing_Services_Lab_Documentation

2. G0/0 interfaces within the 10.X.X.0/26 network should share a common /29
subnet
3. All other links will be point-to-point (/30) networks. But will fall within the
ranges defined in the diagram.
4. All Routers will have loopbacks addressed to 10.255.X.1-14/32

Section 1.2: IP Multi-Area OSPF

Section Goal
Implement multi-area OSPF within the topology. Identify ABRs within the topology
and configure them to connect leaf routers into the backbone area. Validate OSPF
neighborship within the topology. Validate connectivity to all loopbacks within the
topology. While running a continuous ping from a leaf router, shut upstream interfaces
towards the backbone and analyze the availability of the network. Document routing

2 / 89
 Advanced_Routing_Services_Lab_Documentation

table changes as OSPF calculates new best paths to the loopback interfaces.

Section Expectations
The OSPF configurations for this section will satisfy the following requirements.

1. ABRs will advertise only the summary addresses of OSPF area 1-4 and leaf router
loopbacks into the backbone.
2. ABRs will advertise only the summary address of Area 0 and the loopbacks of the
leaf and backbone routers to the leaf routers.
3. All OSPF routers will have routing table entries for the loopbacks of all other OSPF
routers.

3 / 89
 Advanced_Routing_Services_Lab_Documentation

OSPF Configuration Theory

OSPF Neighborship
To form neighbor relationships in OSPF, the OSPF router process must be initialized
and interfaces must be configured to send OSPF hello packets. The Area-ID of OSPF
hello packets must match to form neighbor relationships. OSPF interfaces are often
enabled with the network <subnet-id> <wildcard-mask> area <area-id> syntax. You may

4 / 89
 Advanced_Routing_Services_Lab_Documentation

find that managing OSPF configurations with multiple interfaces in different areas
becomes easier when OSPF is enabled per-interface. The syntax for interface-level
OSPF configuration is as follows:

interface <interface-id>
ip address <ip> <subnet-mask>
ip ospf <process-id> area <area-id>

OSPF Summarization
OSPF is a link-state routing protocol. All routers in an OSPF area know the full LSDB for
routers within that area. This makes summarization within an OSPF area impossible.
When summarizing routes in OSPF, we perform summarization on the ABR. This allows
us to constrain the routing tables in different OSPF areas, and to prevent topology
changes in one area from causing SPF calculations in another area.
Summarization can be achieved with the command:
area <id> range <summary-address> <summary-mask>
Under the global OSPF process.

Device Example
Upon completion of general OSPF configuration and ABR summarization, the inter-
area routes from the perspective of a leaf router should look like this.

LR-AR1-1#sh ip route | in O IA
O IA 10.X.X.0/26 [110/2] via 10.X.X.73, 00:12:07, GigabitEthernet0/1
O IA 10.X.X.96/27 [110/2] via 10.X.X.73, 00:12:07, GigabitEthernet0/1
O IA 10.X.X.128/27 [110/3] via 10.X.X.73, 00:12:07, GigabitEthernet0/1
O IA 10.X.X.160/27 [110/3] via 10.X.X.73, 00:11:37, GigabitEthernet0/1
O IA 10.255.X.1/32 [110/3] via 10.X.X.73, 00:11:37, GigabitEthernet0/1
O IA 10.255.X.2/32 [110/2] via 10.X.X.65, 00:12:17, GigabitEthernet0/0
O IA 10.255.X.3/32 [110/3] via 10.X.X.73, 00:11:37, GigabitEthernet0/1
O IA 10.255.X.4/32 [110/2] via 10.X.X.73, 00:12:07, GigabitEthernet0/1
O IA 10.255.X.5/32 [110/3] via 10.X.X.73, 00:11:37, GigabitEthernet0/1
O IA 10.255.X.6/32 [110/3] via 10.X.X.73, 00:12:07, GigabitEthernet0/1
O IA 10.255.X.9/32 [110/3] via 10.X.X.73, 00:11:25, GigabitEthernet0/1
O IA 10.255.X.10/32 [110/3] via 10.X.X.73, 00:11:25, GigabitEthernet0/1
O IA 10.255.X.11/32 [110/4] via 10.0.X.73, 00:11:48, GigabitEthernet0/1

5 / 89
 Advanced_Routing_Services_Lab_Documentation

O IA 10.255.X.12/32 [110/4] via 10.X.X.73, 00:11:48, GigabitEthernet0/1

O IA 10.255.X.13/32 [110/4] via 10.X.X.73, 00:11:37, GigabitEthernet0/1
O IA 10.255.X.14/32 [110/4] via 10.X.X.73, 00:11:37, GigabitEthernet0/1

Notice that we are filtering the routing table for inter-area routes using show ip route |
include O IA , and that all inter-area routes aside from loopbacks are summary
addresses for each area. Performing show ip route ospf should display ECMP routes for
almost all prefixes, but it’s output will include intra-area routes.

Configuration Examples:
By viewing the configuration example we see that nothing special is happening within
the configuration of routers that have all their interfaces in a non-backbone area. All
summarization is being performed on Area Border Routers.

hostname LR-AR1-1
!
interface loopback 0
ip address 10.255.X.7 [Link]
ip ospf 100 area 1
!
router ospf XXX
!
interface G0/0
ip address 10.X.X.65 [Link]
ip ospf XXX area 1
no shutdown
!
interface G0/1
ip address 10.X.X.69 [Link]
ip ospf XXX area 1
no shutdown
!
interface G0/2
ip address 10.X.X.73 [Link]
ip ospf XXX area 1
no shutdown
!

6 / 89
 Advanced_Routing_Services_Lab_Documentation

hostname BR-1
!
interface loopback 0
ip address 10.255.X.2 [Link]
ip ospf area 0
!
router ospf 100
area 0 range 10.X.X.0 [Link]
area 1 range 10.X.64.0 [Link]
!
interface g0/0
ip address 10.X.X.2 [Link]
ip ospf XXX area 0
no shutdown
!
interface g0/1
ip address 10.X.X.10 [Link]
ip ospf XXX area 0
no shutdown
!
interface g0/2
ip address 10.X.X.13 [Link]
ip ospf XXX area 0
no shutdown
!
interface g0/3
ip address 10.X.X.66 [Link]
ip ospf XXX area 1
no shutdown
!
interface g0/4
ip address 10.X.X.75 [Link]
ip ospf XXX area 1
no shutdown
!

Section 1.3: iBGP

Section Goal

7 / 89
 Advanced_Routing_Services_Lab_Documentation

Overlay a full-mesh of iBGP over the existing topology. Using the AS 65501 , configure
peering so that all routers are iBGP neighbors with all other routers. Advertise a default
route from

CORE-EDGE to all neighbors. Validate that all neighbors can reach the public internet
via ICMP.

Section Expectations
The iBGP configurations within this section will satisfy the following requirements

4. All routers will have BGP neighborship with all other routers via their loopback
addresses.
5. All routers will have a routing table entry of [Link] via CORE-EDGE.
6. All routes advertised by iBGP peers will use the advertising router's loopback
address as the next-hop.

iBGP Configuration Theory 8 / 89

 Advanced_Routing_Services_Lab_Documentation

iBGP Configuration Theory

Loopback Peering
Routers within the same BGP Autonomous System have an iBGP neighbor relationship.
We are using the loopback interfaces to abstract our BGP relationship within the
network away from the transport OSPF network. Since loopback interfaces never go
down, as long as OSPF can calculate a path to the loopbacks of neighbor routers, our
BGP sessions within 65501 will never go down.

BGP next-hop advertisement.

iBGP does not change the next hop of routes advertised to neighbors by default. This
can pose a problem if a route advertised into an AS uses a next hop not known by every
router within the AS. All routers who do not have an entry for the next hop will not
install the route into the local RIB. Since every router within 65501 has routes to the
loopbacks of every other router, peering over loopbacks then using the peer IP as the
next hop solves this issue. Next hop advertisements can be configured within the BGP
neighbor statements using neighbor <neighbor_ip> next-hop-self .

Device Example
Upon completion of iBGP configuration the BGP routes for a leaf router should look like
this.

LR-AR1-1#sh ip route bgp

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is [Link] to network [Link]
B* [Link]/0 [200/0] via [Link], 01:32:39

Configuration Example:

9 / 89
 Advanced_Routing_Services_Lab_Documentation

Notice that LR-AR-1-1 is running the same AS as it’s neighbor, and utilizing next-hop-
self in the routes it will advertise.

LR-AR1-1#sh run | sec bgp

router bgp 65501
bgp log-neighbor-changes
neighbor 10.255.X.1 remote-as 65501
neighbor 10.255.X.1 update-source Loopback0
neighbor 10.255.X.1 next-hop-self

Section 2: Connectivity at the Edge

Progress Expectation
Before completing this section you will have built connectivity within the network
using OSPF and BGP. You will have successfully advertised a default route to all routers
within the topology and can ping public IP addresses from every router within the
network.

Section Outline
In this section you will extend connectivity to four edge routers by assigning them an
AS and a /24 prefix in the [Link]/10 space. Each edge router will be directly
connected to the transport network with a /29 in the [Link]/24 space. Each edge
router will advertise their public prefix into the transport network. Each edge router
will receive a default route from the leaf router they are connected to. Leaf routers will
advertise default routes to edge routers, but may or may not advertise the public
prefixes of other edge sites. Edge routers will each have a /32 loopback interface in the
assigned public subnet. All edge routers will be reachable via their public loopbacks
from other edge routers throughout the network.

Section 2.1: eBGP

Section Goal

10 / 89
 Advanced_Routing_Services_Lab_Documentation

Connect four edge routers to the transport network. Assign each router a /24 in the
[Link]/10 space and document it. Advertise a default route to the leaf routers.
Advertise the public prefix of each edge router into the transport network. Assign a
loopback for each CE-RTR in their public prefix using a /32. Validate that all CE routers
can reach the public loopbacks of all other routers.

Section Expectations
The configurations for section 2.1 will satisfy the following requirements.

1. Each edge router should connect to leaf routers in different OSPF areas.
2. Each edge router will peer with the leaf routers using interfaces in the
[Link]/24 space. Each peering network will be a /29. 3. Each edge router
should have a loopback in their assigned public subnet.
3. Each edge router should receive a default route via the leaf router.
4. Each edge router should advertise a /24 in the [Link]/10 space
5. Neither CE or LR routers should advertise prefixes in the [Link]/24 space.

eBGP Configuration Theory

eBGP Neighbors and Route Advertisements

11 / 89
 Advanced_Routing_Services_Lab_Documentation

External BGP sessions are configured to allow peers from different autonomous
systems to exchange routing updates. In this example LR-AR1-1 is in AS 65501, CE-1
can be in any AS other than 65501 for this session to be considered eBGP. Routes
received by eBGP peers will use the peer ip address as the next-hop, meaning we do not
need to use next-hop-self command on LR-AR1-1 towards CE-RTR-1. In the example
above 198.51.100.X/29 serves as a transit network and is not advertised to the rest of AS
65501. Routers in AS 65501 should use the loopback address of LR-AR1-1 to reach the
prefix advertised by CE-1

Summary Route Advertisement

After configuring a network statement BGP checks for a matching prefix in the global
RIB, and if found, installs it in the BGP Loc-RIB and sets the following path attributes:

Connected network: The next-hop BGP attribute is set to [Link], the BGP origin
attribute is set to i (IGP), and the BGP weight is set to 32,768.
Static route or routing protocol: The next-hop BGP attribute is set to the next-hop
IP address in the RIB, the BGP origin attribute is set to i (IGP), the BGP weight is
set to 32,768, and the MED is set to the IGP metric.

CE-RTR-1 needs to advertise 100.64.X.0/24 to LR-AR1-1 but it does not have a

matching prefix for 100.64.X.0 in it’s routing table. Even though the router has a
loopback within the network, BGP requires an exact match in the local RIB before
routes can be installed in the local BGP table and advertised to peers. To get around
this, we can install a summary route for 100.64.X.0/24 with a next hop of null0. Traffic
destined to the loopback address will be received and processed by the router, all other
traffic will be dropped.

A configuration for a summary route and advertisement looks like this:

ip route 100.64.X.0 [Link] null0

!
router bgp 6550X
network 100.64.X.0 mask [Link]
!

Device Example

12 / 89
 Advanced_Routing_Services_Lab_Documentation

Upon completion of this section, all routers within AS 65501 should have iBGP routes to
four public /24s via the loopbacks of leaf routers. All edge routers should have 3 routes
to the public prefixes advertised by the other edge routers via leaf routers.

Core-Edge#sh ip route BGP

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, \* - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route

- - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is [Link] to network [Link]
[Link]/24 is subnetted, 4 subnets
B 100.64.X.0 [200/0] via 10.255.X.7, 02:16:28
B 100.64.X.0 [200/0] via 10.255.X.11, 02:16:28
B 100.64.X.0 [200/0] via 10.255.X.9, 01:27:18
B 100.64.X.0 [200/0] via 10.255.X.14, 00:26:33
10
CE-RTR-1#sh ip route BGP
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, \* - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
- - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is [Link] to network [Link]
B\* [Link]/0 [20/0] via [Link], 02:27:04
[Link]/8 is variably subnetted, 5 subnets, 2 masks
B [Link]/24 [20/0] via [Link], 02:27:37
B [Link]/24 [20/0] via [Link], 01:43:01
B [Link]/24 [20/0] via [Link], 00:30:22

Configuration Examples: 13 / 89
 Advanced_Routing_Services_Lab_Documentation

Configuration Examples:
The BGP configurations within this section are very straightforward and similar to the
configurations in 1.3, aside from different AS numbers and the inclusion of a network
statement on the edge router side.

CE-RTR-1#sh run | sec bgp

router bgp 655XX
bgp log-neighbor-changes
network 100.64.X.0 mask [Link]
neighbor 198.51.100.X remote-as 65501

Section 2.2: Controlling BGP Prefix Advertisement

and Reception.
Section Goal
Sites connected to Area 1 and Area 2 will advertise prefixes into AS 65501 but not to
other external peers of 65501. Sites in Area 3 and Area 4 will advertise prefixes to all
peers, but request only a default route from AS 65501. Leaf routers will be configured to
only accept the assigned public prefix from all sites. Utilize route maps to add the no-
export BGP community to routes advertised from Area 1 and 2 sites. Utilize prefix lists
to advertise only a default route to Area 3 and 4 sites. Utilize an inbound route-map on
leaf routers at all sites to only accept the 100.64.x.0/24 prefix assigned. Validate
connectivity to all sites.

Section Expectations
The BGP prefix advertisement configurations within this section will satisfy the
following requirements

6. eBGP peers connected to routers in Area 1 and Area 2 will add the no-export
community to routes advertised into AS 65501
7. Leaf routers providing connectivity to edge nodes in Area 1 and 2 will send the BGP
communities they receive to all iBGP peers that provide connectivity to
downstream routers.
8. Routers in Area 1 and Area 2 will have prefixes in their routing tables for routers in

14 / 89
 Advanced_Routing_Services_Lab_Documentation

Area 3 and 4, but not each other.

9. Routers in Area 3 and Area 4 will receive only a default route from AS 65501, this
will be accomplished utilizing prefix lists.
10. All leaf routers that provide connectivity to edge routers will utilize inbound route
maps that only accept the assigned /24 of the edge router.
11. All edge routers will still have connectivity to all other edge routers.

Prefix Advertisement and Reception Theory

Prefix lists
Prefix-lists can be used to filter prefixes advertised or received from dynamic routing
protocols. While prefix lists look very similar to access lists, they contain functionality
that makes it much easier to create complex matching rules for route advertisement
and reception. For example, you could write a prefix list that accepts routes from
[Link]/8 but only networks larger than a /30 and smaller than a /23.

The power of prefix lists derive from the less than and equal than operators. A prefix
list that matches the conditions specified above looks like this.

ip prefix-list my-prefix-list permit [Link]/8 ge 29 le 24

Breaking down the structure of the prefix list can provide further clarity.

15 / 89
 Advanced_Routing_Services_Lab_Documentation

ip prefix-list my-prefix-list - create and name the prefix list

Permit [Link]/8 - allow routes from [Link]/8
ge 29 - allow subnets /29 and bigger (/28, /27...)
le 24 - allow routes /24 and smaller (/25, /26...)

Prefix lists can then be applied to BGP neighbors like this

router bgp <ASN>

neighbor <neighbor-ip> prefix-list my-prefix-list out

Route maps
Route maps provide many different features to a variety of routing protocols. At the
simplest level, route maps can filter networks much the same way as ACLs, but they
also provide additional capability through the addition or modification of network
attributes. To influence a routing protocol, a route map must be referenced from the
routing protocol. Route maps are critical to BGP because they are the main component
in modifying a unique routing policy on a neighbor- by-neighbor basis.

We will be using route maps to add BGP communities to outbound routes advertised to
upstream eBGP peers, and to validate that the prefixes we are receiving are expected
prefixes from downstream eBGP peers.

To configure a route map, we use the route-map command, followed by the name of the
route map, a permit or deny statement, and a sequence number .

route-map my-route-map permit 10

We then enter the route-map sub-configuration and can implement some form of
matching logic or set some attributes.

Match some access list

(config-route-map)#match ip address <some-acl>

Set some sort of attribute

16 / 89
 Advanced_Routing_Services_Lab_Documentation

(config-route-map)#set <some-protocol-attribute>

Finally, we apply the route map to a BGP neighbor. If we want the route map to apply to
advertised routes, we specify “out”. If we want the route map to apply to received
routes, we can use “in”.

router bgp <ASN>

neighbor <neighbor-ip> route-map <route-map-name> <in/out>

BGP Communities
We can utilize BGP communities to add more information to prefixes advertised to
neighbors for traffic engineering and routing purposes. There are four well known BGP
communities that can be used without any policy configuration. Custom BGP
communities can be created using a numeric value and defining the policy locally.

The four well-known BGP communities are:

12. Internet: Advertise to all BGP neighbors

13. No-Advertise: Don’t advertise the prefix to any BGP neighbor
14. No-Export: Don’t advertise the prefix to any eBGP neighbors
15. Local-AS: Don’t advertise the prefix outside of the BGP confederation sub-AS.

BGP communities are configured by setting the community in a route-map.

route-map <route-map-name> permit 10

set community <some-community>

The route map must then be applied to a BGP neighbor.

router bgp <ASN>

neighbor <neighbor-ip> route-map <route-map-name>

17 / 89
 Advanced_Routing_Services_Lab_Documentation

Finally, we must tell BGP to send the community to the BGP neighbor, as it will not by
default.

router bgp <ASN>

neighbor <neighbor-ip> send-community

Device Example
Using the show ip bgp we can validate whether or not our BGP community
configuration is working. This is also a useful command to gain more insight into the
attributes of a BGP route.

LR-AR1-1#sh ip bgp 100.64.X.0

BGP routing table entry for 100.64.X.0/24, version 8

Paths: (1 available, best #1, table default, not advertised to EBGP peer)
Not advertised to any peer
Refresh Epoch 1
655XX
10.255.X.9 (metric 3) from 10.255.X.9 (10.255.X.9)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: no-export
rx pathid: 0, tx pathid: 0x0

Some edge routers may have no visibility into the network they are connected to, but
should still be able to reach the loopback of any other edge router when forwarding
traffic into 65501.

CE-RTR-11#sh ip route bgp

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, \* - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route

18 / 89
 Advanced_Routing_Services_Lab_Documentation

- - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 198.51.100.X to network [Link]

B* [Link]/0 [20/0] via 198.51.100.X, 02:00:15

CE-RTR-11#ping 100.64.X.1 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.64.X.1, timeout is 2 seconds:
Packet sent with a source address of 100.64.X.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/28/34 ms

Some routers will have two routes for both networks that do not use BGP communities

CE-RTR-5#sh ip route bgp

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
- - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 198.51.100.X to network [Link]

B* [Link]/0 [20/0] via 198.51.100.X, 00:51:06

[Link]/8 is variably subnetted, 4 subnets, 2 masks
B 100.64.X.0/24 [20/0] via 198.51.100.X, 00:51:41
B 100.64.X.0/24 [20/0] via 198.51.100.X, 00:51:41

Configuration Example
We can use ACL’s in combination with route maps to validate expected prefixes.

19 / 89
 Advanced_Routing_Services_Lab_Documentation

ip access-list standard bgp-198.51.100.X-in

permit 100.64.X.0 [Link]
!
route-map bgp-198.51.100.X-in permit 10
match ip address bgp-198.51.100.X-in
!
router bgp 65501
! neighbor 198.51.100.X route-map bgp-198.51.100.X-in in

We can utilize prefix lists to filter outbound routes to default only. Notice that we do not
need to utilize greater than or less than operators to accomplish this.

ip prefix-list default-only permit [Link]/0

!
router bgp 65501
neighbor 198.51.100.X prefix-list default-only out

We can use route-maps and BGP communities to prevent prefix advertisement outside
of an AS. Notice that we must both configure the edge router to send the community to
the upstream leaf router, and the leaf router to send the community to it’s iBGP peer
that provides connectivity to another AS.

20 / 89
 Advanced_Routing_Services_Lab_Documentation

CE-1
route-map no-export permit 10
set community no-export
!
router bgp 65520
neighbor 198.51.100.X send-community
neighbor 198.51.100.X route-map no-export out

LR-AR1-1
router bgp 65501
neighbor 10.255.X.9 send-community.

Section 3: Overlay Technologies - Enterprise

Progress Expectation
Before completing this section, you will have successfully advertised networks from CE
sites into the transit network using eBGP and controlled the receipt of prefixes from
downstream eBGP peers on PE routers. All CE sites can reach other CE sites using their
public loopback addresses. All PE routers advertise the necessary prefix information to
other provider routers, and only permit expected prefixes into the transport network.
o

Section Outline
In this section you will utilize IPsec to connect remote private subnets over a WAN. You
will first construct a site-to-site policy based tunnel to connect two remote networks.
You will then build a hub and spoke, routed IPsec topology, and use an IGP to advertise
reachability information to other peers.

Section 3.1: Policy Based IPSec Tunnels

Section Goal

21 / 89
 Advanced_Routing_Services_Lab_Documentation

Select two edge routers within the topology. Add network statements on each edge
router to advertise their 198.51.100.X/29 prefix. Modify the route maps of each
upstream leaf router to accept the new prefix. Validate that these prefixes have
propagated throughout the transport network. Validate connectivity between edge
routers via their 198.51.100.X/29 interfaces. Connect hosts to edge routers using /24
networks within the [Link]/8 space. Build a policy based IPSec tunnel between edge
routers that provides connectivity between end hosts. Send test traffic and validate host
to host connectivity via the tunnel. Validate IPSec security association.

Section Expectations
The Policy Based IPsec tunnel configurations will satisfy the following requirements

1. Two edge routers will advertise 198.51.100.X/29 prefixes using a network

statement
2. RFC1918 addresses will not be learned by the transport network.
3. Route maps on upstream edge routers will be modified to accept new prefixes
4. Each edge router will have a host connected to a 10.X.X.1/24 interface.
5. Each edge router will be configured to establish an IPsec tunnel using it’s
198.100.51.X/29 address as the source and the 198.51.100.X/29 address of the other
edge router as a peer.
6. Hosts behind each edge router will be reachable over ICMP via the tunnel.

22 / 89
 Advanced_Routing_Services_Lab_Documentation

Route Map Modification Theory

We need to modify the inbound route map for our downstream BGP neighbors so they
can advertise the prefixes of interfaces that will be used for IPSec tunnel peering. First
we can look at the route maps configured on our leaf router. We will be focusing on the
second route map in this output. We can see that this route map uses an access list to
match prefixes advertised by 198.51.100.X .

23 / 89
 Advanced_Routing_Services_Lab_Documentation

LR-AR1-1#sh route-map
route-map bgp-198.51.100.X-out, permit, sequence 10
Match clauses:
ip address (access-lists): bgp-198.51.100.X-out
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map bgp-198.51.100.X-in,permit, sequence 10
Match clauses:
i
p address (access-lists): bgp-198.51.100.X-in
Set clauses:
Policy routing matches: 0 packets, 0 bytes

We then need to look at the access list referenced in our inbound route map and create a
new match statement to accept the new prefix

LR-AR1-1#sh ip access-lists bgp-[Link]-in

Standard IP access list bgp-198.51.100.X-in
10 permit 100.64.X.0, wildcard bits [Link] (1 match)

We can add a new prefix to the route map by referencing the existing ACL, creating a
new ACE,
and incrementing the sequence number.

ip access-list standard bgp-198.51.100.X-in

20 permit 198.51.100.X [Link]

Once we modify our route map, we should validate that we are receiving the route from
our
customer edge router.

LR-AR1-1#sh ip bgp topo *

For address family: IPv4 Unicast
BGP table version is 12, local router ID is 10.255.X.7
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

24 / 89
 Advanced_Routing_Services_Lab_Documentation

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i [Link] 10.255.X.1 0 100 0 i
*> 100.64.X.0/24 198.51.100.X 0 0 65520 i
*>i 100.64.X.0/24 10.255.X.11 0 100 0 65503 i
*>i 100.64.X.0/24 10.255.X.9 0 100 0 65521 i
*>i 100.64.X.0/24 10.255.X.14 0 100 0 65504 i
r> 198.51.100.X/29 198.51.100.X 0 0 65520 i

Notice that the prefix is received, but we have some different flags under the route.
Looking at the flags we see that the route has been marked with ' rib failure '. Running
show ip bgp rib can give us more information.

LR-AR1-1#sh ip bgp rib

Network Next Hop RIB-failure RIB-NH Matches
198.51.100.X/29 198.51.100.X Higher admin distance n/a

BGP is not inserting the route into the routing table because there is already a route
with a higher administrative distance. lets run show ip route <prefix>

CE-RTR-1#sh ip route [Link] [Link]

Routing entry for [Link]/29
Known via "connected", distance 0, metric 0 (connected, via interface)
Advertised by bgp 65520
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/0
Route metric is 0, traffic share count is 1

Everything is actually working exactly as expected. BGP is learning our route, and it is
in the BGP topology. BGP is not inserting our route into the global RIB because there is a
route with a higher admin distance. When looking at the routing table, we see that this
prefix is available via a directly connected interface. Lets check BGP routes for an iBGP
neighbor and validate that the rest of the transport network knows how to reach our
prefix.

25 / 89
 Advanced_Routing_Services_Lab_Documentation

BR-4#sh ip route bgp

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 10.255.X.1 to network [Link]
B* [Link]/0 [200/0] via [Link], 00:33:38
[Link]/24 is subnetted, 4 subnets
B [Link] [200/0] via [Link], 00:33:43
B [Link] [200/0] via [Link], 00:33:43
B [Link] [200/0] via [Link], 00:33:43
B [Link] [200/0] via [Link], 00:33:43
[Link]/29 is subnetted, 1 subnets
B [Link] [200/0] via [Link], 00:12:54

Policy Based IPSec Configuration Theory

Before we stand up an IPSec tunnel, we need to do some planning. First we need to
gather some key information about the configuration, like peer ip addresses and the
networks that will be communicating via the tunnel. Then we need to make decisions
about some aspects of the configuration that will be shared between both peers, such as
the integrity and encryption methods. Determining all this information ahead of time
will result in less time spent troubleshooting the configuration if the tunnel fails to
establish.

For each configuration we need to identify a peer IP address, as well as the source and
destination networks to be protected over the tunnel.

We need to decide on a means to authenticate our peers on the other side. We can use a
preshared-key for this.

We also need to decide on a transform set. IPSec peers need to use the exact same
encryption and hashing methods on both sides of the tunnel to successfully pass traffic
back and forth. When negotiating a tunnel connection, peers offer combinations of
methods to encrypt traffic and validate the integrity of tunnel data to each other until

26 / 89
 Advanced_Routing_Services_Lab_Documentation

they find a method they both share; these offerings are called transform sets.

We are using ESP for this tunnel, SHA to ensure the integrity of the data that traverses
the tunnel, and AES to encrypt the payloads. This means our transform set will consist
of esp-sha-hmac and esp-aes.

This configuration demonstrates using Diffie-Hellman group 2 for PFS. PFS is a means
by which we protect the initial authorization key exchange during Phase-1 of the tunnel
from eavesdropping by attackers seeking to compromise the integrity of the tunnel. PFS
is not negotiated by default, and later show commands will show that PFS was not used
to negotiate the tunnel.

Now that we have all of this information we can begin to build out the configurations
for our tunnel. We start by creating a new ISAKMP policy on “CE-RTR-A” and setting
all of the tunnel configurations we decided on previously.

crypto isakmp policy 1

encryption aes
hash sha
authentication pre-share
group 2

We then define the key that will be used for our tunnel peer.

crypto isakmp key 0 qwe-123 address 198.51.100.B

Now it is time to define the transform set that will be offered to CE-RTR-B

crypto ipsec transform-set ipsec-transform-ceA-ceB esp-aes esp-sha-hmac

Next, we need to create a crypto map that defines what traffic should take the tunnel,
the peer that should be used for the traffic flow, and the transform set that should be
offered to the peer

We also need to create an access list that has our internal subnet as the source and the
remote subnet as the destination.

27 / 89
 Advanced_Routing_Services_Lab_Documentation

crypto map ipsec-crypto-ceA-ceB 10 ipsec-isakmp

set peer 198.51.100.B
set transform-set ipsec-transform-ceA-ceB
match address 100
access-list 100 permit ip 10.X.A.0 [Link] 10.X.B.0 [Link]

Finally, we need to apply the crypto map to our WAN facing interface and create a static
route for the remote subnet via that interface.

interface GigabitEthernet0/0
crypto map ipsec-crypto-ceA-ceB
ip route 10.X.B.0 [Link] <next-hop-of-outbound-interface>

Device Example
Before standing up the tunnel, pings from one host to another behind CE routers should
fail, because their addresses are not routable over the transit network.

/ # ping 10.A.X.10
PING 10.A.X.10 (10.A.X.10): 56 data bytes
--- 10.A.X.10 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss

Traffic from a local network to the remote network should initialize the tunnel if the
configuration was implemented successfully.

28 / 89
 Advanced_Routing_Services_Lab_Documentation

/ # ping 10.A.X.10
PING 10.A.X.10 (10.A.X.10): 56 data bytes
64 bytes from 10.A.X.10: seq=1 ttl=62 time=47.384 ms
64 bytes from 10.A.X.10: seq=2 ttl=62 time=24.917 ms
64 bytes from 10.A.X.10: seq=3 ttl=62 time=87.131 ms
64 bytes from 10.A.X.10: seq=4 ttl=62 time=213.148 ms
64 bytes from 10.A.X.10: seq=5 ttl=62 time=54.158 ms
64 bytes from 10.A.X.10: seq=6 ttl=62 time=44.556 ms
64 bytes from 10.A.X.10: seq=7 ttl=62 time=55.867 ms
64 bytes from 10.A.X.10: seq=8 ttl=62 time=61.939 ms
--- 10.A.X.10 ping statistics ---
9 packets transmitted, 8 packets received, 11% packet loss

As you can see, we lost one packet as the tunnel established, and after that our traffic
was successfully encapsulated and routed over the transport network.

We can validate our tunnel using the show crypto ipsec sa command.

CE-RTR-1#sh crypto ipsec sa

interface: GigabitEthernet0/0
Crypto map tag: ipsec-crypto-ceA-ceB, local addr 198.51.100.A
protected vrf: (none)
local ident (addr/mask/prot/port): (10.X.A.0/[Link]/0/0)
remote ident (addr/mask/prot/port): (10.X.B.0/[Link]/0/0)
current_peer 198.51.100.B port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 8, #pkts encrypt: 8, #pkts digest: 8
#pkts decaps: 8, #pkts decrypt: 8, #pkts verify: 8
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 198.51.100.A, remote crypto endpt.: 198.51.100.B
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
current outbound spi: 0x56768AEF(1450609391)
PFS (Y/N): N, DH group: none

This section is a representation of our configurations and the overall state of the tunnel.

29 / 89
 Advanced_Routing_Services_Lab_Documentation

interface: GigabitEthernet0/0
Crypto map tag: ipsec-crypto-ceA-ceB, local addr 198.51.100.a

shows us the egress interface of the tunnel.

local ident (addr/mask/prot/port): (10.X.A.0/[Link]/0/0)

remote ident (addr/mask/prot/port): (10.X.B.0/[Link]/0/0)
current_peer 198.51.100.B port 500

These are the remote and local networks who’s traffic will be encrypted and decrypted
by the tunnel, and the peer that we will be forwarding the tunneled traffic to.

#pkts encaps: 8, #pkts encrypt: 8, #pkts digest: 8

#pkts decaps: 8, #pkts decrypt: 8, #pkts verify: 8
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 198.51.100.A, remote crypto endpt.: 198.51.100.B
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0

Here we have interface and traffic statistics. If the tunnel has never been established,
you will see 0 packets. Our tunnel has a plaintext MTU and an IP MTU. The IP MTU is
derived from the MTU of the interface, this is the largest PDU our interface can forward.
Our plaintext MTU is equal to the interface MTU minus the 62 byte IPsec header. This
means any PDU larger than 1483 bytes could be fragmented or dropped.

inbound esp sas:

spi: 0x337464E7(863266023)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: SW:1, sibling_flags 80000040, crypto map: ipsec-crypto-ceA-ceB
sa timing: remaining key lifetime (k/sec): (4287805/3170)
IV size: 16 bytes
replay detection support: Y

30 / 89
 Advanced_Routing_Services_Lab_Documentation

Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x56768AEF(1450609391)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: SW:2, sibling_flags 80000040, crypto map: ipsec-crypto-ceA-ceB
sa timing: remaining key lifetime (k/sec): (4287805/3170)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:

This section provides information as to the state of the Security Associations, or SAs of
the tunnel. A site to site IPsec tunnel uses two SAs on either end, one for in and
outbound traffic. A functional tunnel should have two ACTIVE status SAs.

Section 3.2: Hub and Spoke IPSEC with IGP Routing.

Section Goal
Tear down the policy based tunnel from section 3.1. Designate 1 CE router as an IPSEC
hub. Designate 3 CE routers as IPSEC spokes. Configure two internal subnets on each CE
router. Configure a hub and spoke IPSEC topology using tunnel interfaces assigned to
the loopback of each router. Configure an IGP to advertise the reachability of internal
subnets via the loopback address. Validate hub to spoke connectivity for internal hosts.
Validate spoke to spoke connectivity for internal hosts. Choose a spoke to spoke traffic
flow and document the forwarding decisions made by transport and CE routers.

Section Expectations
1. PE routers connecting to CE routers will have their configuration modified to
allow for the advertisement of the CE /29 through either; advertising from CE and
modifying the inbound route-map, or redistribution into iBGP of the interface
connecting CE routers to the provider network.
2. A Hub router will be designated among four CE routers.
3. The Hub router will use a Virtual-Template to dynamically assign Access-

31 / 89
 Advanced_Routing_Services_Lab_Documentation

Interfaces to Spokes.
4. Spoke routers will initiate IPsec tunnels towards the Hub router. 5. The Hub router
will form EIGRP neighbor adjacencies with spoke routers.
5. Spoke routers will advertise two internal subnets to the hub router via EIGRP.
6. Hub routers will advertise all internal subnets to all spokes.
7. All spokes will have connectivity via the hub router.

Diagram: Advanced Routing and Services Section 3.2 - Hub and Spoke IPSec with IGP
Routing

Route Based IPsec Configuration Theory

In our previous example of IPsec, we used a site to site tunnel to connect two subnets
together over a public WAN. These types of tunnels work great for point to point
networks, where one or more networks at one site needs to reach one or more networks
at another site. However, when we start adding sites, managing our IPsec tunnel policy
becomes complex. One site may need to serve as transit for traffic between two remote
networks, creating complexity in the policies for local and remote subnets. Another
approach involves building a partial or full-mesh of point to point tunnels, creating
configuration and management complexity as the network scales.

We can utilize Virtual-Templates and an IGP over the tunnel to simplify multi-site
IPsec deployments. With this approach, a Hub router uses a Virtual-Template to create
dynamic tunnels for IPsec peers. All routers run an IGP that advertises the desired
subnets through tunnel interfaces. These tunnel interfaces utilize the IP address of a
loopback, and the outbound interface of the CE router as a source. When routers need to
forward a packet, they will utilize the tunnel interface as a next hop, encapsulate the
packet using IPsec, and forward the packet with the source address of the outbound
interface.

When a packet is received by the Hub, it will de-encapsulate the packet using the IPsec
SA formed when peering with the spoke (these SA’s are associated with the spoke
outbound interface). It will then consult it’s routing table and determine the next hop.
If the next hop is for one of it’s internal subnets, it will forward the packet natively. If
the destination address matches an EIGRP route learned via another IPsec peer, it will
re-encapsulate the packet using the peer SA and forward the packet down another
tunnel towards the peer. By utilizing this topology, we connect four sites and build only

32 / 89
 Advanced_Routing_Services_Lab_Documentation

three IPsec tunnels.

first we need to tear down our policy based tunnel

CE-RTR-1#sh run | b crypto

crypto isakmp policy 1 #
encr aes
authentication pre-share
group 2
crypto isakmp key ipsec-secret-key-ce1-ce8 address [Link] #
!
!
crypto ipsec transform-set ipsec-transform-ce1-ce8 esp-aes esp-sha-hmac #
mode tunnel
!
!
!
crypto map ipsec-crypto-ce1-ce-8 10 ipsec-isakmp #
set peer [Link]
set transform-set ipsec-transform-ce1-ce8
match address 100
!
!
!
!
!
interface Loopback0
ip address [Link] [Link]
!
interface GigabitEthernet0/0
ip address [Link] [Link]
duplex auto
speed auto
media-type rj45
crypto map ipsec-crypto-ce1-ce-8 #
!

these are the commands we need to remove

33 / 89
 Advanced_Routing_Services_Lab_Documentation

no crypto isakmp key ipsec-secret-key-ce1-ce8 address [Link]

no crypto ipsec transform-set ipsec-transform-ce1-ce8 esp-aes esp-sha-hmac
int g0/0
no crypto map ipsec-crypto-ce1-ce-8

we can validate there are no ISPEC SA's on CE-1

CE-RTR-1#sh crypto ipsec sa

No SAs found

Now we can build our hub router configuration. Since we will have multiple peers on
our hub
router, we will be using a keyring to manage our PSK's. We do this by creating a new key
ring,
and writing statements that identify our peers and desired auth.

crypto keyring IPSEC_KEYS

pre-shared-key address 198.51.100.B key ipsec-secret-key
pre-shared-key address 198.51.100.C key ipsec-secret-key
pre-shared-key address 198.51.100.D key ipsec-secret-key

We will create a phase 1 policy.

crypto isakmp policy 10

encryption aes
hash sha
group 2
authentication pre-share

And phase 2.

crypto ipsec transform-set VTI_TRANSFROM esp-aes esp-sha-hmac

mode tunnel

34 / 89
 Advanced_Routing_Services_Lab_Documentation

We will create an IPSEC profile.

crypto ipsec profile VTI_PROFILE

set transform-set VTI_TRANSFROM

Now we will create a virtual template. A virtual template allows us to define

configurations for virtual interfaces that can be created on-demand by the router.
When spoke routers initiate a tunnel towards the hub, the hub will create a virtual
interface using the IPsec profile we specified previously and use it to form a tunnel with
the spoke. We are using the ip unnumbered loopback 0 command to allow the tunnel to
use the loopback 0 interface IP address and configuration, which will be useful when
enabling EIGRP.

interface Virtual-Template 1 type tunnel

tunnel mode ipsec ipv4
ip unnumbered loopback 0
tunnel protection ipsec profile VTI_PROFILE

Finally, we will create an ISAKMP profile to set phase 1 information for our Virtual-
Template. We then tie this phase 1 information to our virtual template within the
ISAKMP profile config.

crypto isakmp profile VTI_ISAKMP

keyring IPSEC_KEYS
match identity address 198.51.100.B [Link]
match identity address 198.51.100.C [Link]
match identity address 198.51.100.D [Link]
virtual-template 1

The configurations from the perspective of a spoke are simpler. We just need to create
an IPsec policy, tie it to a tunnel interface, tie that tunnel interface to our loopback, and
source the tunnel from our WAN interface.

We need to define the hub as a peer and provide the PSK that will be used for tunnel
authentication.

35 / 89
 Advanced_Routing_Services_Lab_Documentation

crypto isakmp key ipsec-secret-key address 198.51.100.A

We use the same phase 1 and phase 2 policy and create a transform set to be used for the
tunnel.

crypto isakmp policy 10

encryption aes
hash sha
group 2
authentication pre-share
!
crypto ipsec transform-set VTI_TRANSFROM esp-aes esp-sha-hmac
mode tunnel

We also create an IPsec profile and associate our transform set with it.

crypto ipsec profile VTI_PROFILE

set transform-set VTI_TRANSFROM

We then create a tunnel interface and attach the ipsec profile, we specify the Hub as our
tunnel destination and our outbound interface as the source. We will take IP
information from the loopback.

interface tunnel 0
ip unnumbered loopback 0
tunnel source GigabitEthernet0/0
tunnel destination 198.51.100.A
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI_PROFILE
!

Once this has been implemented across the network we should have three ISAKMP SAs
on CE A.

36 / 89
 Advanced_Routing_Services_Lab_Documentation

CE-RTR-1#sh crypto isakmp sa

IPv4 Crypto ISAKMP SA
dst src state conn-id status
198.51.100.A 198.51.100.B QM_IDLE 1003 ACTIVE
198.51.100.A 198.51.100.D QM_IDLE 1001 ACTIVE
198.51.100.A 198.51.100.C QM_IDLE 1002 ACTIVE

We now need to enable EIGRP on each router and add network statements for the
loopback interface we have tied to the tunnel, as well as our local subnets. From the
perspective of CE-A this looks like:

router eigrp <asn>

network 100.64.X.1 [Link]
network 10.A.X.0 [Link]
network 10.A.Y.0 [Link]

Device Example
After a successful configuration, our hub should have a Virtual-Access interface in
up/up that shares the IP address of Loopback 0 and our Virtual-Template.

Interface IP-Address OK? Method Status Protocol

GigabitEthernet0/0 [Link] YES NVRAM up up
GigabitEthernet0/1 10.A.X.1 YES NVRAM up up
GigabitEthernet0/2 10.A.Y.1 YES NVRAM up up
GigabitEthernet0/3 unassigned YES NVRAM administratively down down
Loopback0 [Link] YES NVRAM up up
Virtual-Access1 [Link] YES unset up up
Virtual-Template1 [Link] YES unset up down

Our spoke should have a Tunnel0 interface in up/up.

37 / 89
 Advanced_Routing_Services_Lab_Documentation

E-RTR-7#sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 [Link] YES NVRAM up up
GigabitEthernet0/1 10.B.X.1 YES NVRAM up up
GigabitEthernet0/2 10.B.Y.1 YES manual up up
GigabitEthernet0/3 unassigned YES NVRAM administratively down down
Loopback0 [Link] YES NVRAM up up
Tunnel0 [Link] YES TFTP up up

Once we configure EIGRP, we should see new adjacencies form over the virtual-access
interfaces.

CE-RTR-1#
*Jul 8 17:08:15.757: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor [Link]
(Virtual-Access1) is up:
new adjacency

Once we have enabled EIGRP across all sites, we should see 9 EIGRP routes on CE-A, 1
for each site's loopback and 2 remote subnets.

CE-RTR-1#sh ip route eigrp

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is [Link] to network [Link]
[Link]/8 is variably subnetted, 11 subnets, 2 masks
D 10.B.X.0/24 [90/26880256] via [Link], 00:47:31, Virtual-Access1
D 10.B.Y.0/24 [90/26880256] via [Link], 00:51:00, Virtual-Access1
D 10.C.X.0/24 [90/26880256] via [Link], 00:43:58, Virtual-Access2
D 10.C.Y.0/24 [90/26880256] via [Link], 00:43:58, Virtual-Access2
D 10.D.X.0/24 [90/26880256] via [Link], 00:43:42, Virtual-Access3

38 / 89
 Advanced_Routing_Services_Lab_Documentation

D 10.D.Y.0/24 [90/26880256] via [Link], 00:00:48, Virtual-Access3

[Link]/8 is variably subnetted, 7 subnets, 2 masks
D [Link]/32 [90/27008000] via [Link], 00:52:29, Virtual-Access1
D [Link]/32 [90/27008000] via [Link], 00:43:58, Virtual-Access2
D [Link]/32 [90/27008000] via [Link], 00:43:42, Virtual-Access3

show crypto ipsec sa can tell us about the IPsec tunnel configuration that has been
generated for our Virtual-Access interfaces.

E-RTR-1#sh crypto ipsec sa

interface: Virtual-Access1
Crypto map tag: Virtual-Access1-head-0, local addr [Link]

protected vrf: (none)

local ident (addr/mask/prot/port): ([Link]/[Link]/0/0)
remote ident (addr/mask/prot/port): ([Link]/[Link]/0/0)
current_peer [Link] port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 1200, #pkts encrypt: 1200, #pkts digest: 1200
#pkts decaps: 851, #pkts decrypt: 851, #pkts verify: 851
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: [Link], remote crypto endpt.: [Link]

plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
current outbound spi: 0x82B58D0A(2192936202)
PFS (Y/N): N, DH group: none

inbound esp sas:

spi: 0xB098B8E2(2962798818)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 15, flow_id: SW:15, sibling_flags 80004040, crypto map: Virtual-
Access1-head-0
sa timing: remaining key lifetime (k/sec): (4266222/1525)
IV size: 16 bytes
replay detection support: Y

39 / 89
 Advanced_Routing_Services_Lab_Documentation

Status: ACTIVE(ACTIVE)

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x82B58D0A(2192936202)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 16, flow_id: SW:16, sibling_flags 80004040, crypto map: Virtual-
Access1-head-0
sa timing: remaining key lifetime (k/sec): (4266222/1525)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

outbound ah sas:

outbound pcp sas:

One of the key differences between this output and our previous tunnel is that each SA
references a dynamically created crypto map. Another difference is that, while our
policy based tunnel SA was tied to a physical egress interface, this SA is tied to a
Virtual-Access interface, while retaining the egress IP address as a source.

Section 4: Security, Access Control and NAT.

Progress Expectation
Before completing this section, you will have successfully built a hub and spoke
topology using IPsec and EIGRP to provide reachability to 8 remote networks at four
sites. All hosts behind CE routers can reach all other hosts.

Section Outline
In this section you will write security policies to enable desired traffic flows within the
network and restrict all other access. You will also provide connectivity to resources on
the public internet by configuring PAT at all sites. Each site will receive a new
management loopback in it’s private IP space, while public loopbacks will be secured to

40 / 89
 Advanced_Routing_Services_Lab_Documentation

only allow SSH from CE-A’s WAN facing address. Once connectivity is established,
iPerf3 will be downloaded onto all hosts.

Section 4.1 NAT

Section Goal
Provide connectivity to the public internet for hosts behind CE routers by configuring
Port
Address Translation using the CE egress interface. Validate that hosts at all four sites
can reach
[Link] and [Link] using ICMP. Validate that hosts can resolve DNS requests using either
[Link] or [Link] as a nameserver.

Section Expectations
1. Connectivity to the public internet will be established for hosts behind CE routers
by
configuring a NAT policy using Port Address Translation,

41 / 89
 Advanced_Routing_Services_Lab_Documentation

2. Each site will use the IP address of the egress interface for the NAT policy.
3. Once connectivity is established, iPerf3 will be downloaded across all hosts.
4. An Iperf3 test will be ran across the network between hosts at separate CE sites.

NAT/PAT Configuration Theory

The configurations for this section are very straightforward. First we need to create
matching statements for the traffic we want to NAT, and identify inside and outside
interfaces. We then need to enable PAT on our outbound interface
We need to create an Access-List to identify the networks we want to apply NAT to.
Since we only care about matching against source ip addresses for this NAT policy, we
can use a Standard access list. I am using a Standard named access list in these
configurations for added clarity.

ip access-list standard NAT_POOL

10 permit 10.A.X.0 [Link]
20 permit 10.A.Y.0 [Link]

We then need to identify the inside and outside interfaces that we want to be included
in the NAT configuration.

int g0/1
ip nat inside
!
int g0/2
ip nat inside
!
int g0/0
ip nat outside
!

Finally, we will initialize the configuration with the ip nat inside command. Our ACL is
the source list and G0/0 is the egress interface IP address that will be used for
translation purposes.

42 / 89
 Advanced_Routing_Services_Lab_Documentation

ip nat inside source list NAT_POOL interface G0/0 overload

Device Example
After a successful configuration, we should be able to ping [Link] from a host behind
any CE router.

/ # ping [Link]
PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: seq=0 ttl=107 time=73.981 ms
64 bytes from [Link]: seq=1 ttl=107 time=40.015 ms
64 bytes from [Link]: seq=2 ttl=107 time=212.349 ms
^C
--- [Link] ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss

If DNS has been configured correctly on the host, Iperf3 should download successfully.

# apk add iperf3

fetch [Link]
fetch [Link]
(1/1) Installing iperf3 (3.7-r0)
Executing [Link]
OK: 6 MiB in 15 packages

We can validate successful NAT translations, and look at the state of our translation
table by running show ip nat translations after connecting to a remote host.

CE-RTR-11#sh ip nat trans

Pro Inside global Inside local Outside local Outside global
tcp [Link]:37704 10.D.X.10:37704 [Link]:80 [Link]:80
udp [Link]:45939 10.D.X.10:45939 [Link]:53 [Link]:53

43 / 89
 Advanced_Routing_Services_Lab_Documentation

We can see in this output that two outbound connections were translated when we
installed IPerf, the first was a DNS request to [Link] to resolve the hostname dl-
[Link], the second was an HTTP connection to [Link], the alpine
package manager server, to download the IPerf package.
Once this process has been completed across two sites, we should be able to run an
Iperf test between two hosts.

# iperf3 -c 10.D.2.10
Connecting to host 10.D.Y.10, port 5201
[ 5] local 10.A.X.10 port 60532 connected to 10.D.Y.10 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 310 KBytes 2.54 Mbits/sec 0 40.6 KBytes
[ 5] 1.00-2.13 sec 0.00 Bytes 0.00 bits/sec 0 43.3 KBytes
[ 5] 2.13-3.00 sec 134 KBytes 1.26 Mbits/sec 0 46.0 KBytes
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 55.5 KBytes
[ 5] 4.00-5.00 sec 127 KBytes 1.04 Mbits/sec 0 69.0 KBytes
[ 5] 5.00-6.00 sec 191 KBytes 1.56 Mbits/sec 0 96.1 KBytes
[ 5] 6.00-7.13 sec 0.00 Bytes 0.00 bits/sec 0 107 KBytes
[ 5] 7.13-8.00 sec 254 KBytes 2.38 Mbits/sec 0 131 KBytes
[ 5] 8.00-9.14 sec 382 KBytes 2.74 Mbits/sec 0 154 KBytes
[ 5] 9.14-10.00 sec 0.00 Bytes 0.00 bits/sec 0 166 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.37 MBytes 1.15 Mbits/sec 0 sender
[ 5] 0.00-12.62 sec 652 KBytes 423 Kbits/sec receiver

Section 4.2: ACLs

Section Goal
Write security policy that only permits desired traffic flows to hosts within the overlay
network,
and allows for general HTTP and HTTPS connectivity to the public internet. Test
security policy
36
using Iperf running on application ports and validate rule hits on access-lists. For this
section,
assume that all security policy has already been implemented at the hub network, the

44 / 89
 Advanced_Routing_Services_Lab_Documentation

goal
should be to secure traffic to and from spoke networks.

Section Expectations
1. Hosts behind spoke routers should be able to connect to a host in the 10.A.Y.0 hub
network via SMTP.
2. Hosts behind spoke routers should be able to connect to a host in the 10.A.Y.0 hub
network via HTTPS.
3. Hosts behind spoke routers should be able to ping a host in the 10.A.Y.0 hub
network.
4. All hosts should have HTTP and HTTPS access to the internet.
5. All hosts should have DNS via the internet using [Link] as a nameserver.
6. Existing control plane traffic will be allowed
7. Traffic flows will be validated using Iperf3

Access Control List Configuration Theory

We need to write some access-lists to ensure only desired traffic flows are allowed
within the network. First we need to breakdown the requirements and understand the
policies we need to write, let's focus on flows from the perspective of a spoke.

8. All hosts should be able to connect to a server in hub network Y over

SMTP(25/585)
and HTTPS(443)
9. ICMP should be allowed between the management subnet at the hub and remote
subnets.
10. HTTP, HTTPS and DNS should be permitted over the internet.
11. All current control plane traffic should be allowed.
Lets first focus on requirements 1 and 2. We can simplify some of our ACL
configurations by using object groups as representations of multiple networks or
protocols. Let's define an object

45 / 89
 Advanced_Routing_Services_Lab_Documentation

group for our local subnets.

object-group network INTERNAL-HOSTS
10.D.X.0 [Link]
10.D.Y.0 [Link]
!

We can also create an object group for our server and supply a single address.

object-group network SERVER

host 10.A.X.10

We will create a third object group to represent the services we will be allowing to the
server.

object-group service SERVER-PORTS

tcp 443
tcp 587
tcp 25
!

With all this in place we can satisfy the requirements of item 1 with a single rule.

ip access-list extended VPN_POLICY_OUT

20 permit object-group SERVER-PORTS object-group INTERNAL-HOSTS object-group
SERVER
!

Let's take a closer look at the structure of this rule:

20 permit object-group SERVER-PORTS - This rule will apply to any packet with a
destination port
defined in SERVER-PORTS

object-group INTERNAL-HOSTS - Packets must have a source address specified in

INTERNAL-HOSTS

46 / 89
 Advanced_Routing_Services_Lab_Documentation

object-group SERVER - Packets must have a destination address specified in SERVER .

For item 2, we can define another object group, MGMT-SUBNET , and write an ACL to allow
ICMP between our internal networks and management.

object-group network `MGMT-SUBNET`

10.A.X.0 [Link]
!
ip access-list extended VPN_POLICY_OUT
30 permit icmp object-group INTERNAL-HOSTS object-group MGMT-NETWORK
!

One of the benefits of using object-groups within ACL’s is that, if our source or
destination addresses change, we can simply update the object group as opposed to
updating the rule. Now that items concerning VPN traffic are solved for, let's apply this
ACL to our tunnel interface.

interface tunnel 0
ip access-group VPN_POLICY_OUT out

When applying access-lists to interfaces we must specify a direction. As a general rule

of thumb, if source addresses are behind the interface we are placing the ACL on, we
should apply the ACL in the outbound direction. If destination networks in the
matching statements are behind an interface, it should be applied in the inbound
direction.

47 / 89
 Advanced_Routing_Services_Lab_Documentation

To satisfy requirement 3, we need to write rules for the WAN interface.

These rules can be a bit simpler, since we can expect a multitude of addresses to be
accessed over the internet, we can use "any any" rules and just specify application
ports for web traffic.

ip access-list extended WAN_INTERFACE_OUT

20 permit tcp any any eq 80
30 permit tcp any any eq 443
!

We can be more specific with DNS.

48 / 89
 Advanced_Routing_Services_Lab_Documentation

40 permit udp any host [Link] eq 53

!

We can apply this ACL to our egress interface in the outbound direction.

interface GigabitEthernet0/0
ip access-group WAN_INTERFACE_OUT out
!

We can write inbound ACL's to control traffic destined to our networks or networks
behind it. It is important to remember that you will not be able to be as specific with
some application ports when writing stateless policy for inbound flows. In most client
server flows, the client uses an application port as a destination, but uses an ephemeral
or random port as a source. This means that if you allow only port 80 on both sides on
an interface for a specific traffic flow, it will break bi-directional communication, as
the return traffic will not be on port 80. This means for an ACL matching web traffic, we
can only permit TCP generally inbound. We would then need to deny other protocols
that run on TCP that we do not want to allow into our network, like SSH and Telnet.
It is also important to note that while outbound ACL's do not match on control plane
traffic generated by the network device, inbound ACL's will match on control plane
traffic destined to the interface or addresses behind it. It is important to understand
what protocols and network services are running before configuring any ACL.

ip access-list extended WAN_INTERFACE_IN

10 permit esp host 198.51.100.A host 198.51.100.D
11 permit udp host 198.51.100.A host 198.51.100.D eq 500
20 permit tcp host [BGP-peer] host 198.51.100.D eq 179
30 permit tcp host [BGP-peer] host 198.51.100.D
48 deny tcp any any eq telnet
49 deny tcp any any eq 22
50 permit tcp any any
70 permit icmp any any
80 permit udp host [Link] any

49 / 89
 Advanced_Routing_Services_Lab_Documentation

In this example ACL, we have BGP and an IPsec tunnel running to our interface so we
need to permit ESP, ISAKMP and TCP 179 inbound. To handle return web traffic, we
first deny any 40 protocols we do not want to allow in, and then allow TCP generally.
I'm also allowing ICMP for troubleshooting purposes.
We don't have to permit any of the traffic flows that will be riding the tunnel since they
are encapsulated with ESP and will not be inspected, permitting ESP will allow all
traffic that passes the rules of the tunnel interface to traverse the tunnel. At the end we
allow UDP traffic from Google DNS.

Device Example
After successful policy configuration, you should be able to establish iperf sessions on
application ports defined in the section requirements to a host in 10.A.Y.0/24

iperf3 -c 10.A.X.10 -p 443

Connecting to host 10.A.X.10, port 443
[ 5] local 10.A.1.10 port 58636 connected to 10.D.X.10 port 443
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.11 sec 84.8 KBytes 629 Kbits/sec 23 9.47 KBytes
[ 5] 1.11-2.00 sec 0.00 Bytes 0.00 bits/sec 2 9.47 KBytes
[ 5] 2.00-3.01 sec 0.00 Bytes 0.00 bits/sec 0 12.2 KBytes
[ 5] 3.01-4.03 sec 0.00 Bytes 0.00 bits/sec 0 14.9 KBytes
[ 5] 4.03-5.00 sec 44.1 KBytes 373 Kbits/sec 0 21.7 KBytes
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 32.5 KBytes
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 36.5 KBytes
[ 5] 7.00-8.06 sec 257 KBytes 1.99 Mbits/sec 0 52.8 KBytes
[ 5] 8.06-9.00 sec 191 KBytes 1.66 Mbits/sec 0 74.4 KBytes
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 78.5 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 577 KBytes 473 Kbits/sec 25 sender
[ 5] 0.00-11.03 sec 241 KBytes 179 Kbits/sec receiver
iperf Done.
#

# iperf3 -c 10.A.X.10 -p 587

Connecting to host 10.A.X.10, port 587
[ 5] local 10.B.X.10 port 42434 connected to 10.A.X.10 port 587

50 / 89
 Advanced_Routing_Services_Lab_Documentation

[ ID] Interval Transfer Bitrate Retr Cwnd

[ 5] 0.00-1.00 sec 81.2 KBytes 665 Kbits/sec 0 39.3 KBytes
[ 5] 1.00-2.08 sec 234 KBytes 1.78 Mbits/sec 0 40.6 KBytes
[ 5] 2.08-3.05 sec 0.00 Bytes 0.00 bits/sec 0 43.3 KBytes
[ 5] 3.05-4.00 sec 133 KBytes 1.15 Mbits/sec 0 50.1 KBytes
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 60.9 KBytes
[ 5] 5.00-6.00 sec 191 KBytes 1.56 Mbits/sec 0 78.5 KBytes
[ 5] 6.00-7.02 sec 254 KBytes 2.04 Mbits/sec 0 114 KBytes
[ 5] 7.02-8.00 sec 0.00 Bytes 0.00 bits/sec 0 120 KBytes
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 125 KBytes
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 143 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 893 KBytes 732 Kbits/sec 0 sender
[ 5] 0.00-13.04 sec 506 KBytes 318 Kbits/sec receiver
iperf Done.

Standard Iperf3 tests should fail since the default port is not included within our
policies.

# iperf3 -c 10.A.2.10
iperf3: error - unable to connect to server: Host is unreachable
#

We can validate that we are getting hits on access rules using show ip access-lists

CE-RTR-D#sh ip access-lists
Standard IP access list NAT_POOL
10 permit 10.D.X.0, wildcard bits [Link] (3 matches)
20 permit 10.D.Y.0, wildcard bits [Link]
Extended IP access list VPN_POLICY_IN
10 permit eigrp any any (688 matches)
20 permit tcp object-group REMOTE-HOSTS object-group INTERNAL-HOSTS (721 matches)
30 permit icmp object-group MGMT-NETWORK object-group INTERNAL-HOSTS
Extended IP access list VPN_POLICY_OUT
10 permit object-group SERVER-PORTS object-group INTERNAL-HOSTS object-group SERVER
(895 matches)
20 permit icmp object-group INTERNAL-HOSTS object-group MGMT-NETWORK
Extended IP access list WAN_INTERFACE_IN

51 / 89
 Advanced_Routing_Services_Lab_Documentation

10 permit esp host 198.51.100.A host [Link] (2832 matches)

11 permit udp host 198.51.100.A host [Link] eq isakmp (12 matches)
20 permit tcp host [BGP-peer] host [Link] eq bgp (397 matches)
30 permit tcp host [BGP-peer] host [Link]
48 deny tcp any any eq telnet
49 deny tcp any any eq 22
50 permit tcp any any
70 permit icmp any any (5 matches)
80 permit udp host [Link] any (8 matches)
Extended IP access list WAN_INTERFACE_OUT
10 permit tcp any any eq 443
20 permit tcp any any eq www (796 matches)
30 permit udp any host [Link] eq domain (4 matches)
40 permit icmp any any

If you have had to reinstall iperf after enabling your access policies, you will see
outbound hits on HTTP rules to the internet. If you would like to test HTTPS, first
install curl, then curl an HTTPS URL like [Link]

# apk add curl

(1/4) Installing ca-certificates (20191127-r2)
(2/4) Installing nghttp2-libs (1.40.0-r1)
(3/4) Installing libcurl (7.67.0-r0)
(4/4) Installing curl (7.67.0-r0)
Executing [Link]
Executing [Link]
OK: 8 MiB in 19 packages
/ # curl [Link]
<!doctype html>
<html>
<head>
<title>Example Domain</title>
Re-checking the ACL will show hits matching on 443.
CE-RTR-D#sh ip access-lists WAN_INTERFACE_OUT
Extended IP access list WAN_INTERFACE_OUT
10 permit tcp any any eq 443 (20 matches)
20 permit tcp any any eq www (1067 matches)
30 permit udp any host [Link] eq domain (8 matches)
40 permit icmp any any

52 / 89
 Advanced_Routing_Services_Lab_Documentation

Section 4.3: Securing the Management Plane.

Section Goal
Create a new loopback interface on spoke routers and advertise it into the EIGRP
routing domain. Generate necessary configurations to enable SSH access to spoke
routers. Update existing security policy to allow management to spoke routers from
both inside and outside the IPsec tunnel. Ensure that local attempts to access the
management loopback fail. Validate that management failover is working correctly by
downing an IPsec tunnel and successfully bringing it back up via an ssh connection to
the public loopback.

Section Expectations
12. SSH will only be allowed via the tunnel to the management loopback from source
addresses in 10.A.X.0/24.
13. In the event of a down tunnel, spoke routers can be managed via their public
loopback.
43
14. SSH will only be allowed from the public internet via the IP address of the hub
network
public interface.
15. SSH connections attempting to terminate on a spoke router public physical
interface will
fail.

Management Plane Security Theory

We are going to enable management access to our routers from inside and outside the
overlay. First we need to configure our hub routers for SSH access
We need to define a domain name, and generate a key pair

ip domain-name [Link]
crypto key generate rsa modulus 2048
!

53 / 89
 Advanced_Routing_Services_Lab_Documentation

We need to create a user account to authenticate against, enable ssh on our virtual
terminal and use the local database for authentication.

username admin privilege 15 secret admin

!
line vty 0 5
transport input ssh
login local

We are going to create a new management loopback address and advertise it to the hub
router using EIGRP

int loop 1
ip addr 10.B.99.1 [Link]
!
router eigrp 100
network 10.B.99.1 [Link]
!

We now need to ensure that only hosts with a source address in the management
subnet can SSH to our management IP address. Since we are only concerned with
source addresses here, we can use a standard ACL.

ip access-list standard ALLOW_MGMT

10 permit 10.A.X.0 [Link]
!

Note: We can not use object groups with standard ACL's.

Now we can apply our rules in-bound within our VTY configuration.

line vty 0 5
access-class ALLOW_MGMT in
!

54 / 89
 Advanced_Routing_Services_Lab_Documentation

We still need to open up the rules on the tunnel to allow SSH to the loopback address.
Show ip access-list can be used to get the current state of your ACL entries. Ensure that
you are inserting your rules in such a way that they are not skipped by matching an
earlier deny. We can be very specific with this rule as we only want to permit in-bound
ssh and outbound TCP to our management IP address from our management network.

ip access-list extended VPN_POLICY_IN

40 permit tcp object-group MGMT-NETWORK host 10.B.99.1 eq 22
!
ip access-list extended VPN_POLICY_OUT
30 permit tcp host 10.B.99.1 object-group MGMT-NETWORK

Lets also add the loopback to the INTERNAL-HOSTS object group so it will be included
in the management subnet to internal hosts ICMP policy.

object-group network INTERNAL-HOSTS

host 10.B.99.1

We also need to allow ssh only from the public address of our hub, so we can manage
our spoke in the event that we lose IPsec. We need to add a permit statement that allows
SSH only from the public IP address of our spoke router to our public loopback.

ip access-list extended WAN_INTERFACE_IN

45 permit tcp host 198.51.100.A host 100.64.X.1 eq 22
!
ip access-list extended WAN_INTERFACE_OUT
45 permit tcp host 100.64.X.1 host 198.51.100.A
!
Finally, lets add the hub public interface to the VTY ACL
ip access-list standard ALLOW_MGMT
20 permit 198.51.100.A [Link]

Let’s test out our policies by connecting to our management loopback via SSH from our
host in the management network. You will likely need to install openssh on the
container first. apk add openssh

55 / 89
 Advanced_Routing_Services_Lab_Documentation

# ssh admin@10.D.99.1
The authenticity of host '10.B.99.1 (10.B.99.1)' can't be established.
RSA key fingerprint is SHA256:5HemCq1+vg2xjh52ZBLRQf+xMsEH8+WJEuQXBS65YwU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.B.99.1' (RSA) to the list of known hosts.
Password:
CE-RTR-D#

Management via the tunnel is looking good. Let’s simulate an IPsec outage by shutting
the tunnel interface on a spoke. Here’s what we will see on the hub.

*Jul 14 18:08:52.294: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-

Access3, changed state to
down
*Jul 14 18:08:52.343: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 100.64.B.1
(Virtual-Access3) is down:
interface down

We've lost all our internal routes to the spoke, so if we want to troubleshoot we will
have to ssh at the public loopback.

# ssh admin@100.64.D.1
The authenticity of host '100.64.D.1 (100.64.D.1)' can't be established.
RSA key fingerprint is SHA256:5HemCq1+vg2xjh52ZBLRQf+xMsEH8+WJEuQXBS65YwU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '100.64.D.1' (RSA) to the list of known hosts.
Password:
CE-RTR-D#

It looks like our configuration is working, let’s validate we are getting hits on the right
policies just to be sure.

CE-RTR-D#sh ip access-lists
Standard IP access list ALLOW_MGMT
20 permit 198.51.100.A (6 matches)

56 / 89
 Advanced_Routing_Services_Lab_Documentation

10 permit 10.A.X.0, wildcard bits [Link] (6 matches)

Standard IP access list NAT_POOL
10 permit 10.D.X.0, wildcard bits [Link] (7 matches)
20 permit 10.D.Y.0, wildcard bits [Link]
Extended IP access list VPN_POLICY_IN
10 permit eigrp any any (2078 matches)
20 permit tcp object-group REMOTE-HOSTS object-group INTERNAL-HOSTS (793 matches)
30 permit icmp object-group MGMT-NETWORK object-group INTERNAL-HOSTS (3 matches)
40 permit tcp object-group MGMT-NETWORK host [Link] eq 22
Extended IP access list VPN_POLICY_OUT
10 permit object-group SERVER-PORTS object-group INTERNAL-HOSTS object-group SERVER
(895 matches)
20 permit icmp object-group INTERNAL-HOSTS object-group MGMT-NETWORK
30 permit tcp host [Link] object-group MGMT-NETWORK
Extended IP access list WAN_INTERFACE_IN
10 permit esp host 198.51.100.A host 198.51.100.D (2906 matches)
11 permit udp host 198.51.100.A host 198.51.100.D eq isakmp (17 matches)
20 permit tcp host [BGP-peer] host 198.51.100.D eq bgp (409 matches)
30 permit tcp host [BGP-peer] host [Link]
45 permit tcp host 198.51.100.A host 100.64.D.1 eq 22 (192 matches)
48 deny tcp any any eq telnet
49 deny tcp any any eq 22
50 permit tcp any any
70 permit icmp any any (5 matches)
80 permit udp host [Link] any (8 matches)
Extended IP access list WAN_INTERFACE_OUT
10 permit tcp any any eq 443 (20 matches)
20 permit tcp any any eq www (1067 matches)
30 permit udp any host [Link] eq domain (8 matches)
40 permit icmp any any

Section 5: Service Provider Segmentation & Network

Virtualization
Progress Expectation

57 / 89
 Advanced_Routing_Services_Lab_Documentation

Before completing this section, you will have successfully built a hub and spoke
topology using IPsec and EIGRP to provide reachability to 8 remote networks at four
sites. Access policy has been written that permits desired traffic flows throughout the
network that uses object groups where possible to reduce the administrative overhead
of writing and updating policy.

Section Outline
In this section you will enable MPLS throughout the service provider network to extend
new services to customer routers and eliminate the need for BGP in the service provider
core. You will then configure a MPLS L3VPN to route private customer subnets over the
service provider transport network. Finally, you will use AToM to extend L2
connectivity between two customer sites, and use the new L2 connectivity to exchange
routes between the IPSEC and L3VPN network using OSPF.

Section 5.1: BGP Free Core/MPLS Backbone

Section Goal
Enable MPLS forwarding on all interfaces within the transport network aside from
customer-facing interfaces. Validate that routers have formed MPLS adjacencies and
constructed an MPLS forwarding table. Migrate core routers off of BGP while validating
reachability throughout the network.

Section Expectations
All core router interfaces should participate in MPLS
All provider edge router interfaces that do not connect to customers should participate
in MPLS
All provider edge routers will maintain an iBGP neighborship with internet edge.
All provider edge routers will maintain an iBGP neighborship with each other.

58 / 89
 Advanced_Routing_Services_Lab_Documentation

MPLS Configuration Theory

MPLS at its core is a network virtualization technology. MPLS allows us to support
multiple network topologies and protocols using the same data plane, without
requiring direct support for a particular topology or protocol throughout the network.

We accomplish this by adding an MPLS label to every packet between the L2 and L3
headers before forwarding it to other MPLS routers. At each hop, the MPLS label in the
packet header will be swapped with a new label relevant to the next router who will be
forwarding the packet. The path a packet takes within the MPLS network is referred to

59 / 89
 Advanced_Routing_Services_Lab_Documentation

as the Label Switched Path.

Because these labels are the only things needed to forward a packet from one edge of an
MPLS network to another, complex topologies and services can be offered with little to
no configuration change within the transport core.

By using MPLS we can do things like; extend L2 connectivity across a L3 network, build
private customer routing tables across a WAN, or tunnel non IP traffic across an IP
network.

We first need to enable MPLS throughout the network. We can enable MPLS forwarding
per interface with:

Interface <interface_id>
mpls ip

Once MPLS has been enabled throughout the network, routers will generate MPLS
labels for all prefixes in the routing table. Routers will then share labels with one
another until an MPLS forwarding table converges. Once this has been accomplished, a
few things will happen:

1. Edge routers will generate an MPLS label for the loopback addresses of all transit
routers participating in OSPF.
2. These loopback addresses also serve as the next hop for all prefixes learned via
BGP, including the default route to the public internet.
3. Edge routers will add an MPLS label to all traffic destined for other edge routers or
the internet.
4. Core routers will stop consulting the RIB when forwarding traffic and will label
switch packets based on the MPLS Label Forwarding Information Base, or LFIB.

We need to validate that MPLS labels have been generated for all loopbacks within the
transport network. To do this, we can do:
sh mpls ldp bindings

BR-3#sh mpls ldp bindings

lib entry: [Link]/0, rev 70
remote binding: lsr: [Link]:0, label: imp-null

60 / 89
 Advanced_Routing_Services_Lab_Documentation

lib entry: [Link]/32, rev 66

local binding: label: 30
remote binding: lsr: [Link]:0, label: 33
remote binding: lsr: [Link]:0, label: 26
remote binding: lsr: [Link]:0, label: imp-null
remote binding: lsr: [Link]:0, label: 32
remote binding: lsr: [Link]:0, label: 26
remote binding: lsr: [Link]:0, label: 31
remote binding: lsr: [Link]:0, label: 27
remote binding: lsr: [Link]:0, label: 27
remote binding: lsr: [Link]:0, label: 30
lib entry: [Link]/32, rev 30

This is similar to a show <protocol> topology/database type command, and shows you the
label information that has been exchanged for this particular prefix. I’ve removed some
output here so we can focus on the loopback address for this particular edge router. To
view the actual MPLS labels this router will use for forwarding, we can use

show mpls forwarding-table

BR-3# sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label [Link]/32 0 Gi0/0 10.X.1.6
Pop Label [Link]/32 2030 Gi0/6 10.X.1.26
17 Pop Label [Link]/32 5452 Gi0/0 10.X.1.5
18 Pop Label [Link]/32 3480 Gi0/0 10.X.1.3
19 Pop Label [Link]/32 0 Gi0/0 10.X.1.2
Pop Label [Link]/32 0 Gi0/5 10.X.1.17
20 Pop Label 10.X.1.12/30 0 Gi0/0 10.X.1.1
Pop Label 10.X.1.12/30 0 Gi0/0 10.X.1.3
21 Pop Label 10.X.1.8/30 0 Gi0/0 10.X.1.1
Pop Label 10.X.1.8/30 0 Gi0/0 10.X.1.2
Pop Label 10.X.1.8/30 0 Gi0/5 10.X.1.17
22 Pop Label 10.X.1.32/30 0 Gi0/0 10.X.1.3
Pop Label 10.X.1.32/30 0 Gi0/0 10.X.1.5
23 Pop Label 10.X.1.28/30 0 Gi0/0 10.X.1.5
Pop Label 10.X.1.28/30 0 Gi0/0 10.X.1.6
Pop Label 10.X.1.28/30 0 Gi0/6 10.X.1.26
24 Pop Label 10.X.1.160/27 0 Gi0/0 10.X.1.3

61 / 89
 Advanced_Routing_Services_Lab_Documentation

Pop Label 10.X.1.160/27 0 Gi0/0 10.X.1.5

25 Pop Label 10.X.1.128/27 0 Gi0/0 10.X.1.5
Pop Label 10.X.1.128/27 0 Gi0/0 10.X.1.6
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
Pop Label 10.X.1.128/27 0 Gi0/6 10.X.1.26
26 Pop Label [Link]/32 13701 Gi0/1 10.X.1.74
27 Pop Label 10.X.1.80/30 0 Gi0/1 10.X.1.74
Pop Label 10.X.1.80/30 0 Gi0/2 10.X.1.78
28 Pop Label 10.X.1.68/30 0 Gi0/2 10.X.1.78
29 Pop Label 10.X.1.64/30 0 Gi0/1 10.X.1.74
30 Pop Label [Link]/32 2178 Gi0/0 10.X.1.1
31 Pop Label [Link]/24 0 Gi0/0 10.X.1.1
32 33 [Link]/32 0 Gi0/0 10.X.1.3
25 [Link]/32 2522 Gi0/0 10.X.1.5
33 19 [Link]/32 2550 Gi0/0 10.X.1.3
26 [Link]/32 0 Gi0/0 10.X.1.5
34 Pop Label [Link]/32 8310 Gi0/2 10.X.1.78
35 Pop Label [Link]/32 12479 Gi0/3 10.X.1.98
36 Pop Label 10.X.2.108/30 0 Gi0/3 10.X.1.98
37 Pop Label 10.X.1.112/30 0 Gi0/4 10.X.1.102
38 Pop Label 10.X.1.104/30 0 Gi0/3 10.X.1.98

Interpreting the first two lines of this output tells us that this router is directly
connected to [Link], as it will pop the MPLS label off the packet before forwarding.
This is called penultimate hop popping, and is done to save forwarding time for the last
hop router. 10.255.X.6 is reachable via G0/0 and G0/6, and routers should use label 16
when forwarding to traffic destined to 10.255.X.6 to BR-3.

Label generation and exchange should be validated across the transit network, and
once it is determined that all adjacent routers are LDP neighbors, and all labels have
been exchanged. BGP can be shut down on the core routers, specifically:

62 / 89
 Advanced_Routing_Services_Lab_Documentation

These routers, which only serve to provide transit connectivity in and out of the
backbone and be shut down.

BR-3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
BR-3(config)#no router bgp 65501
BR-3(config)#

After successfully shutting down BGP, ensure that core routers are only learning OSPF
routes.

BR-1#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

63 / 89
 Advanced_Routing_Services_Lab_Documentation

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, \* - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route

- - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set
[Link]/8 is variably subnetted, 37 subnets, 5 masks
O 10.X.1.0/26 is a summary, 00:58:17, Null0
[SOME OUTPUT OMMITED - TRANSPORT LINKS/CONNECTED NETWORKS]
[110/2] via 10.X.1.6, 00:57:31, GigabitEthernet0/0
[110/2] via 10.X.1.4, 00:57:21, GigabitEthernet0/0
O IA 10.X.1.128/27 [110/2] via 10.X.1.6, 00:57:31, GigabitEthernet0/0
[110/2] via 10.X.1.5, 00:57:31, GigabitEthernet0/0
O IA 10.X.1.160/27 [110/2] via 10.X.1.5, 00:57:31, GigabitEthernet0/0
[110/2] via 10.X.1.3, 00:57:31, GigabitEthernet0/0
O IA 10.X.2.108/30 [110/3] via 10.X.1.18, 00:56:54, GigabitEthernet0/3
[110/3] via 10.X.1.6, 00:56:53, GigabitEthernet0/0
[110/3] via 10.X.1.4, 00:56:54, GigabitEthernet0/0
O [Link]/32 [110/2] via 10.X.1.9, 00:57:21, GigabitEthernet0/4
[110/2] via 10.X.1.1, 00:57:21, GigabitEthernet0/0
C [Link]/32 is directly connected, Loopback0
O [Link]/32 [110/2] via 10.X.1.3, 00:57:31, GigabitEthernet0/0
O [Link]/32 [110/2] via 10.X.1.18, 00:57:31, GigabitEthernet0/3
[110/2] via 10.X.1.4, 00:57:21, GigabitEthernet0/0
O [Link]/32 [110/2] via 10.X.1.5, 00:57:31, GigabitEthernet0/0
O [Link]/32 [110/2] via 10.X.1.6, 00:57:31, GigabitEthernet0/0
O [Link]/32 [110/2] via 10.X.1.66, 00:57:21, GigabitEthernet0/1
O [Link]/32 [110/2] via 10.X.1.70, 00:57:21, GigabitEthernet0/2
O IA [Link]/32 [110/3] via 10.X.1.18, 00:56:54, GigabitEthernet0/3
[110/3] via 10.X.1.6, 00:56:53, GigabitEthernet0/0
[110/3] via 10.X.1.4, 00:56:54, GigabitEthernet0/0
O IA [Link]/32 [110/3] via 10.X.1.18, 00:55:52, GigabitEthernet0/3
[110/3] via 10.X.1.6, 00:56:02, GigabitEthernet0/0
[110/3] via 10.X.1.4, 00:55:52, GigabitEthernet0/0
O IA [Link]/32 [110/3] via 10.X.1.6, 00:55:25, GigabitEthernet0/0
[110/3] via 10.X.1.5, 00:55:38, GigabitEthernet0/0
O IA [Link]/32 [110/3] via 10.X.1.6, 00:56:14, GigabitEthernet0/0
[110/3] via 10.X.1.5, 00:56:06, GigabitEthernet0/0
O IA [Link]/32 [110/3] via 10.X.1.5, 00:57:21, GigabitEthernet0/0

64 / 89
 Advanced_Routing_Services_Lab_Documentation

[110/3] via 10.X.1.3, 00:57:21, GigabitEthernet0/0

O IA [Link]/32 [110/3] via 10.X.1.5, 00:57:21, GigabitEthernet0/0
[110/3] via 10.X.1.3, 00:57:20, GigabitEthernet0/0
O [Link]/24 [110/2] via 10.X.1.9, 00:57:21, GigabitEthernet0/4
[110/2] via 10.X.1.1, 00:57:21, GigabitEthernet0/0

We can see that BR only knows about directly connected networks and networks known
by OSPF. It does not even know a default route. As a final check, show ip route bgp
shows no output.

BR-1#sh ip route bgp

BR-1#

MPLS Configuration Validation

To test our new configuration, let’s send some test pings from one of our customer
edges to the internet.

Our pings will be natively forwarded from our edge router to LR-AR-1, from there LR-
AR-1 will consult its routing table to determine the next hop router for [Link]/0, which
in this topology will always be 10.255.X.1.

65 / 89
 Advanced_Routing_Services_Lab_Documentation

LR-AR1-1#sh ip route [Link]

Routing entry for [Link]/0, supernet
Known via "bgp 65501", distance 200, metric 0, candidate default path, type
internal
Last update from [Link] 01:04:40 ago
Routing Descriptor Blocks:
* [Link], from [Link], 01:04:40 ago

It will consult the MPLS forwarding table to determine which label it’s LDP neighbors
have generated for [Link], it then pushes this label onto the label stack, and
forwards it to either BR-1 or BR-3.

LR-AR1-1#sh mpls forwarding-table [Link]

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
31 32 [Link]/32 0 Gi0/0 10.X.1.65
30 [Link]/32 0 Gi0/1 10.X.1.73

Let’s assume that BR-1 receives the packet. Let’s take a look at what BR-1 will do when
it receives MPLS label 32.

BR-1#sh mpls forwarding-table labels 32

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
32 Pop Label [Link]/32 9627 Gi0/0 10.X.1.1
Pop Label [Link]/32 9856 Gi0/4 10.X.1.9

BR-1 knows it is the last hop before reaching 10.255.X.1, so it pops the label and
forwards it out of either G0/0 or G0/4, both directly connected interfaces to 10.255.X.1

From there, [Link], or our edge, will consult it’s IP routing table to determine where
the packet should be forwarded.

66 / 89
 Advanced_Routing_Services_Lab_Documentation

Core-Edge#sh ip route [Link]

Routing entry for [Link]/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Advertised by bgp 65501
Routing Descriptor Blocks:
* [Link]
Route metric is 0, traffic share count is 1

The packet gets forwarded natively out to the internet. The response returned will
require the edge router to consult it’s routing table for the destination network of our
customer edge.

Core-Edge#sh ip route 198.51.100.A

Routing entry for 198.51.100.A/29, 2 known subnets
B 198.51.100.A [200/0] via [Link], 01:11:12

It will then consult the MPLS forwarding table for the label for 10.255.X.7

Core-Edge#sh mpls forwarding-table [Link]

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
37 28 10.255.X.7/32 0 Gi0/1 10.X.1.2
26 10.255.X.7/32 0 Gi0/1 10.X.1.4
28 10.255.X.7/32 0 Gi0/2 10.X.1.10

Let’s assume that the edge router uses label 28 via G0/2, it’s directly connected link to
BR-1.

Let’s see what BR-1 does when it receives a packet with label 28.

BR-1#sh mpls forwarding-table labels 28

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
28 Pop Label 10.255.X.7/32 71960 Gi0/1 10.X.1.66

67 / 89
 Advanced_Routing_Services_Lab_Documentation

BR-1 is the last MPLS hop for this flow, so it pops the label and forwards the packet to
10.255.X.7, who in turn forwards it to our customer edge router.

Here is the successful ping from the perspective of our customer.

CE-RTR-1#ping [Link] source gigabitEthernet 0/0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
Packet sent with a source address of 198.51.100.A
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/45/64 m

This is the true power of MPLS. BR-1 can now forward traffic destined to any of our
customer edges or the internet without having any information in its RIB for how to
reach these networks.

Section 5.2: MPLS L3VPN

Section Goal
Configure an MPLS L3VPN between the four edge routers not currently participating in
the Hub and Spoke IPSEC network. Select two routers to be internet egress points
within the VPN, and configure two interfaces to the upstream provider network. One
interface should be configured as traditional internet, with a public address block
assigned, and a static default route to the provider router. The second interface will use
private addressing, and connect to the L3 VPN service. Configure a customer VRF on
each provider edge and define a route descriptor for VRF routes. Configure import and
export rules for this route descriptor within the VRF. Configure all provider edge
routers that will extend L3VPN service to activate the VPNv4 address family. Validate
that customers can exchange routes via BGP into the VPN and that connectivity is
established. Advertise a default route via the internet egress routers and configure NAT
policy so that outbound traffic via the egress routers uses egress router public IP
addressing. Utilize BGP to prefer default routes via different egress routers for the two
remaining sites. Perform failover testing between both internet egress routers by
shutting down the internet link and validating that sites take a new default route.

Section Expectations

68 / 89
 Advanced_Routing_Services_Lab_Documentation

The egress routers will utilize two separate links, one for internet traffic and one
for VPN traffic, the spoke routers will utilize only a VPN link
Customer private links should consist of /30’s in the [Link]/16 network.
All customer edge routers will use a different ASN.
All customer routers within the L3VPN will configure at least one host, and
advertise at least one host subnet into the VPN.
The internet egress routers will identify the source subnets used by all sites and
will configure NAT policy to translate internet bound traffic to its public IP
address.
BGP Policy coordination with service provider routers will be used to create path
diversity for internet-bound traffic.
Failover testing will be performed to validate that a new path will be selected
when default route failures are propagated into the VPN from an egress router.

L3VPN Configuration Theory

MPLS L3VPN uses VRF and a special BGP address family to create private customer
routing tables and route them over an L3 fabric.

The MPLS L3VPN requires a few components to function:

Each provider router needs to configure a VRF and place the customer link in the
VRF.

69 / 89
 Advanced_Routing_Services_Lab_Documentation

Each provider router needs to configure the VRF with a route descriptor, and to
export and import VRF routes of the same route descriptor using a route target.
Each provider router needs to activate the vpnv4 address family within the BGP
routing process for all peers who will be providing L3VPN service.
Each customer router needs to establish an eBGP session with the provider router,
and advertise subnets using BGP into the L3VPN.

When PE routers send customer traffic into the VPN, two labels will be pushed onto the
MPLS label stack, a VPN label, and a transport label. The transport label is the
outermost MPLS label, and is used for forwarding within the network core. From the
perspective of the local PE, this will be the label in the LFIB for the loopback address of
the remote PE. This label will be swapped by MPLS routers along the LSP until the
packet reaches the remote PE. The VPN label will sit below the transport label, and will
be popped by the remote PE when it receives the packet. The VPN label allows the
remote PE to select the proper customer VRF used to natively forward the packet along
to the customer.

Configuring Provider Edge routers.

First we need to create a VRF for our customer on our provider routers.

ip vrf vpn-customer-01
rd 655XX:X
route-target both 655XX:X

We then need to identify the customer facing interface, and place it in the VRF.

interface <interface_id>
ip vrf forwarding vpn-customer-01
ip addr 172.16.254.X [Link]

We then need to activate the VPNv4 address family for all peers that will be providing
VPN service.

70 / 89
 Advanced_Routing_Services_Lab_Documentation

router bgp 65501

address-family vpnv4
neighbor 10.255.0.B activate
neighbor 10.255.0.C activate
neighbor 10.255.0.D activate

LR-AR2-2(config-router-af)#
*Jul 20 19:29:01.820: %BGP-5-NBR_RESET: Neighbor [Link] reset (Capability
changed)
*Jul 20 19:29:01.845: %BGP-5-ADJCHANGE: neighbor [Link] Down Capability changed
*Jul 20 19:29:01.846: %BGP_SESSION-5-ADJCHANGE: neighbor [Link] IPv4 Unicast
topology base removed
from session Capability changed
*Jul 20 19:29:02.831: %BGP_SESSION-5-ADJCHANGE: neighbor [Link] VPNv4 Unicast
topology base removed
from session Capability changed
*Jul 20 19:29:02.835: %BGP-5-ADJCHANGE: neighbor [Link] Up

This will cause BGP to be reset between peers.

All provider edge routers will feature an identical configuration to activate the VPN.

Configuring Customer edge routers with BGP

Traditional BGP can be configured between customer and provider to advertise routes
into the VPN.

Configurations from the perspective of an internet egress router:

router bgp 655XX

network [Link]
network [Link].0.0 mask [Link]
neighbor 172.16.254.X remote-as 65501

Our internet routers also need some additional configuration, a NAT policy which will
translate all source IPs advertised into the VPN into the hub public ip address.

71 / 89
 Advanced_Routing_Services_Lab_Documentation

We need to identify the MPLS VPN interface and our host interface as NAT inside
interfaces.

interface GigabitEthernet0/0
ip address 172.16.254.X [Link]
ip nat inside

interface GigabitEthernet0/1
ip address [Link].0.1 [Link]
ip nat inside

We then need to identify our internet facing interface as the outside interface.

interface GigabitEthernet0/2
ip address 198.51.100.E [Link]
ip nat outside

We will define an access list to identify our source subnets

ip access-list standard MPLS-NAT

permit [Link].0.0 [Link]
permit [Link].0.0 [Link]
permit [Link].0.0 [Link]
permit [Link].0.0 [Link]
!

Finally, we will activate PAT on our internet facing interfaces.

ip nat inside source list MPLS-NAT interface GigabitEthernet0/2 overload

Tagging Default Routes with a BGP community

72 / 89
 Advanced_Routing_Services_Lab_Documentation

We can coordinate with our service provider edges and use BGP communities to
influence the PE routing table. Each PE router maintains a separate BGP table that
contains all the routes exchanged into the VPN. We can set a specific community on
default routes advertised into the VPN from different internet routers, and match on
that community to set the weight in the local routing table.

On our CE router, our route map needs two statements: A statement that matches our
default route and adds a standard community, and a statement that matches the host
subnets advertised into the VPN. We can define two prefix lists that describe the
subnets we are planning on advertising.

ip prefix-list DC_2_HOSTS seq 5 permit [Link].A.0/24

!
ip prefix-list DC_2_INT seq 10 permit [Link]/0
!

We can then create a single route map that tags the default route with a community and
simply matches and permits our other subnets.

route-map DC_2_INT_COMM permit 10

match ip address prefix-list DC_2_INT
set community 1000
!
route-map DC_2_INT_COMM permit 20
match ip address prefix-list DC_2_HOSTS
!

Finally, we can apply this route map to the PE neighbor and configure the BGP process
to send the community.

neighbor 172.16.254.A remote-as 65501

neighbor 172.16.254.A send-community standard
neighbor 172.16.254.A route-map DC_2_INT_COMM out

Applying routing policy based on communities for PE routers.

73 / 89
 Advanced_Routing_Services_Lab_Documentation

The PE router who receives community tagged routes will need to be configured to send
both standard and extended communities to the router who’s BGP table must be
manipulated. When activating the neighbor for the VPNv4, the send-community-
extended command is implemented by default, we must configure the sending of both
standard and extended communities manually.

neighbor 10.255.X.12 send-community both

The PE router who will be influencing default route selection needs two things: A
community list, and route map to match the community sent by the remote PE. The
route map will require two statements, one to match the community, and one to allow
routes not tagged by any community.

We define the community we are looking to match:

ip community-list 10 permit 1000

We then create a route-map that has two statements, one that matches the community
and one that matches all other routes advertised by the CE into the VPN. We can
accomplish the second requirement by matching the ASN of the advertising CE router.

route-map PREF_DC_2 permit 10

match community 10
set weight 200
!
route-map PREF_DC_2 permit 20
match source-protocol bgp <customer ASN>

L3VPN Verification
Once BGP is established between provider edge routers and customer edge routers, the
BGP table for the VPN can be viewed with:

show bgp vpnv4 unicast vrf <vrf-name>

74 / 89
 Advanced_Routing_Services_Lab_Documentation

LR-AR3-2#sh bgp vpnv4 unicast vrf vpn-customer-01

BGP table version is 44, local router ID is [Link]
Status codes: s suppressed, d damped, h history, \* valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 65570:1 (default for vrf vpn-customer-01)
* i [Link] [Link] 0 100 0 65570 i
*>i [Link] 0 100 200 65573 i
*>i [Link].0.0/24 [Link] 0 100 0 65570 i
*>i [Link].0.0/24 [Link] 0 100 0 65571 i
*> [Link].0.0/24 [Link] 0 0 65572 i
*>i [Link].0.0/24 [Link] 0 100 0 65573 i

We can see that all four customer subnets have been advertised into the VPN. We can
also see that two default routes have been advertised into the VPN. This is a router
where we are doing path manipulation, and we can see that we have set the default
route advertised from PE [Link] with a weight of 200 and selected it as the best
path.

CE-RTR-8#sh ip bgp topo *

For address family: IPv4 Unicast

BGP table version is 20, local router ID is [Link]

Status codes: s suppressed, d damped, h history, _ valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

*> [Link] [Link] 0 65501 65573 i
*> [Link].0.0/24 [Link] 0 65501 65570 i
Network Next Hop Metric LocPrf Weight Path
*> [Link].0.0/24 [Link] 0 65501 65571 i

75 / 89
 Advanced_Routing_Services_Lab_Documentation

*> [Link].0.0/24 [Link] 0 32768 i

*> [Link].0.0/24 [Link] 0 65501 65573 i
*> [Link]/32 [Link] 0 65501 65570 ?
*> [Link]/32 [Link] 0 65501 65570 ?
*> [Link]/32 [Link] 0 65501 65570 ?
*> [Link]/32 [Link]

From the perspective of the CE router, all paths are available via the PE. Default route
manipulation is not visible from the CE router.

Test pings should succeed between all hosts within the VPN.

AlpineLinux-9 console is now available... Press RETURN to get started.

# ifconfig
eth0 Link encap:Ethernet HWaddr 46:16:A6:EC:CC:E1
inet addr:[Link].0.10 Bcast:[Link] Mask:[Link]
inet6 addr: fe80::4416:a6ff:feec:cce1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:516 (516.0 B)

# ping [Link].0.10
PING [Link].0.10 ([Link].0.10): 56 data bytes
64 bytes from [Link].0.10: seq=0 ttl=59 time=570.566 ms
64 bytes from [Link].0.10: seq=1 ttl=59 time=156.791 ms

--- [Link].0.10 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 156.791/309.482/570.566 ms
# ping [Link].0.10
PING [Link].0.10 ([Link].0.10): 56 data bytes
64 bytes from [Link].0.10: seq=0 ttl=58 time=42.316 ms
64 bytes from [Link].0.10: seq=1 ttl=58 time=17.690 ms

--- [Link].0.10 ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 17.690/97.830/304.360 ms
# ping [Link].0.10

76 / 89
 Advanced_Routing_Services_Lab_Documentation

PING [Link].0.10 ([Link].0.10): 56 data bytes

64 bytes from [Link].0.10: seq=0 ttl=58 time=250.509 ms
64 bytes from [Link].0.10: seq=1 ttl=58 time=89.020 ms

Hosts within the VPN should have internet connectivity by forwarding traffic to
internet routers.

# ifconfig
eth0 Link encap:Ethernet HWaddr 26:CB:EA:17:E2:CE
inet addr:[Link].0.10 Bcast:[Link] Mask:[Link]
inet6 addr: fe80::24cb:eaff:fe17:e2ce/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:93 errors:0 dropped:64 overruns:0 frame:0
TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11831 (11.5 KiB) TX bytes:1454 (1.4 KiB)
# ping [Link]
PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: seq=0 ttl=101 time=226.312 ms
64 bytes from [Link]: seq=1 ttl=101 time=129.416 ms
64 bytes from [Link]: seq=2 ttl=101 time=193.458 ms
64 bytes from [Link]: seq=3 ttl=101 time=62.225 ms

We should be able to validate NAT translations for internet-bound traffic from our hub
router.

CE-RTR-4#sh ip nat translations

Pro Inside global Inside local Outside local Outside global
icmp [Link]:16128 [Link].0.10:16128 [Link]:16128 [Link]:16128

When tracing a route to the internet, hosts in non-internet sites should take diverse
paths, and use a different public IP address. I have configured [Link] as a loopback on
the core-edge router in the provider network for a quicker traceroute.

77 / 89
 Advanced_Routing_Services_Lab_Documentation

AlpineLinux-10 console is now available... Press RETURN to get started.

# traceroute [Link]
traceroute to [Link] ([Link]), 30 hops max, 46 byte packets
1 [Link].0.1 ([Link].0.1) 201.014 ms 13.801 ms 4.387 ms
2 [Link] ([Link]) 211.431 ms 10.554 ms 4.361 ms
3 10.X.1.101 (10.X.1.101) 135.768 ms 893.187 ms 362.510 ms
4 [Link] ([Link]) 27.526 ms 325.443 ms 49.729 ms
5 [Link] ([Link]) 40.922 ms 256.753 ms 89.981 ms
6 [Link] ([Link]) 753.724 ms 602.775 ms 173.193 ms
7 * * *
8 10.X.1.9 (10.X.1.9) 208.794 ms 1014.695 ms 355.129 ms
#

AlpineLinux-2 console is now available... Press RETURN to get started.

# traceroute [Link]
traceroute to [Link] ([Link]), 30 hops max, 46 byte packets
1 [Link].0.1 ([Link].0.1) 328.599 ms 59.070 ms 4.251 ms
2 [Link] ([Link]) 12.376 ms 44.684 ms 90.954 ms
3 10.X.1.129 (10.X.1.129) 61.501 ms 287.903 ms 387.174 ms
4 [Link] ([Link]) 69.148 ms 146.013 ms 696.046 ms
5 [Link] ([Link]) 323.546 ms 822.571 ms 579.647 ms
6 [Link] ([Link]) 270.662 ms 163.328 ms 144.782 ms
7 * * *
8 10.X.1.13 (10.X.1.13) 814.336 ms 500.170 ms 156.254 ms
#

Downing an interface on one of the routers advertising a default route into the VPN
should cause BGP tables for all routers to use the backup path, including the internet
egress router that experienced internet failure.

CE-RTR-12(config)#int g0/2
CE-RTR-12(config-if)#shutdown
CE-RTR-12(config-if)#
*Oct 8 19:25:22.312: %LINK-5-CHANGED: Interface GigabitEthernet0/2, changed state to
administratively
down

78 / 89
 Advanced_Routing_Services_Lab_Documentation

_Oct 8 19:25:23.315: %LINEPROTO-5-UPDOWN: Line protocol on Interface

GigabitEthernet0/2, changed state
to down
CE-RTR-12(config-if)#do sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF
external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, _ - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route

+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is [Link] to network [Link]

We can see that the default route is now the PE router. From the perspective of the PE
router performing path manipulation, the redundant internet path should be removed,
and the non-weighted path should take preference.

LR-AR3-2#sh bgp vpnv4 unicast vrf vpn-customer-01

BGP table version is 45, local router ID is [Link]
Status codes: s suppressed, d damped, h history, _ valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 65570:1 (default for vrf vpn-customer-01)
_>i [Link] [Link] 0 100 0 65570 i
_>i [Link].0.0/24 [Link] 0 100 0 65570 i
_>i [Link].0.0/24 [Link] 0 100 0 65571 i
_> [Link].0.0/24 [Link] 0 0 65572 i
_>i [Link].0.0/24 [Link] 0 100 0 65573 i

A traceroute from the same host who originally used the failed path should
automatically take a new path using the alternate internet router.

79 / 89
 Advanced_Routing_Services_Lab_Documentation

# traceroute [Link]
traceroute to [Link] ([Link]), 30 hops max, 46 byte packets
1 [Link].0.1 ([Link].0.1) 328.599 ms 59.070 ms 4.251 ms
2 [Link] ([Link]) 12.376 ms 44.684 ms 90.954 ms
3 10.X.1.129 (10.X.1.129) 61.501 ms 287.903 ms 387.174 ms
4 [Link] ([Link]) 69.148 ms 146.013 ms 696.046 ms
5 [Link] ([Link]) 323.546 ms 822.571 ms 579.647 ms
6 [Link] ([Link]) 270.662 ms 163.328 ms 144.782 ms
7 * * *
8 10.X.1.13 (10.X.1.13) 814.336 ms 500.170 ms 156.254 ms
# traceroute [Link]
traceroute to [Link] ([Link]), 30 hops max, 46 byte packets
1 [Link].0.1 ([Link].0.1) 15.071 ms 202.039 ms 298.292 ms
2 [Link] ([Link]) 62.157 ms 17.576 ms 358.618 ms
3 10.X.1.129 (10.X.1.129) 429.122 ms 211.830 ms 109.892 ms
4 10.X.1.4 (10.X.1.4) 269.552 ms 75.664 ms 624.871 ms
5 [Link] ([Link]) 26.703 ms 183.637 ms 80.170 ms
6 [Link] ([Link]) 370.722 ms 387.636 ms 683.058 ms
7 [Link] ([Link]) 516.944 ms 713.968 ms 607.993 ms
8 * * *
9 10.X.1.9 (10.X.1.9) 791.808 ms 667.321 ms 224.222 ms

Section 5.3: MPLS L2VPN

Section Goal:
Configure an L2VPN between the IPSEC hub router and the L3VPN hub router.
Configure OSPF between both routers. Redistribute the EIGRP subnets from the IPSEC
network and the BGP subnets from the L3VPN network into OSPF. Update security
policy within the IPSEC network to permit ICMP and MySQL from hosts within the
IPSEC network to hosts within the L3VPN network.

Section Expectations
A new link connecting each customer router to the provider network will be configured.
The L3VPN and IPSEC hubs will configure the interface connected to the new link with
an IP address in the same subnet.
Provider edge routers facilitating the VPN between both hubs will configure AToM
using the new link to extend layer 2 connectivity between both customers.

80 / 89
 Advanced_Routing_Services_Lab_Documentation

Customer edge routers will run OSPF over the L2VPN link and redistribute host
networks. IPSEC spoke policy will be updated to permit ICMP and MYSQL (3306) to
hosts in the L3VPN.

OSPF Configuration and protocol redistribution theory

We can prep the entire OSPF, security policy configuration, and protocol redistribution
before bringing up the new Virtual L2 link.

Let’s initialize the OSPF process

router ospf 2XX

We need to configure the new interfaces for our L2 VPN on each customer edge, we can
activate OSPF on these interfaces as well:

interface GigabitEthernet0/3
ip address [Link] [Link]
ip ospf 2XX area 0

On the IPsec hub, we need to mutually redistribute OSPF and EIGRP

81 / 89
 Advanced_Routing_Services_Lab_Documentation

On the IPsec hub, we need to mutually redistribute OSPF and EIGRP

Redistributing OSPF into EIGRP requires that we define the metrics that will be used for
the routes

router eigrp 100

redistribute ospf 200 metric 10000 100 255 1 1500

Redistributing EIGRP into OSPF just requires a redistribution command.

router ospf 200

redistribute eigrp 100 subnets

On our L3VPN hub, we need to mutually redistribute BGP and OSPF.

Redistributing BGP into OSPF only requires the default distribution command.

router ospf 200

redistribute bgp 65570 subnets

The OSPF subnets our router learns are learned as External Type-2 due to them being
redistributed into OSPF from EIGRP. The BGP redistribution command will only match
intra-area and inter-area (O, O IA) routes by default. To redistribute E2 routes, we will
need to utilize the match keyword.

router bgp 65570

redistribute ospf 200 match external 2

Access-list Modification Theory

On our IPSEC spoke routers, we need to add new entries to the inbound and
outbound IPSEC access policy.
First, we can define a new object group for our L3VPN subnets.

82 / 89
 Advanced_Routing_Services_Lab_Documentation

object-group network MSQL-SERVERS

[Link].0.0 [Link]
[Link].0.0 [Link]
[Link].0.0 [Link]
[Link].0.0 [Link]

We can also define the services our hosts can use to connect to the L3VPN hosts.

object group service SQL-SERVER-PORTS

icmp
tcp eq 3306

We then need to add a new entry in the outbound policy.

ip access-list extended VPN_POLiCY_OUT

40 permit object-group SQL-SERVER-PORTS object-group INTERNAL-HOSTS
object-group MSQL-SERVERS

For the inbound policy we will allow ICMP and all inbound TCP connections from the
SQL server group.

ip access-list extended VPN_POLICY_IN

50 permit icmp object-group MSQL-SERVERS object-group INTERNAL-HOSTS
60 permit tcp object-group MSQL-SERVERS object-group INTERNAL-HOSTS

This configuration must be mirrored across every IPSEC spoke

AToM Configuration Theory.

AToM stands for Any Transport over MPLS. AToM can be used to create a virtual cross
connect to tunnel ethernet traffic over a layer 3 network using a predefined MPLS label.

AToM is configured at the interface level. And requires defining the virtual circuit
endpoint IP address and MPLS label on both sides of the circuit.

83 / 89
 Advanced_Routing_Services_Lab_Documentation

interface <interface_id>
no ip address
xconnect 10.255.X.B <label> encapsulation mpls

AToM Validation
We can validate that our new virtual circuit is functional by running show mpls
l2transport vc
On our provider edges.

LR-AR1-2#sh mpls l2transport vc

Local intf Local circuit ID Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Gi0/5 Ethernet 10.255.X.A 13 UP

OSPF should establish between both neighbors once the VC has been established.

CE-RTR-4#
*Oct 4 22:55:42.366: %OSPF-5-ADJCHG: Process 200, Nbr [Link] on
GigabitEthernet0/3 from LOADING to
FULL, Loading Done
CE-RTR-4#

Our L3VPN hub should have OSPF routes for all the subnets within the IPSEC topology.

CE-RTR-4#sh ip route ospf

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, \_ - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR

84 / 89
 Advanced_Routing_Services_Lab_Documentation

Gateway of last resort is [Link] to network [Link]

[Link]/8 is variably subnetted, 11 subnets, 2 masks

O E2 10.A.X.0/24 [110/20] via [Link], 01:40:03, GigabitEthernet0/3
O E2 10.A.Y.0/24 [110/20] via [Link], 01:40:03, GigabitEthernet0/3
O E2 10.D.X.0/24 [110/20] via [Link], 00:05:38, GigabitEthernet0/3
O E2 10.D.Y.0/24 [110/20] via [Link], 00:05:38, GigabitEthernet0/3
[Link]/32 is subnetted, 2 subnets
O E2 [Link] [110/20] via [Link], 01:40:03, GigabitEthernet0/3
O E2 [Link] [110/20] via [Link], 00:05:38, GigabitEthernet0/3
CE-RTR-4#

Our IPSEC hub should have OSPF routes for all subnets within the L3VPN topology.

CE-RTR-1#sh ip route ospf

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, \* - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is [Link] to network [Link]

[Link]/8 is variably subnetted, 13 subnets, 2 masks

O E2 [Link].0.0/24 [110/1] via [Link], 00:01:54, GigabitEthernet0/3
O E2 [Link].0.0/24 [110/1] via [Link], 00:01:54, GigabitEthernet0/3
O E2 [Link].0.0/24 [110/1] via [Link], 00:01:54, GigabitEthernet0/3
O E2 [Link].0.0/24 [110/1] via [Link], 00:01:54, GigabitEthernet0/3
CE-RTR-1#

The IPSEC spokes should know about our L3VPN subnets via EIGRP.

CE-RTR-5#sh ip route eigrp

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

85 / 89
 Advanced_Routing_Services_Lab_Documentation

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, \* - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is [Link] to network [Link]

[Link]/8 is variably subnetted, 14 subnets, 2 masks

D 10.A.X.0/24 [90/26880256] via [Link], 00:08:09, Tunnel0
D 10.A.Y.0/24 [90/26880256] via [Link], 00:08:09, Tunnel0
D EX [Link]/24 [170/26905600] via [Link], 00:08:09, Tunnel0
D 10.D.X.0/24 [90/28160256] via [Link], 00:08:09, Tunnel0
D 10.D.Y.0/24 [90/28160256] via [Link], 00:08:09, Tunnel0
D EX [Link].0.0/24 [170/26905600] via [Link], 00:08:09, Tunnel0
D EX [Link].0.0/24 [170/26905600] via [Link], 00:08:09, Tunnel0
D EX [Link].0.0/24 [170/26905600] via [Link], 00:08:09, Tunnel0
D EX [Link].0.0/24 [170/26905600] via [Link], 00:08:09, Tunnel0
[Link]/8 is variably subnetted, 6 subnets, 2 masks
D [Link]/32 [90/27008000] via [Link], 00:08:09, Tunnel0
D [Link]/32 [90/28288000] via [Link], 00:08:09, Tunnel0

The L3VPN routers should know about our IPSEC subnets via BGP.

CE-RTR-6#sh ip route bgp

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, \* - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is [Link] to network [Link]

86 / 89
 Advanced_Routing_Services_Lab_Documentation

B* [Link]/0 [20/0] via [Link], 01:32:19

[Link]/8 is variably subnetted, 15 subnets, 2 masks
B 10.A.X.0/24 [20/0] via [Link], 00:15:38
B 10.A.Y.0/24 [20/0] via [Link], 00:15:38
B [Link]/24 [20/0] via [Link], 00:18:03
B 10.B.X.0/24 [20/0] via [Link], 00:10:27
B 10.B.Y.0/24 [20/0] via [Link], 00:10:27
B 10.C.X.0/24 [20/0] via [Link], 00:15:38
B 10.C.Y.0/24 [20/0] via [Link], 00:15:38
B [Link]/32 [20/0] via [Link], 00:15:38
B 10.D.X.0/24 [20/0] via [Link], 00:15:38
B 10.D.Y.0/24 [20/0] via [Link], 00:15:38
B [Link].0.0/24 [20/0] via [Link], 01:32:19
B [Link].0.0/24 [20/0] via [Link], 00:50:58
B [Link].0.0/24 [20/0] via [Link], 00:50:59
[Link]/32 is subnetted, 4 subnets
B [Link] [20/0] via [Link], 00:15:38
B [Link] [20/0] via [Link], 00:10:27
B [Link] [20/0] via [Link], 00:15:38
B [Link] [20/0] via [Link], 00:15:38

If our security policy has been updated successfully, we should have connectivity
between our L3VPN hosts and our IPSEC hosts.

# ifconfig
eth0 Link encap:Ethernet HWaddr 5A:E7:84:BA:CB:11
inet addr:10.C.X.10 Bcast:[Link] Mask:[Link]
inet6 addr: fe80::58e7:84ff:feba:cb11/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:74 (74.0 B) TX bytes:586 (586.0 B)

# ping [Link].0.10
PING [Link].0.10 ([Link].0.10): 56 data bytes
64 bytes from [Link].0.10: seq=0 ttl=56 time=369.486 ms
64 bytes from [Link].0.10: seq=1 ttl=56 time=317.073 ms
64 bytes from [Link].0.10: seq=2 ttl=56 time=845.465 ms
64 bytes from [Link].0.10: seq=3 ttl=56 time=851.060 ms

87 / 89
 Advanced_Routing_Services_Lab_Documentation

As seen previously, we can use iPerf to validate the TCP ports.

# iperf3 -c [Link].0.10 -p 3306

Connecting to host [Link].0.10, port 3306
[ 5] local 10.C.X.10 port 43160 connected to [Link].0.10 port 3306
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 84.8 KBytes 694 Kbits/sec 11 13.5 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 5 27.1 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 44.7 KBytes
[ 5] 3.00-4.08 sec 234 KBytes 1.78 Mbits/sec 0 44.7 KBytes
[ 5] 4.08-5.01 sec 0.00 Bytes 0.00 bits/sec 0 48.7 KBytes
[ 5] 5.01-6.22 sec 133 KBytes 901 Kbits/sec 0 62.3 KBytes
[ 5] 6.22-7.01 sec 0.00 Bytes 0.00 bits/sec 0 62.3 KBytes
[ 5] 7.01-8.02 sec 0.00 Bytes 0.00 bits/sec 0 69.0 KBytes
[ 5] 8.02-9.07 sec 0.00 Bytes 0.00 bits/sec 0 75.8 KBytes
[ 5] 9.07-10.20 sec 191 KBytes 1.38 Mbits/sec 0 96.1 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.20 sec 642 KBytes 515 Kbits/sec 16 sender
[ 5] 0.00-12.11 sec 268 KBytes 181 Kbits/sec receiver
iperf Done.

We can also validate that we are receiving hits on our ACLs

CE-RTR-5#sh ip access-lists
Standard IP access list ALLOW_MGMT
10 permit [Link]
20 permit 10.A.X.0, wildcard bits [Link]
Standard IP access list NAT_POOL
10 permit 10.C.X.0, wildcard bits [Link] (2 matches)
20 permit 10.C.Y.0, wildcard bits [Link]
Extended IP access list VPN_POLICY_IN
10 permit eigrp any any (286 matches)
20 permit tcp object-group REMOTE-HOSTS object-group INTERNAL-HOSTS
30 permit icmp object-group MGMT-NETWORK object-group INTERNAL-HOSTS
40 permit tcp object-group MGMT-NETWORK host [Link] eq 22
50 permit icmp object-group MSQL-SERVERS object-group INTERNAL-HOSTS (5 matches)
60 permit tcp object-group MSQL-SERVERS object-group INTERNAL-HOSTS (271
matches)

88 / 89
 Advanced_Routing_Services_Lab_Documentation

Extended IP access list VPN_POLICY_OUT

10 permit object-group SERVER-PORTS object-group INTERNAL-HOSTS object-group
SERVER
20 permit icmp object-group INTERNAL-HOSTS object-group MGMT-NETWORK
30 permit tcp host [Link] object-group MGMT-NETWORK
40 permit object-group SQL-SERVER-PORTS object-group INTERNAL-HOSTS object-group
MSQL-SERVERS (361 matches)

Conclusion
Congratulations on completing the lab. The network you have constructed has used
multiple overlay technologies, routing protocols and access policies to achieve our
primary goal as network engineers, providing access to resources. You have seen the
difference between building an overlay network over the public internet and using a
service provider VPN. You have learned how MPLS can be used to move traffic over an
overlay network, and how service providers use it to extend special means of
connectivity to customers. You have written basic policies to control access to a specific
resource, and updated those policies when new requirements are made on the network.

The lab does not need to stop here! There are many improvements or changes that can
be made to this network that you can research and consider implementing. Here are
some ideas to get you started:

Transitioning the iBGP service provider topology into a design that utilizes route
reflectors
Adding redundant connections at all sites for the internet
Improving the failover times in the service provider network
Adding security policy for the L3VPN network
Controlling the route redistribution between the the IPSEC network and the
L3VPN network to advertise only a specific subset of networks
Adding route tracking to the statically routed internet connections for automatic
failove

89 / 89