BGP Based Default Routing White-Paper PDF

AT&T Consulting Solutions, Inc.
BGP Based Default Routing

White Paper
(A Dynamic Routing Solution for Enterprise Networks with Multiple Internet POPs)
Author:
Brett M. Spunt, CCIE No.12745
Senior Consultant, AT&T Consulting, Inc.
brett.spunt@att.com
August 2nd, 2014
COPYRIGHT 2014 Brett M Spunt | AT&T Consulting, Inc. All rights reserved.
This document and the information it contains may not be distributed or disclosed outside AT&T Consulting, Inc. except upon written
permission from AT&T Consulting, Inc. or Brett M Spunt
Table of Contents
1 Solution Overview ................................................................................. 4
2 Configure .............................................................................................. 6
2.1 Lab Environment ................................................................................................. 6
2.1.1 Network Topology | Network Diagram .......................................................... 6
2.1.2 Network Diagram Analysis .............................................................................. 7
2.2 Edge Network Configuration .............................................................................. 9
2.2.1 Internet-facing-rt1 .......................................................................................... 9
Configuration ...................................................................................................... 9
Configuration Analysis ...................................................................................... 10
2.2.2 Edge-L3-core-sw1.......................................................................................... 13
Configuration .................................................................................................... 13
2.2.3 Firewall .......................................................................................................... 16
Configuration .................................................................................................... 16
2.2.4 Internet Service Provider Router .................................................................. 18
Configuration .................................................................................................... 18
2.3 Internal Network Configuration (LAN Core) ..................................................... 20
2.3.1 Internal-L3-core-sw1 ..................................................................................... 20
Configuration .................................................................................................... 20
2.4 Private WAN Network Configuration (Dual MPLS Providers) ........................... 25
2.4.1 AT&T (AVPN) WAN Router 1 ......................................................................... 25
Configuration .................................................................................................... 25
2.4.2 Verizon (VZB) WAN Router 2 ........................................................................ 30
Configuration .................................................................................................... 30
2.4.3 AT&T MPLS PE Router ................................................................................... 33
Configuration .................................................................................................... 33
2.4.4 Verizon MPLS PE Router ............................................................................... 35
Configuration .................................................................................................... 35
This document and the information it contains may not be distributed or disclosed outside AT&T Consulting, Inc. except upon
written permission from AT&T Consulting, Inc. or Brett M Spunt
2
3 Verify................................................................................................... 37
3.1 Validate Routing................................................................................................ 37
3.1.1 ISP Router...................................................................................................... 37
3.1.2 Internet-facing-rt1 ........................................................................................ 38
3.1.3 Edge-L3-core-sw1.......................................................................................... 39
3.1.4 FW1 ............................................................................................................... 40
3.1.5 Internal-L3-core-sw1 ..................................................................................... 40
3.1.6 AVPN-WAN-rt1.............................................................................................. 43
3.1.7 VZB-WAN-rt2................................................................................................. 46
3.1.8 AVPN PE Router ............................................................................................ 49
3.1.9 VZB PE Router ............................................................................................... 51
3.2 Test The Solution (Failover and Fallback) ......................................................... 52
3.2.1 Test Connectivity to the Internet .................................................................. 52
3.2.2 Failover from ISP to AVPN ............................................................................ 54
Pre-failover Route Table ................................................................................... 54
Pre-failover Traffic Flow Diagram ..................................................................... 54
Post-failover Route Table Analysis.................................................................... 55
Post-failover Traffic Flow Diagram ................................................................... 55
3.2.3 Failover from AVPN to VZB ........................................................................... 56
Post-failover Route Table Analysis.................................................................... 56
Post-failover Traffic Flow Diagram ................................................................... 56
3.2.4 Fallback from VZB to ISP ............................................................................... 57
Post-fallback Route Table Analysis ................................................................... 57
Post-fallback Traffic Flow Diagram ................................................................... 57
4 Additional Design Considerations........................................................ 58
4.1 Gotchas ............................................................................................................. 58
4.2 BGP Best Path Selection Process (From Cisco Documentation) ....................... 58
5 Appendix D: Contact Information ........................................................ 61
5.1 AT&T Consulting................................................................................................ 61
3
1 SOLUTION OVERVIEW
Today, many enterprise networks have robust, redundant WANs with multiple internet POPs.
One of the current challenges facing many of these networks relates to internet based routing.
For many, this is manually configured within the L3 core network, pointing to the local firewall,
and thus, if a site that has local internet and/or provides internet access for remote sites, loses
its local internet connection, these networks experience downtime and failure of internet based
traffic for that site, as well as other sites that use that site as an internet POP.
This is until manual intervention is taken and the default route is reconfigured to point back to
the private WAN cloud, (e.g. an MPLS network or other private WAN), possibly requiring the
MPLS folks to make adjustments within the cloud environment as well.
This is not a desirable solution, especially when there are numerous internet POPs available in
the enterprise.
The goal of resolving the issue described above is to create a dynamic default routing design,
whereby the default route can be distributed dynamically (across firewalls) to the core of the
site with the local internet POP as primary, and failover dynamically to other internet POPs
available across the private WAN without any manual intervention.
Optimally, as shown in this white paper, the network would use the local internet as first choice.
Then, for the purposes of this white paper, the AT&T MPLS (AVPN) is used as second choice, and
lastly, the Verizon MPLS path is used as the third choice to reach an internet POP.
This white paper and solution design present one option enterprise networks can use to resolve
this issue in a robust and solid way.
Any non-internet Sites (e.g. sites that do not have local internet access) will have to receive the
default dynamically if the remote site has redundant private WAN connections, and remove any
static default routing.
The solution presented in this white paper has been tested in the lab successfully
using GNS3.
4
The solution uses the following design strategies:
1. eBGP from the edge router (referred to as internet-facing-rt1) to the core router (referred to as
internal-L3-core-sw1) using eBGP multihop
2. Within the edge/perimeter network, OSPF is used to dynamically distribute the default route
back to the next hop after the firewall.
3. The next hop is providing edge/perimeter network routing services (referred to as edge-L3-core-
sw1).
4. Firewall routing uses manual default route pointing back to the edge network core router
(referred to as edge-L3-core-sw1).
5. Routes to and from internet-facing-rt1 and internal-L3-core-sw1s loopback interfaces must be
present
6. NAT must be bypassed in the Firewall for the loopback0 IP of the core router (internal-L3-core-
sw1)
7. BGP is used to exchange all routes within the internal enterprise network with this design,
including LAN routes. This would be a routing paradigm shift within most enterprise networks,
although this is only needed at sites with local internet access, and not needed at sites that use a
remote site for internet access.
8. OSPF is only used to learn the loopback0 IPs for the purpose of BGP neighbor establishment.
OSPF on the internal network does not provide routes to LAN or WAN networks. I call OSPF a
utility routing protocol for the purposes of this design.
9. iBGP full mesh is needed from the private WAN routers (referred to as AVPN-WAN-rt1 and as
VZB-WAN-rt2) to the private core (internal-L3-core-sw1)
10. The default route is received from internet-facing-rt1 to the internal core (internal-L3-core-sw1)
via eBGP and passed onto AVPN-WAN-rt1 and VZB-WAN-rt2 via iBGP.
11. Recursive route lookup is used to reach the default route. (Next hop preserved)
12. AVPN-WAN-rt1 and VZB-WAN-rt2 pass the default into the private WAN cloud (Simulated MPLS
cloud is used as part of this white paper).
13. The reverse is true, e.g. AVPN-WAN-rt1 and VZB-WAN-rt2 have a backup default route in the bgp
table ready to populate if the route via internet-facing-rt1 drops out (primary internet down)
14. All precautions are taken to ensure symmetry, proper first choice, second choice and third choice
for the default route, and to make sure no internal networks are leaked into the edge/perimeter
network
15. All precautions are taken to ensure no routes other than the default route are accepted from
edge/perimeter network (internet-facing-rt1) back to the internal core (internal-L3-core-sw1)
In summary, having a dynamic default routing architecture in place can help to provide a great
deal of value to enterprise networks, with internet outages occurring (and being resolved) with
minimal to no interruption of service to the end user.
5
2 CONFIGURE
This chapter goes over the lab environment, first covering the topology (network
diagram), then an analysis of the network diagram/topology.
Following that, we go over each device configuration, and finally, an analysis of the
configuration of each device used in the lab.
2.1 LAB ENVIRONMENT
For the lab environment, we utilized GNS3, using Cisco 3700 Series routers. We created
the topology shown in the network diagram below.
Specifics regarding the topology are covered in the section following the Network
Diagram section titled Network Diagram Analysis
2.1.1 Network Topology | Network Diagram
Primary WAN provider Secondary WAN provider

AVPN Verizon MPLS
AS 13979 AS 65300
MPLS layer
EBGP
EBGP
Internet layer WAN link
10.107.246.14 IBGP
WAN link
149.181.151.30
copper copper
AS 65523
BGP AS 1000
AVPN-WAN-rt1 VZB-WAN-rt2
EBGP 10.90.7.197/30 10.90.7.198/30
Internet
OSPF 2350
BGP 2350 Area 0
EBGP
internet-facing-rt1
10.90.7.240/30
ospf cost 100
/30 Routed link L3-CORE-SW1
OSPF 2350
Area 0
edgeL3-CORE-SW1 FW1
Edge layer
Core layer
6
2.1.2 Network Diagram Analysis
The network diagram above shows a simulated ISP (cloud object) which used a router
configured with BGP AS 1000 and included some additional test networks. This router
has an eBGP session to BGP AS 2350.
OSPF is the IGP (Interior Gateway Protocol) that runs from the inside of internet-facing-
rt1 to edge-L3-core-sw1, providing a route from internet-facing-rt1 to edge-L3-core-sw1
to the loopback0 IP of internet-facing-rt1 and redistributing the default route received
from the ISP router into OSPF from internet-facing-rt1 to edge-L3-core-sw1.
This provides default routing on the edge/perimeter network dynamically all the way
up to edge-L3-core-sw1. In addition to this, within the perimeter network, only the
Firewall needs to have a static default route pointing to edge-L3-core-sw1 to complete
default routing from the firewall to the ISP.
The next device inline in the topology is the firewall, which within the lab, was a Cisco
router. This was used in the lab to Act as a firewall would (relative to design testing),
providing NAT to translate all internet bound traffic to a public IP using the external
block IP address space. This also allowed us simulate the configuration needed to
bypass NAT for the loopback0 IP for the internal L3 core (internal-L3-core-sw1), which
needs to traverse the firewall and maintain its true loopback0 IP on its way to internet-
facing-rt1 for eBGP session communication.
Next inline in the diagram is the core internal-L3-core-sw1 which was used to simulate
end LAN networks, core routing from the LAN to the internet and to the private MPLS
WAN (AVPN or Verizon)
After the core are the connections out to the MPLS WAN layer via AVPN-WAN-rt1 or
VZB-WAN-rt2.
Finally, there are two more cloud objects in the topology which represent the AVPN and
Verizon MPLS clouds. Again, Cisco routers were used to simulate the PER devices and
eBGP sessions back to AVPN-WAN-rt1 and VZB-WAN-rt2.
7
Additional notes about the diagram include the logical representation of routing domain
demarcation points, e.g. there is an eBGP session from AS 1000 to AS 2350 (ISP to the
Enterprise network), and an eBGP session from AS 2350 to AS 65523 (iBGP Private AS in
the lab). This is what is needed to bring the default route into the internal route table,
using the firewall as the next hop. The actual next hop (as will be shown and described
in later sections) will be the loopback0 IP of internet-facing-rt1. This is due to BGP
behavior, which shows the IP of the next hop from the neighbor that advertised the
route (internet-facing-rt1).
So, for example, on core internal-L3-core-sw1 or AVPN-WAN-rt1, the default routes

next hop will be 131.89.81.253 (internet-facing-rt1 loopback0) and the route to get
there will be dictated by the route to get to 131.89.81.253, which is also referred to as a
recursive route lookup. This is one of the many key subtleties of the design and
configuration. There not only needs to be a static route to 131.89.81.253 in internal-L3-
core-sw1, but this needs to be advertised via the network command under BGP in
internal-L3-core-sw1, to get this route over to AVPN-WAN-rt1 and VZB-WAN-rt2.
This will be covered under the section where we analyze internal-L3-core-sw1s

configuration.
OSPF runs in the core of the network, but only as a utility routing protocol, e.g. only to
provide a route to the loopback0 interfaces of internal-L3-core-sw1, AVPN-WAN-rt1 and
VZB-WAN-rt2, which are required to establish the iBGP session between internal-L3-
core-sw1, AVPN-WAN-rt1 and VZB-WAN-rt2.
No LAN routes are exchanged using OSPF. Only loopback0 IPs, and the transit nets
where the OSPF adjacencies are established.
Full mesh iBGP sessions are established within AS 65523 from core internal-L3-core-sw1,
AVPN-WAN-rt1 and VZB-WAN-rt2
Lastly, one eBGP session from AS 65523 to AS 13979 is established (AVPN) and one
eBGP session from AS 65523 to AS 65300 is established (Verizon MPLS)
8
2.2 EDGE NETWORK CONFIGURATION
2.2.1 Internet-facing-rt1
The router configuration specific to the solution is shown below:
Configuration
interface Loopback0
description OSPF-BGP-RID
ip address 131.89.81.253 255.255.255.255
interface FastEthernet0/0
description connected to edge-L3-core-sw1
ip address 131.89.81.229 255.255.255.252
no ip redirects
ip ospf network point-to-point
ip ospf cost 10
ip ospf 2350 area 0.0.0.0
description ### Internet Circuit ###
ip address 1.1.1.1 255.255.255.252
router ospf 2350
router-id 131.89.81.253
log-adjacency-changes
area 0 authentication message-digest
passive-interface default
no passive-interface FastEthernet0/0
network 131.89.81.228 0.0.0.3 area 0
network 131.89.81.253 0.0.0.0 area 0
default-information originate metric 1 metric-type 1
router bgp 2350
no synchronization
bgp router-id 131.89.81.253
9
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.252
network 131.89.80.0 mask 255.255.254.0
neighbor 1.1.1.2 remote-as 1000
neighbor 1.1.1.2 soft-reconfiguration inbound
neighbor 1.1.1.2 prefix-list default-route-in in
neighbor 1.1.1.2 prefix-list external-block-only out
neighbor 10.90.1.251 eBGP-multihop 255
neighbor 10.90.1.251 update-source Loopback0
default-information originate
no auto-summary
ip prefix-list default-route-in seq 5 permit 0.0.0.0/0
ip prefix-list external-block-only seq 5 permit 131.89.80.0/23
Configuration Analysis
OSPF related:
OSPF uses the loopback0 interface as the OSPF router ID.
The configuration advertises the /32 loopback interface and the 131.89.81.228/30
transit net which exists between internet-facing-rt1 and edge-L3-core-sw1 to bring up
the OSPF adjacency.
The /32 loopback0 interface is advertised to edge-L3-core-sw1 to assist in getting the

route to this IP back to the internal core network. This is needed for establishing the
eBGP session with internal-L3-core-sw1, since internal-L3-core-sw1 and internet-facing-
rt1 will establish an eBGP session via loopback0 interfaces.
Lastly, OSPF originates a default route to propagate back to edge-L3-core-sw1, which is
the final destination for the default route (dynamically speaking) on the edge network.
10
The next device in the edge network is fw1, which uses static routes (has a static default
route pointing to edge-L3-core-sw1)
Under OSPF, default-information originate is all that is needed for the IGP (OSPF) to
get the default back to edge-L3-core-sw1, since the default will be in the RIB of internet-
facing-rt1 (learned via eBGP session to the ISP router)
Internet-facing-rt1 OSPF specific config snippet:
network 131.89.81.228 0.0.0.3 area 0
## transit net to edge-L3-core-sw1 to establish OSPF session
network 131.89.81.253 0.0.0.0 area 0
## loopback0 net
default-information originate metric 1 metric-type 1
## get default route advertised to edge-L3-core-sw1 as type 1, which is preferred over
type2
The metric-type 1 is not needed in this lab exercise, but is recommended, as it would
*fit* perfectly into a design if the local site was dual homed to multiple ISPs, so, for
example, you could prefer rt1 as first choice on the perimeter and rt2 (second provider)
as second choice, just by receiving the second route as a normal type-2 route. Of
course, this goes beyond the scope of this white paper, e.g. youd then need another
eBGP session from the edge-rt2 router back to the internal-core router too, plus you
might want to load balance traffic out to both ISPs. In addition, youd probably be
running iBGP between the two internet-facing routers if dual homing to multiple ISPs.
You might also have multiple ISP connections coming out of one router too, thus not
needing to run iBGP on the edge router.
11
BGP related:
BGP also uses the loopback0 interface as the router ID.
The configuration advertises the 1.1.1.0/30 net, which is used in the lab as the WAN
block between the ISP router and internet-facing-rt1. It also advertises the /23 external
block (131.89.80.0/23). This route is present in the RIB via OSPF redistribution from
edge-L3-core-sw1.
Two BGP policies have been applied using prefix-lists. The first one is applied inbound
on route updates from the ISP to internet-facing-rt1:
Neighbor 1.1.1.2 prefix-list default-route-in in
The above configuration makes sure that regardless of what the ISP sends, we will only
accept a default route from the ISP.
The second policy is applied for outbound updates from internet-facing-rt1 to the ISP
router (BGP neighbor 1.1.1.2):
Neighbor 1.1.1.2 prefix-list external-block-only out
ip prefix-list external-block-only seq 5 permit 131.89.80.0/23
Since there is no additional prefix-list seq number, everything else is denied.
The above configuration ensures we will only advertise the /23 external block to the ISP
The next part of the configuration is the eBGP session to the core (internal-L3-core-sw1).
This session is established using the loopback interface of internal-L3-core-sw1 and must
use eBGP multi-hop to work using an IP thats not on a directly connected subnet.
Again, noting there must be a route to this loopback in the IGP (OSPF will know about
this route via redistribution from edge-L3-core-sw1 into OSPF).
12
Lastly, we specify that updates to internal-L3-core-sw1 will use our loopback0 IP as the
source of the updates (critical for successful configuration). The internet-facing-rt1
loopback0 IP is 131.89.81.253 and the loopback0 IP of internal-L3-core-sw1 is
10.90.1.251.
Internet-facing-rt1 BGP specific config snippet:

neighbor 10.90.1.251 eBGP-multihop 255
Lastly, on internet-facing-rt1 under BGP, the default-information originate is all that is

needed to advertise the default route back to the core (internal-L3-core-sw1) since the
default will not only be in the RIB of internet-facing-rt1 (learned via eBGP session to the
ISP router), but it will also in the bgp table. Since it will be a BGP route, a network
statement is not needed, and only the default-information originate command under
BGP is needed.
2.2.2 Edge-L3-core-sw1
Configuration
interface Loopback0
description OSPF-RID
ip address 131.89.81.251 255.255.255.255
description TRANSIT- FW1::131.89.81.16/28
ip address 131.89.81.17 255.255.255.240
13
description connected to internet-facing-rt1
ip address 131.89.81.230 255.255.255.252
router ospf 2350
router-id 131.89.81.251
redistribute static subnets route-map static-to-ospf
network 131.89.81.228 0.0.0.3 area 0.0.0.0
network 131.89.81.251 0.0.0.0 area 0.0.0.0
ip route 10.90.1.251 255.255.255.255 131.89.81.20 name Internal-L3-SW1-Loop0-VIA-FW
ip route 131.89.80.0 255.255.254.0 Null0
ip prefix-list static-to-ospf seq 20 permit 131.89.80.0/23
route-map static-to-ospf permit 10
match ip address prefix-list static-to-ospf
OSPF related:
The configuration advertises the /32 loopback interface and the 131.89.81.228/30
transit net which exists between internet-facing-rt1 and edge-L3-core-sw1 to bring up
the OSPF adjacency. The /32 loopback0 interface (131.89.81.251) is advertised to
internet-facing-rt1.
This is needed for establishing the eBGP session with internal-L3-core-sw1 since core
internal-L3-core-sw1 and internet-facing-rt1 establish the eBGP session via loopback0
interfaces.
14
router ospf 2350
router-id 131.89.81.251
network 131.89.81.228 0.0.0.3 area 0.0.0.0
network 131.89.81.251 0.0.0.0 area 0.0.0.0
ip route 10.90.1.251 255.255.255.255 131.89.81.20
ip route 131.89.80.0 255.255.254.0 Null0
router ospf 2350
redistribute static subnets route-map static-to-ospf
Two static routes are configured on edge-L3-core-sw1. One points to the core internal-
L3-core-sw1 loopback0 IP with a next hop of fw1, and the other is the /23 public
external block, pointing to null0.
Both of these static routes are redistributed into OSPF via a route map, which points to
a prefix-list, specifying these exact prefixes.
This allows OSPF to advertise the public block /23 to internet-facing-rt1, which then
advertises it via eBGP to the ISP.
Lastly, we advertise the core internal-L3-core-sw1 loopback0 IP (10.90.1.251) back to

internet-facing-rt1 which is needed for eBGP session establishment between internet-
facing-rt1 and core internal-L3-core-sw1.
15
2.2.3 Firewall
The configuration specific to the solution is shown below:
Configuration
ip address 10.90.7.225 255.255.255.240
ip nat inside
description transit to edge-L3-core-sw1
ip address 131.89.81.20 255.255.255.240
ip nat outside
ip route 0.0.0.0 0.0.0.0 131.89.81.17
ip route 10.0.0.0 255.0.0.0 10.90.7.228
ip nat pool fw1 131.89.81.29 131.89.81.30 prefix-length 30
ip nat inside source list 7 pool fw1 overload
access-list 7 deny 10.90.1.251
access-list 7 permit 10.0.0.0 0.255.255.255
The configuration is simulating what a firewall would provide to the network from a
routing perspective, and for testing purposes related to the white paper.
16
Two static routes are configured. One is the default route pointing to edge-L3-core-sw1
as the next hop, and one is a 10.0.0.0/8 pointing back to the internal network core
(internal-L3-core-sw1). The default static will cover the route needed by BGP to get to
the loopback0 IP on internet-facing-rt1, sending it to edge-L3-core-sw1. Once it gets to
edge-L3-core-sw1, an OSPF route will get it to internet-facing-rt1. The 10.0.0.0/8
pointing back into the core at internal-L3-core-sw1 will cover the reverse direction route
back to the 10.0.0.0/8 internal nets and the route to internal-L3-core-sw1s loopback0 IP
via internal-L3-core-sw1.
From internet-facing-rt1, it will receive internal-L3-core-sw1s loopback0 route from

edge-L3-core-sw1 via OSPF, and edge-L3-core-sw1 is configured with a static route to
this loopback with a next hop of fw1.
NAT is setup on the Firewall router to simulate and test routed connectivity from the
MPLS cloud, internal-L3-core-sw1, AVPN-WAN-rt1, and VZB-WAN-rt2 out to the ISP
router via ping tests, NATTing to an IP within the public address space.
The last part of the configuration, which is very important to the design, is the need to
omit NAT on the loopback0 IP of core internal-L3-core-sw1 when it traverses the
firewall:
ip nat inside source list 7 pool fw1 overload
access-list 7 deny 10.90.1.251
access-list 7 permit 10.0.0.0 0.255.255.255
This allows the eBGP session to be established by maintaining the true IP of internal-L3-
core-sw1s loopback0 as it communicates to internet-facing-rt1 via eBGP
On fw1, using a real world firewall scenario, TCP port 179 would need to be opened
from loopback0 to loopback0 IPs (from internet-facing-rt1 to core internal-L3-core-sw1)
17
2.2.4 Internet Service Provider Router
Configuration
hostname ISP-Router
interface Loopback10
description test-net
ip address 14.1.1.1 255.255.255.255
description ### Internet Circuit ###
ip address 1.1.1.2 255.255.255.252
router bgp 1000
no synchronization
network 0.0.0.0
network 1.1.1.0 mask 255.255.255.252
network 13.0.0.0 mask 255.255.0.0
no auto-summary
ip route 0.0.0.0 0.0.0.0 Null0
ip route 13.0.0.0 255.255.0.0 Null0 name test-net
18
The ISP configuration used in the white paper was setup to obtain the following
objectives:
1. Advertise a default route back to the Private Networks CPE (internet-facing-rt1)

2. Advertise an additional network (13.0.0.0/16) to make sure internet-facing-rt1
blocked this route and only accepted the default 0/0 route
3. Provide another reachable network (loopback10 @ 14.1.1.1) that could be
tested via ping as a test-net simulating a network out on the internet. This was
to test the defaut route from the internal network, and for testing proper
routing from the internet cloud back to the networks external public block.
The above was accomplished by first creating a default route to null0 and then bringing
it into BGP using the following:
ip route 0.0.0.0 0.0.0.0 Null0
router bgp 1000
network 0.0.0.0
Next, the loopback10 interface was setup to make the 14.1.1.1/32 net pingable:
description test-net
ip address 14.1.1.1 255.255.255.255
Next, the following was created in the configuration to test CPE filtering of only the 0/0
default route:
ip route 13.0.0.0 255.255.0.0 Null0 name test-net
router bgp 1000
network 13.0.0.0 mask 255.255.0.0
19
Beyond that, a basic eBGP session was configured between the ISP router and internet-
facing-rt1:
router bgp 1000
network 1.1.1.0 mask 255.255.255.252
2.3 INTERNAL NETWORK CONFIGURATION (LAN CORE)
2.3.1 Internal-L3-core-sw1
Configuration
hostname internal-L3-core-sw1
interface Loopback0
description OSPF-BGP-RID
ip address 10.90.1.251 255.255.255.255
description simulated End User Networks
ip address 10.90.10.1 255.255.255.0
ip address 10.90.11.1 255.255.255.0
ip address 10.90.12.1 255.255.255.0
20
ip address 10.90.13.1 255.255.255.0
description to VZB-WAN-rt2 VERIZON
ip address 10.90.7.249 255.255.255.252
ip ospf cost 100
ip address 10.90.7.228 255.255.255.240
description to AVPN-WAN-rt1 AVPN
ip address 10.90.7.241 255.255.255.252
router ospf 2350
router-id 10.90.1.251
network 10.90.1.251 0.0.0.0 area 0.0.0.0
network 10.90.7.240 0.0.0.3 area 0.0.0.0
network 10.90.7.248 0.0.0.3 area 0.0.0.0
router bgp 65523
no synchronization
network 10.90.0.0 mask 255.255.0.0
network 131.89.81.253 mask 255.255.255.255
network 172.26.64.0 mask 255.255.192.0
21
neighbor 131.89.81.253 ebgp-multihop 255
neighbor 131.89.81.253 weight 65535
neighbor 131.89.81.253 prefix-list deny-all-routes out
no auto-summary
ip route 10.90.0.0 255.255.0.0 Null0
ip route 172.26.64.0 255.255.192.0 Null0
ip route 131.89.81.253 255.255.255.255 10.90.7.225 name ebgp-loop-via-FW
ip prefix-list deny-all-routes seq 5 deny 0.0.0.0/0 le 32
First, we have created three simulated LAN networks using loopback10 thru 12. These
use subnets 10.90.10.0/24, 10.90.11.024, 10.90.12.0/24 and 10.90.13.024.
This is to test BGP functionality and routed connectivity from the AVPN and Verizon
cloud routers back to the LAN networks
The following static routes are created:
ip route 10.90.0.0 255.255.0.0 Null0
ip route 172.26.64.0 255.255.192.0 Null0
ip route 131.89.81.253 255.255.255.255 10.90.7.225 name ebgp-loop0-via-FW1
22
The first two routes are aggregates to null0, which cover all sites networks (all 10.x.x.x)
and a simulated aggregate to 172.26.64.0/18.
These are advertised into BGP for testing purposes.
The third route is a route to internet-facing-rt1s loopback0 interface, which is critical to

establishing the eBGP neighbor session. The next hop points back to fw1.
This is also advertised into BGP.
OSPF related:
OSPF uses the loopback0 interface as the OSPF and BGP router ID.
The configuration advertises the /32 loopback interface, the 10.90.7.248/30 and the
10.90.7.240/30 transit nets which exist from internal-L3-core-sw1 to AVPN-WAN-rt1 and
VZB-WAN-rt2. This is all that is needed to bring up the OSPF adjacency.
router ospf 2350
router-id 10.90.1.251
network 10.90.1.251 0.0.0.0 area 0.0.0.0
network 10.90.7.240 0.0.0.3 area 0.0.0.0
network 10.90.7.248 0.0.0.3 area 0.0.0.0
The cost is bumped up on the connection from internal-L3-core-sw1 back to VZB-WAN-

rt2, so internal-L3-core-sw1 will always prefer the path via AVPN-WAN-rt1 for routes
originating from the MPLS cloud
description to VZB-WAN-rt2
ip address 10.90.7.249 255.255.255.252
ip ospf cost 100
23
Thats all for OSPF, which is only being used as a utility routing protocol, e.g. just to
get the loopback interface advertised to AVPN-WAN-rt1 and VZB-WAN-rt2 for BGP
neighbor establishment. All routes to end node networks are learned via BGP
BGP related:
BGP first advertises the LAN aggregates and the loopback0 of internet-facing-rt1. This is
needed, so all iBGP neighbors (AVPN-WAN-rt1, VZB-WAN-rt2) will have a route to the
next hop of the default route, which will be in the BGP tables, and the RIB as
131.89.81.253 (internet-facing-rt1s loopback0).
No BGP aggregate address configuration is needed, because the route to null0 is

already an aggregate and will be configured into BGP via a network command, since
these aggregates are already in the RIB.
router bgp 65523
network 10.90.0.0 mask 255.255.0.0
network 131.89.81.253 mask 255.255.255.255
network 172.26.64.0 mask 255.255.192.0
Next, the BGP configuration sets up the neighbors for AVPN-WAN-rt1, VZB-WAN-rt2 and
internet-facing-rt1, as shown below:
router bgp 65523
neighbor 131.89.81.253 ebgp-multihop 255
24
Above, youll notice we must use ebgp-multihop since internet-facing-rt1 is not on the
same subnet as internal-L3-core-sw1. Ive left the max hops set to default.
One additional command I have in there thats not needed, but used as a safety net, is
the bgp weight statement. This guarantees that internet-facing-rt1 (131.89.81.253) (if
up and available) will always be preferred for any routes it advertises. We will also
control what we accept from internet-facing-rt1 (only the default route).
We also control what we send via bgp from internal-L3-core-sw1 to internet-facing-rt1

(will not send ANY routes from internal-L3-core-sw1 to internet-facing-rt1)
The configuration is shown below:
router bgp 65523
neighbor 131.89.81.253 prefix-list deny-all-routes out
ip prefix-list deny-all-routes seq 5 deny 0.0.0.0/0 le 32
2.4 PRIVATE WAN NETWORK CONFIGURATION (DUAL MPLS PROVIDERS)
2.4.1 AT&T (AVPN) WAN Router 1
Configuration
hostname AVPN-WAN-rt1
interface Loopback0
ip address 10.90.1.253 255.255.255.255
25
!
description to-VZB-WAN-rt2-iBGP
ip address 10.90.7.197 255.255.255.252
description To-AVPN-PE
ip address 10.107.246.14 255.255.255.252
description To-internal-L3-core-sw1
ip address 10.90.7.242 255.255.255.252
router ospf 2350
router-id 10.90.1.253
network 10.90.1.253 0.0.0.0 area 0.0.0.0
network 10.90.7.196 0.0.0.3 area 0.0.0.0
network 10.90.7.240 0.0.0.3 area 0.0.0.0
router bgp 65523
no synchronization
network 10.107.246.12 mask 255.255.255.252
26
neighbor 10.107.246.13 send-community
neighbor 10.107.246.13 route-map set-community-default-route
no auto-summary
route-map set-community-default-route permit 10
match ip address 20
set community 65523:110
access-list 20 permit 0.0.0.0
ip bgp-community new-format
OSPF related:
10.90.7.196/30 transit nets which exist from AVPN-WAN-rt1 to internal-L3-core-sw1,
and from AVPN-WAN-rt1 to VZB-WAN-rt2 respectively.
This is all that is needed to bring up the OSPF adjacency.
27
router ospf 2350
router-id 10.90.1.253
network 10.90.1.253 0.0.0.0 area 0.0.0.0
network 10.90.7.196 0.0.0.3 area 0.0.0.0
network 10.90.7.240 0.0.0.3 area 0.0.0.0
get the loopback0 interface advertised to internal-L3-core-sw1 and VZB-WAN-rt2 for
iBGP neighbor establishment.
BGP related:
BGP does not have any network statements on AVPN-WAN-rt1, except for the MPLS
WAN block network 10.107.246.12 mask 255.255.255.252. This is all that is needed,
because all routes, including LAN aggregates, default route, etc are *already* known via
iBGP, and thus, will be passed onto any eBGP neighbors, e.g. the AVPN or Verizon MPLS
private WAN PERs.
In addition to above, the following bgp configuration is used:
iBGP neighbors are setup to VZB-WAN-rt2 and internal-L3-core-sw1.
An eBGP neighbor is setup to the AVPN PE router.
We set the weight on neighbor internal-L3-core-sw1 to 40000. This is used so AVPN-

WAN-rt1 will prefer the default route being advertised from internal-L3-core-sw1 in
favor of the default route being advertised from the AVPN, (which will have a shorter as-
path). This is also needed in an environment with dual cores, so internal-L3-core-sw1
would be preferred over L3-CORE-SW2 by configuring a weight on L3-CORE-SW2 of say
35000.
28
Lastly, the configuration to send the default route into the MPLS cloud (e.g. if this site
was going to be an internet POP for other sites) is setup using a policy which configures
the default route to be in a bgp community before sending to the MPLS cloud.
Doing this, the provider can then set policy accordingly. There are other ways of doing
this, and this is just shown as one example that might be used in conjunction with as-
path pre-pending, etc. if the private WAN is an MPLS cloud and not completely under
the control of the private enterprise, e.g. point-to-point WAN connections.
This might, for example be used by the provider to set a preference for remote sites
using this site as an internet POP within the cloud itself.
Note:
This service must be provided by the MPLS provider to work properly. (Match
community and set policy within the cloud)
No network 0.0.0.0 statement under bgp is needed. Only default-information

originate
Configuration shown below.
router bgp 65523
neighbor 10.107.246.13 send-community
neighbor 10.107.246.13 route-map set-community-default-route
match ip address 20
set community 65523:110 ## Fictional community ###
access-list 20 permit 0.0.0.0
29
2.4.2 Verizon (VZB) WAN Router 2
Configuration
hostname VZB-WAN-rt2
interface Loopback0
ip address 10.90.1.254 255.255.255.255
description to-AVPN-WAN-rt1
ip address 10.90.7.198 255.255.255.252
description to-internal-L3-core-sw1
ip address 10.90.7.250 255.255.255.252
description Verizon MPLS:
ip address 149.181.151.30 255.255.255.252
router ospf 2350
router-id 10.90.1.254
network 10.90.1.254 0.0.0.0 area 0.0.0.0
network 10.90.7.196 0.0.0.3 area 0.0.0.0
network 10.90.7.248 0.0.0.3 area 0.0.0.0
30
router bgp 65523
no synchronization
network 149.181.151.28 mask 255.255.255.252
neighbor 149.181.151.29 route-map as-path-prepend-map out
no auto-summary
route-map as-path-prepend-map permit 10
set as-path prepend 65523 65523 65523 65523 65523
OSPF related:
10.90.7.196/30 transit nets which exist from VZB-WAN-rt2 to internal-L3-core-sw1, and
from VZB-WAN-rt2 to AVPN-WAN-rt1. This is all that is needed to bring up the OSPF
adjacency.
router ospf 2350
router-id 10.90.1.254
network 10.90.1.254 0.0.0.0 area 0.0.0.0
network 10.90.7.196 0.0.0.3 area 0.0.0.0
network 10.90.7.248 0.0.0.3 area 0.0.0.0
31
get the loopback interface advertised to internal-L3-core-sw1 and AVPN-WAN-rt1 for
BGP neighbor establishment.
BGP related:
BGP does not have any network statements on VZB-WAN-rt2, except for the MPLS WAN
block network 149.181.151.28 mask 255.255.255.252. This is all that is needed,
because all routes, including LAN aggregates, default route, etc are *already* known via
iBGP, and thus, will be passed onto any eBGP neighbors, e.g. AVPN or Verizon PERs.
In addition to above, the following bgp configuration is used:
iBGP neighbors are setup to AVPN-WAN-rt1 and internal-L3-core-sw1.
eBGP neighbor is setup to the Verizon PE router.
We set the weight on the neighbor internal-L3-core-sw1 to 40000. This is used, so in an

environment with dual cores, internal-L3-core-sw1 would be preferred over L3-CORE-
SW2 by not configuring a weight on L3-CORE-SW2.
Lastly, we setup the configuration to first send the default route into the MPLS cloud
(e.g. if this site was going to be an internet POP for other sites) and most importantly,
we setup a route map to as-path prepend all routes so the AVPN is always preferred for
all routes (if available) and the Verizon MPLS cloud is second choice.
Again, no network 0.0.0.0 statement under bgp is needed. Only default-information

originate
Configuration shown below:
32
router bgp 65523
2.4.3 AT&T MPLS PE Router
Configuration
hostname AVPN-PER
ip address 10.10.0.1 255.255.255.255
ip address 10.20.0.1 255.255.255.255
description AVPN-to-CE
ip address 10.107.246.13 255.255.255.252
router bgp 13979
no synchronization
network 0.0.0.0
network 10.10.0.1 mask 255.255.255.255
network 10.20.0.1 mask 255.255.255.255
network 10.107.246.12 mask 255.255.255.252
no auto-summary
33
!
ip route 0.0.0.0 0.0.0.0 Null0
The goal of the AVPN PE lab configuration was to generate a default route back to the
CE router (AVPN-WAN-rt1) and to generate a few test-networks simulating advertised
networks that would come from the AVPN cloud, e.g. remote LAN networks from a
remote site. Loopback10 and 11 were used for this purpose, generating routes to:
10.10.0.1/32
10.20.0.1/32
The same routes were generated on the Verizon PE router to validate path preference
was configured correctly, e.g. as-path prepending, weight, etc were working correctly.
A default route to null0 was created and then advertised into bgp.
The two /32 routes were advertised into bgp.
Using the following configuration:
router bgp 13979
network 0.0.0.0
network 10.10.0.1 mask 255.255.255.255
network 10.20.0.1 mask 255.255.255.255
ip route 0.0.0.0 0.0.0.0 Null0
Simply removing the route to null0 in the lab would assist with failover scenarios, as will be shown in
the verify section.
34
2.4.4 Verizon MPLS PE Router
Configuration
hostname Verizon-PER
ip address 10.10.0.1 255.255.255.255
ip address 10.20.0.1 255.255.255.255
description Verizon MPLS VPN:
ip address 149.181.151.29 255.255.255.252
router bgp 65300
no synchronization
network 0.0.0.0
network 10.10.0.1 mask 255.255.255.255
network 10.20.0.1 mask 255.255.255.255
network 149.181.151.28 mask 255.255.255.252
no auto-summary
ip route 0.0.0.0 0.0.0.0 Null0
35
The goal of the Verizon PE lab configuration was also to generate a default route back to
the CE router (VZB-WAN-rt2) and to generate the same test-networks simulating
advertised networks that would come from the Verizon cloud, e.g. remote LAN
networks from a remote site. Loopback10 and 11 were used for this purpose, generating
routes to:
10.10.0.1/32
10.20.0.1/32
The same routes were generated on the AVPN PE router to validate path preference
was configured correctly, e.g. as-path prepending, weight, etc were working correctly.
A default route to null0 was created and then advertised into bgp.
The two /32 routes were advertised into bgp.
Using the following configuration:
router bgp 65300
network 0.0.0.0
network 10.10.0.1 mask 255.255.255.255
network 10.20.0.1 mask 255.255.255.255
ip route 0.0.0.0 0.0.0.0 Null0
Simply removing the route to null0 in the lab would assist with failover scenarios, as will
be shown in the verify section.
36
3 VERIFY
First, lets take a look at each device to get an overall view that our routing is working
how it should be.
This will also provide some additional insight into the overall design and functionality.
3.1 VALIDATE ROUTING
3.1.1 ISP Router
Youll see the ISP router has a bgp route to the external block 131.89.80.0/23 only. No
other bgp routes learned from internet-facing-rt1.
It also has a bgp route to the Perimeter /30 block and to the 13.0.0.0/16 network, which
we created earlier to make sure internet-facing-rt1 is blocking this route, and all but
the default route are blocked from coming into bgp (from the ISP to internet-facing-rt1).
We see the 14.1.1.1 network which is used as a simulated internet host.
We see the external network block 131.89.0.0/23 coming via eBGP from internet-
facing-rt1.
We also see the default route in the ISP router.
ISP>sh ip route
1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0
B 131.89.80.0 [20/20] via 1.1.1.1, 00:00:31
S 13.0.0.0 is directly connected, Null0

37
C 14.1.1.1 is directly connected, Loopback10
S* 0.0.0.0/0 is directly connected, Null0
3.1.2 Internet-facing-rt1
Looking at internet-facing-rt1, we see this router has a bgp originated default route back
to the ISP router only. No other bgp routes are learned from the ISP router. This way, we
know our inbound filtering on the ISP neighbor is working correctly. We can also see the
as-path to the ISP on the default route is correct (AS 1000)
Lastly, we see bgp routes to the /23 aggregate external block that we are advertising to
the ISP router, and the /30 WAN block where the neighbor is established.
In the output from the show ip route command, we see the following in the RIB:
An OSPF external type 2 route to 10.90.1.251/32 (core internal-L3-core-sw1s loopback

interface)
An OSPF external type 2 route to 131.89.80.0/23 (external LAN block)
An OSPF route to 131.89.81.251/32 (edge-L3-core-sw1s loopback interface)
A BGP default route from the ISP router
internet-facing-rt1>sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 1.1.1.2 0 0 1000 i
*> 1.1.1.0/30 0.0.0.0 0 32768 i
*> 131.89.80.0/23 131.89.81.230 20 32768 i
internet-facing-rt1>sh ip route
O E2 10.90.1.251 [110/20] via 131.89.81.230, 00:06:41, FastEthernet0/0
38
131.89.0.0/16 is variably subnetted, 4 subnets, 3 masks
C 131.89.81.253/32 is directly connected, Loopback0
O 131.89.81.251/32 [110/11] via 131.89.81.230, 00:06:41, FastEthernet0/0
C 131.89.81.228/30 is directly connected, FastEthernet0/0
O E2 131.89.80.0/23 [110/20] via 131.89.81.230, 00:06:41, FastEthernet0/0
B* 0.0.0.0/0 [20/0] via 1.1.1.2, 00:06:07
internet-facing-rt1>
3.1.3 Edge-L3-core-sw1
Looking at edge-L3-core-sw1, we see the following in the RIB:
edge-L3-core-sw1>sh ip route
S 10.90.1.251 [1/0] via 131.89.81.20
S 131.89.80.0/23 is directly connected, Null0
O*E1 0.0.0.0/0 [110/11] via 131.89.81.229, 00:07:09, FastEthernet0/1
Above shows we are receiving a default via redistribution as a type 1 into OSPF from
internet-facing-rt1, we have two static routes. One is to the loopback interface of core
internal-L3-core-sw1 via next hop of fw1 (which we redistribute into OSPF to provide
this route to internet-facing-rt1), and the other is a static aggregate to null0 for the
external block, and again, we redistribute this into OSPF to provide this route to
internet-facing-rt1.
edge-L3-core-sw1>sh ip route
S 10.90.1.251 [1/0] via 131.89.81.20
39
O*E1 0.0.0.0/0 [110/11] via 131.89.81.229, 00:07:09, FastEthernet0/1
3.1.4 FW1
Looking at fw1, we created a configuration to simulate key functions that a firewall

performs relative to this study, e.g. NAT, NAT bypass, and static routes. NAT and NAT
bypass were previously discussed in the configuration analysis, so we will only analyze
the route table briefly in this section.
There is a single static route to 10.0.0.0/8 to cover all 10.x nets pointing back to the core
internal-L3-core-sw1. This covers the route needed by bgp from internet-facing-rt1 to
get to core internal-L3-core-sw1s loopback0 (once it makes it to fw1).
Lastly, the default 0/0 route covers everything else going towards edge-L3-core-sw1
fw1>sh ip route
S 10.0.0.0/8 [1/0] via 10.90.7.228
S* 0.0.0.0/0 [1/0] via 131.89.81.17
3.1.5 Internal-L3-core-sw1
Once at core internal-L3-core-sw1, the route table starts to get bigger.
Looking at internal-L3-core-sw1, we first look at the bgp table:
Notice the routes to 10.10.0.1/32 and 10.10.20.1/32 are using AS 13979 even though
the Verizon MPLS router is advertising these same routes, they dont make it back to
internal-L3-core-sw1.
40
There is a /32 route to internet-facing-rt1s loopback0 interface with fw1 as the next
hop, as well as all site specific LAN aggregates - 10.90.0.0/16 and 172.26.64.0/18.
The other bgp routes are WAN blocks.

internal-L3-core-sw1>sh ip bgp
*> 0.0.0.0 131.89.81.253 65535 2350 1000 i
*>i10.10.0.1/32 10.107.246.13 0 100 0 13979 i
*>i10.20.0.1/32 10.107.246.13 0 100 0 13979 i
*> 10.90.0.0/16 0.0.0.0 0 32768 i
*>i10.107.246.12/30 10.90.1.253 0 100 0 i
*>i10.107.246.176/30 10.90.1.253 0 100 0 i
*>i149.181.151.28/30 10.90.1.254 0 100 0 i
*> 131.89.81.253/32 10.90.7.225 0 32768 i
*> 172.26.64.0/18 0.0.0.0 0 32768 i
Next, we first at the OSPF routes in the RIB, and then the overall RIB:
internal-L3-core-sw1>sh ip route ospf
Notice above, per the design, the only routes known via OSPF are the loopback0 IPs of
AVPN-WAN-rt1 and VZB-WAN-rt2 and the /30 transit between AVPN-WAN-rt1 and VZB-
WAN-rt2 (which is also an OSPF transit). The two OSPF transits between internal-L3-
core-sw1 and AVPN-WAN-rt1 and VZB-WAN-rt2 are connected routes that we see in
the full RIB below:
Taken from the show ip route, the 10.10.0.1 and 10.20.0.1 routes show the preferred
next hop using the AVPN.
All the simulated LAN nets - 10.90.10.0/24, 10.90.11.0/24, 10.90.12.0/24 and

10.90.13.0/24 are connected and will be passed under the aggregate 10.90.0.0/16 to
AVPN-WAN-rt1 and VZB-WAN-rt2.
41
The default route is a bgp route via internet-facing-rt1s loopback0 interface, and there
is a static route to internet-facing-rt1s loopback0 interface (131.89.81.253) with a next
hop of fw1 (IP @ 10.90.7.225)
internal-L3-core-sw1>sh ip route
B 149.181.151.28 [200/0] via 10.90.1.254, 00:09:09
S 172.26.64.0 is directly connected, Null0
B 10.10.0.1/32 [200/0] via 10.107.246.13, 00:08:53
B 10.20.0.1/32 [200/0] via 10.107.246.13, 00:08:53
B 10.107.246.176/30 [200/0] via 10.90.1.253, 00:08:53
B 10.107.246.12/30 [200/0] via 10.90.1.253, 00:08:54
S 131.89.81.253 [1/0] via 10.90.7.225
B* 0.0.0.0/0 [20/0] via 131.89.81.253, 00:09:10
internal-L3-core-sw1>
42
3.1.6 AVPN-WAN-rt1
First, lets look at the bgp table:
AVPN-WAN-rt1>sh ip bgp
*> 0.0.0.0 131.89.81.253 0 100 40000 2350 1000 i
* 10.107.246.13 0 0 13979 i
*> 10.10.0.1/32 10.107.246.13 0 0 13979 i
*> 10.20.0.1/32 10.107.246.13 0 0 13979 i
*>i10.90.0.0/16 10.90.1.251 0 100 40000 i
* 10.107.246.12/30 10.107.246.13 0 0 13979 i
*> 0.0.0.0 0 32768 i
*>i149.181.151.28/30
10.90.1.254 0 100 0 i
*>i131.89.81.253/32 10.90.7.225 0 100 40000 i
*>i172.26.64.0/18 10.90.1.251 0 100 40000 i
We see there are *three* default routes in the bgp table, one which is preferred (and
installed in the in RIB) to 131.89.81.253 (Internet-facing-rt1). This is due to setting the
weight on AVPN-WAN-rt1s bgp configuration to 40000 on its BGP connection to
internal-L3-core-sw1. Although the as-path is longer using the path to internet-facing-
rt1, this design works due to weight manipulation. This is yet another critical tuning
configuration.
If this wasnt configured, then AVPN-WAN-rt1 would prefer the AVPN for the default
route
Theres a second default which is the first backup default pointing to the AVPN neighbor
at 10.107.246.13.
There is a third default that AVPN-WAN-rt1 knows about is via iBGP (from VZB-WAN-rt2,
via Verizon MPLS), and when needed, the bgp default path selection takes effect, which
prefers the eBGP route over the iBGP route, so if the first two routes drop out, then the
third choice would be the Verizon MPLS default route.
43
See final chapter about bgp path selection.
Additional relevant BGP routes are shown and explained below:

*> 10.10.0.1/32 10.107.246.13 0 0 13979 i
*> 10.20.0.1/32 10.107.246.13 0 0 13979 i
*>i10.90.0.0/16 10.90.1.251 0 100 40000 i
*>i131.89.81.253/32 10.90.7.225 0 100 40000 i
*>i172.26.64.0/18 10.90.1.251 0 100 40000 i
Above, we see the two routes (10.10.0.1/32 and 10.20.0.1/32) that are duplicate
routes, e.g. they are being advertised from both the AVPN and Verizon MPLS clouds.
This is how we should see it in the BGP table with the AVPN being the route that is used,
due to as-path prepending on Verizon MPLS routes, which simulates the environment
for remote site networks
Next, we see the aggregate 10.90.0.0/16 and 172.26.64.0/18 nets with a next hop of
internal-L3-core-sw1s loopback0 interface
Finally, we see a route to the loopback0 of the internet-facing-rt1s loopback0 interface,

which is very important, as this is the next hop for the default route.
Next, we look at the OSPF routes in the RIB:
AVPN-WAN-rt1>sh ip route ospf
Above, we see that there are only the two /30 transit nets (used for ospf adjacency to
VZB-WAN-rt2 and internal-L3-core-sw1) and then only the loopback0 IPs for VZB-WAN-
rt2 and internal-L3-core-sw1
44
Finally we look at the full RIB:
AVPN-WAN-rt1>sh ip route
B 149.181.151.28 [200/0] via 10.90.1.254, 00:10:45
B 172.26.64.0 [200/0] via 10.90.1.251, 00:10:45
B 10.10.0.1/32 [20/0] via 10.107.246.13, 00:10:45
B 10.20.0.1/32 [20/0] via 10.107.246.13, 00:10:45
B 10.90.0.0/16 [200/0] via 10.90.1.251, 00:10:45
B 131.89.81.253 [200/0] via 10.90.7.225, 00:10:41
B* 0.0.0.0/0 [200/0] via 131.89.81.253, 00:10:41
AVPN-WAN-rt1>
Above, Ive highlighted the bgp routes, and you can see all LAN and WAN routes, and
the default route are bgp routes.
45
3.1.7 VZB-WAN-rt2
VZB-WAN-rt2>sh ip bgp
*>i0.0.0.0 131.89.81.253 0 100 40000 2350 1000 i
* 149.181.151.29 0 0 65300 65300 65300 65300 65300
65300 i
*>i10.10.0.1/32 10.107.246.13 0 100 0 13979 i
* 149.181.151.29 0 0 65300 65300 65300 65300 65300
65300 i
*>i10.20.0.1/32 10.107.246.13 0 100 0 13979 i
* 149.181.151.29 0 0 65300 65300 65300 65300 65300
65300 i
*>i10.90.0.0/16 10.90.1.251 0 100 40000 i
*>i10.107.246.12/30 10.90.1.253 0 100 0 i
*>i10.107.246.176/30
10.90.1.253 0 100 0 i
* 149.181.151.28/30
149.181.151.29 0 0 65300 65300 65300 65300 65300
65300 i
*> 0.0.0.0 0 32768 i
*>i131.89.81.253/32 10.90.7.225 0 100 40000 i
*>i172.26.64.0/18 10.90.1.251 0 100 40000 i
We see there are *three* default routes in the bgp table, one which is preferred (and
installed in the in RIB) to 131.89.81.253 (Internet-facing-rt1).
Due to as-path prepending on VZB-WAN-rt2, we didnt actually need to set the weight
on the VZB-WAN-rt2 to neighbor internal-L3-core-sw1, but to keep things clean and
symmetrical in the real world (e.g. if L3-CORE-SW2 existed, e.g. redundant cores) we still
want this configuration, so if L3-CORE-SW2 existed, we can set the weight to a little bit
below that, e.g. 35000 and ensure symmetrical routing.
46
Theres a second default which is the first backup default pointing to the Verizon
neighbor, and this is due to bgp path selection preferring an eBGP route over an iBGP
route.
There is a third default that VZB-WAN-rt2 knows about via iBGP (from AVPN-WAN-rt1),
and when needed, the bgp default path selection takes effect, which prefers the eBGP
route over the iBGP route, so if the first two routes drop out, then the third choice
would be the AVPN default route known via iBGP.
See final chapter about bgp path selection.
Additional relevant BGP routes are shown and explained below:
*>i10.10.0.1/32 10.107.246.13 0 100 0 13979 i
* 149.181.151.29 0 0 65300x6 i
*>i10.20.0.1/32 10.107.246.13 0 100 0 13979 i
* 149.181.151.29 0 0 65300x6 i
*>i10.90.0.0/16 10.90.1.251 0 100 40000 i
*>i131.89.81.253/32 10.90.7.225 0 100 40000 i
*>i172.26.64.0/18 10.90.1.251 0 100 40000 i
Above, we see the two routes (10.10.0.1/32 and 10.20.0.1/32) that are duplicate
routes, e.g. they are being advertised from both the AVPN and Verizon MPLS clouds.
Over at VZB-WAN-rt2, we see both routes, because, due to as-path prepending, the
AVPN is our first choice (shorter as-path) and the Verzizon eBGP neighbor is second
choice (which has AS 65300 x 6 in its path due to policy)
Next, we see the aggregate 10.90.0.0/16 and 172.26.64.0/18 nets with a next hop of
internal-L3-core-sw1s loopback0 interface
Finally, we see a route to the loopback0 of internet-facing-rt1s loopback0 interface,

which is very important, as this is the next hop for the default route.
47
Next, we look at the OSPF routes in the RIB:
VZB-WAN-rt2>sh ip route ospf
VZB-WAN-rt2>
Above, we see that there are only the two /30 transit nets (used for ospf adjacency to
AVPN-WAN-rt1 and internal-L3-core-sw1) and the loopback0 IPs for AVPN-WAN-rt1 and
internal-L3-core-sw1.
VZB-WAN-rt2>sh ip route
B 172.26.64.0 [200/0] via 10.90.1.251, 00:11:52
B 10.10.0.1/32 [200/0] via 10.107.246.13, 00:11:36
B 10.20.0.1/32 [200/0] via 10.107.246.13, 00:11:36
B 10.107.246.176/30 [200/0] via 10.90.1.253, 00:11:36
B 10.90.0.0/16 [200/0] via 10.90.1.251, 00:11:52
B 10.107.246.12/30 [200/0] via 10.90.1.253, 00:11:36
48
B 131.89.81.253 [200/0] via 10.90.7.225, 00:11:53
B* 0.0.0.0/0 [200/0] via 131.89.81.253, 00:11:52
VZB-WAN-rt2>
Above, Ive highlighted the bgp routes, and you can see all LAN and WAN routes, and
the default route are bgp routes.
3.1.8 AVPN PE Router
AVPN-PER>sh ip bgp
* 0.0.0.0 10.107.246.14 0 65523 2350 1000 i
*> 0.0.0.0 32768 i
*> 10.10.0.1/32 0.0.0.0 0 32768 i
*> 10.20.0.1/32 0.0.0.0 0 32768 i
*> 10.90.0.0/16 10.107.246.14 0 65523 i
* 10.107.246.12/30 10.107.246.14 0 0 65523 i
*> 0.0.0.0 0 32768 i
*> 10.107.246.176/30
10.107.246.14 0 0 65523 i
*> 149.181.151.28/30
10.107.246.14 0 65523 i
*> 131.89.81.253/32 10.107.246.14 0 65523 i
*> 172.26.64.0/18 10.107.246.14 0 65523 i
We see there are *two* default routes in the bgp table, one which is preferred (and
installed in the in RIB) is a route to null0 (local static route for test purposes) The second
default route is coming from the CE (AVPN-WAN-rt1) and shows the correct as-path of
65523, 2350, 1000.
We can also verify we have a route to the LAN networks 10.90.0.0/16 and
172.26.64.0/18, and to internet-facing-rt1s loopback0 IP
49
AVPN-PER>sh ip route
B 149.181.151.28 [20/0] via 10.107.246.14, 00:14:46
B 172.26.64.0 [20/0] via 10.107.246.14, 00:14:46
B 10.107.246.176/30 [20/0] via 10.107.246.14, 00:14:46
B 10.90.0.0/16 [20/0] via 10.107.246.14, 00:14:46
B 131.89.81.253 [20/0] via 10.107.246.14, 00:14:15
AVPN-PER>
Above, I have highlighted relevant routes.
50
3.1.9 VZB PE Router
Verizon-PER>sh ip bgp
* 0.0.0.0 149.181.151.30 0 65523 65523 65523 65523 65523 65523 2350 1000 i
*> 0.0.0.0 0 32768 i
* 10.10.0.1/32 149.181.151.30 0 65523 65523 65523 65523 65523 65523 13979 i
*> 0.0.0.0 0 32768 i
* 10.20.0.1/32 149.181.151.30 0 65523 65523 65523 65523 65523 65523 13979 i
*> 0.0.0.0 0 32768 i
*> 10.90.0.0/16 149.181.151.30 0 65523 65523 65523 65523 65523 65523 i
*> 10.107.246.12/30 149.181.151.30 0 65523 65523 65523 65523 65523 65523 i
*> 10.107.246.176/30
149.181.151.30 0 65523 65523 65523 65523 65523 65523 i
* 149.181.151.28/30
149.181.151.30 0 0 65523 65523 65523 65523 65523 65523 i
*> 0.0.0.0 0 32768 i
*> 131.89.81.253/32 149.181.151.30 0 65523 65523 65523 65523 65523 65523 i
*> 172.26.64.0/18 149.181.151.30 0 65523 65523 65523 65523 65523 65523 i
We see there are *two* default routes in the bgp table, one which is preferred (and
installed in the RIB) is a route to null0 (local static route for test purposes) The second
default route is coming from the CE (VZB-WAN-rt2) and shows the correct as-path of
65523x6, 2350, 1000.
51
Verizon-PER>sh ip route
B 172.26.64.0 [20/0] via 149.181.151.30, 00:15:12
B 10.90.0.0/16 [20/0] via 149.181.151.30, 00:15:12
B 10.107.246.12/30 [20/0] via 149.181.151.30, 00:15:12
B 131.89.81.253 [20/0] via 149.181.151.30, 00:15:12
Above, I have highlighted relevant routes.
3.2 TEST THE SOLUTION (FAILOVER AND FALLBACK)
This chapter validates that the default routing works as designed. (As well as all routing)
First, lets validate that bi-directional routing & NAT are good to go before starting the
failover and fallback process.
3.2.1 Test Connectivity to the Internet
First we traceroute from core internal-L3-core-sw1 out to the simulated internet test-
net that resides on the ISP router (but no explicit route to 14.1.1.1 exists), so we use the
default route, traversing fw1, then edge-L3-core-sw1, then internet-facing-rt1, and
finally to the ISP router to get there.
52
internal-L3-core-sw1>traceroute 14.1.1.1
type escape sequence to abort.
tracing the route to 14.1.1.1
1 10.90.7.225 104 msec 104 msec 76 msec
2 131.89.81.17 104 msec 104 msec 76 msec
3 131.89.81.229 104 msec 104 msec 76 msec
4 1.1.1.2 104 msec 104 msec
Now, well ping the same IP, which validates the ISP router has a route back to our
external block.
internal-L3-core-sw1>ping 14.1.1.1
type escape sequence to abort.
sending 5, 100-byte ICMP Echos to 14.1.1.1, timeout is
!!!!!
success rate is 100 percent (5/5), route-trip min/avg/max
internal-L3-core-sw1>
Next we go into fw1 router to make sure NAT is working properly:
FW1>sh ip nat translation
Pro Inside global Inside local Outside local Outside global
udp 131.89.81.29:49170 10.90.7.228:49170 14.1.1.1:33437 14.1.1.1:33437
udp 131.89.81.29:49171 10.90.7.228:49171 14.1.1.1:33438 14.1.1.1:33438
udp 131.89.81.29:49172 10.90.7.228:49172 14.1.1.1:33439 14.1.1.1:33439
udp 131.89.81.29:49173 10.90.7.228:49173 14.1.1.1:33440 14.1.1.1:33440
udp 131.89.81.29:49174 10.90.7.228:49174 14.1.1.1:33441 14.1.1.1:33441
udp 131.89.81.29:49175 10.90.7.228:49175 14.1.1.1:33442 14.1.1.1:33442
FW1>
53
Above, we can see that NAT on the FW is changing our source address from the internal-
L3-core-sw1 internal LAN IP of 10.90.7.228 (FW transit) to the public external block IP of
131.89.81.29, which we are advertising to the ISP router. We then verify that the
outside local/global IP is the one we are pinging - 14.1.1.1
Now that we know NAT is working, and routed connectivity exists from the ISP to the
public external block, and to the ISP (default routing), we can begin failover and fallback
testing.
3.2.2 Failover from ISP to AVPN
Pre-failover Route Table
From the internal core router:

B* 0.0.0.0/0 [20/0] via 131.89.81.253, 00:05:10
Network Next hop Weight Path
*> 0.0.0.0 131.89.81.253 65535 2350 1000 i
Pre-failover Traffic Flow Diagram

AVPN Verizon MPLS
AS 13979 AS 65300
MPLS layer
EBGP
EBGP
10.107.246.14 IBGP
WAN link
149.181.151.30
copper copper
AS 65523
BGP AS 1000
10.90.7.197/30 10.90.7.198/30
Internet
OSPF 2350
BGP 2350 Area 0
EBGP
internet-facing-rt1
10.90.7.240/30
Internet bound traffic flow ospf cost 100
INTERNET TRAFFIC FLOW

OSPF 2350
Area 0
edgeL3-CORE-SW1 FW1
Edge layer
Core layer
54
Post-failover Route Table Analysis
After shutting down the ISP link, the following route table convergence is shown below,
failing over to next-hop of the AVPN router via AS 13979.
From the Internal core L3 switch:
Network Next hop Metric LocPrf Weight Path
*> i0.0.0.0 10.107.246.13 0 100 0 13979 i
Post-failover Traffic Flow Diagram

AVPN Verizon MPLS
AS 13979 AS 65300
MPLS layer
EBGP
EBGP
IBGP
WAN link
149.181.151.30
copper copper
AS 65523
BGP AS 1000 INTERNET BOUND TRAFFIC FOLLOWS 10.107.246.14
DEFAULT ROUTE INTO THE MPLS CLOUD

10.90.7.197/30 10.90.7.198/30
Internet
AVPN-WAN-rt1 OSPF 2350 VZB-WAN-rt2

BGP 2350 Area 0
EBGP
internet-facing-rt1
10.90.7.240/30
ospf cost 100
OSPF 2350
Area 0
edgeL3-CORE-SW1 FW1
Edge layer
Core layer
55
3.2.3 Failover from AVPN to VZB
We now failover from the AVPN MPLS Primary WAN to the Verizon backup MPLS WAN
default route.
Post-failover Route Table Analysis
You see now that the default route next hop is via AS 65300 x6 (Verizon MPLS) and the
route in the RIB will now point to a next hop of 149.181.151.29 (Verizon MPLS) even
though we are viewing core internal-L3-core-sw1s route table
From the Internal core L3 switch:
Network Next hop Metric LocPrf Weight Path
*> i0.0.0.0 149.181.151.29 0 100 0
65300 65300 65300 65300 65300 65300 i
Post-failover Traffic Flow Diagram

AVPN Verizon MPLS
AS 13979 AS 65300
MPLS layer
EBGP
EBGP
10.107.246.14 IBGP
WAN link
copper copper
AS 65523
BGP AS 1000 149.181.151.30
10.90.7.197/30 10.90.7.198/30
Internet
OSPF 2350
BGP 2350 Area 0
EBGP
internet-facing-rt1
10.90.7.240/30
ospf cost 100
OSPF 2350
Area 0
edgeL3-CORE-SW1 FW1
Edge layer
Core layer
56
3.2.4 Fallback from VZB to ISP
We now bring the ISP router back into service (AS 1000)
Post-fallback Route Table Analysis
Now, we can see that the default route again points back to the loopback0
(131.89.81.253) IP of internet-facing-rt1 via AS 2350, 1000
From the internal core router:
B* 0.0.0.0/0 [20/0] via 131.89.81.253, 00:00:21
Network Next hop Weight Path
*> 0.0.0.0 131.89.81.253 65535 2350 1000 i
Post-fallback Traffic Flow Diagram

AVPN Verizon MPLS
AS 13979 AS 65300
MPLS layer
EBGP
EBGP
10.107.246.14 IBGP
WAN link
149.181.151.30
copper copper
AS 65523
BGP AS 1000
10.90.7.197/30 10.90.7.198/30
Internet
OSPF 2350
BGP 2350 Area 0
EBGP
internet-facing-rt1
10.90.7.240/30
Internet bound traffic flow ospf cost 100

OSPF 2350
Area 0
edgeL3-CORE-SW1 FW1
Edge layer
Core layer
The above completes the lab verification, and final traffic flow after fallback.
In the final chapter, we will go over a few gotchas to be aware of when implementing a
BGP based solution within an enterprise network architecture.
57
4 ADDITIONAL DESIGN CONSIDERATIONS
The final chapter covers a few things to be aware of, and/or to consider when
implementing a solution using BGP across a firewall using eBGP multi-hop.
4.1 GOTCHAS
Routes to all loopback0s (via static or IGP) is critical this will be the next hop in
the default route in BGP, even though it will require a recursive route lookup.
This is also used for establishing the eBGP neighbor between internal-L3-core-
sw1 and internet-facing-rt1
The internal core routers Loopback 0 needs to bypass NAT in the firewall
4.2 BGP BEST PATH SELECTION PROCESS (FROM CISCO DOCUMENTATION)
This list below provides the rules that BGP uses to determine the best path from highest
to lowest, as documented by Cisco Systems:
1. Prefer the path with the highest WEIGHT.
Note: WEIGHT is a Cisco-specific parameter. It is local to the router on which it is configured.
2. Prefer the path with the highest LOCAL_PREF.
Note: A path without LOCAL_PREF is considered to have had the value set with the bgp default
local-preferencecommand, or to have a value of 100 by default.
3. Prefer the path that was locally originated via a network or aggregate BGP subcommand or
through redistribution from an IGP.
Local paths that are sourced by the network or redistribute commands are preferred over local
aggregates that are sourced by the aggregate-address command.
58
4. Prefer the path with the shortest AS_PATH.
Note: Be aware of these items:
o This step is skipped if you have configured the bgp bestpath as-path ignore command.
o An AS_SET counts as 1, no matter how many ASs are in the set.
o The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the
AS_PATH length
5. Prefer the path with the lowest origin type.
Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE.
6. Prefer the path with the lowest multi-exit discriminator (MED).
Note: Be aware of these items:
o This comparison only occurs if the first (the neighboring) AS is the same in the two paths.
Any confederation sub-ASs are ignored.
In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the
same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored.
o If bgp always-compare-med is enabled, MEDs are compared for all paths.
You must disable this option over the entire AS. Otherwise, routing loops can occur.
o If bgp bestpath med-confed is enabled, MEDs are compared for all paths that consist
only of AS_CONFED_SEQUENCE.
These paths originated within the local confederation.
o THE MED of paths that are received from a neighbor with a MED of 4,294,967,295 is
changed before insertion into the BGP table. The MED changes to to 4,294,967,294.
o THE MED of paths that are received from a neighbor with a MED of 4,294,967,295 are
considered valid and are inserted into BGP table with effect to Codes fixed for Cisco bug
ID CSCef34800.
o Paths received with no MED are assigned a MED of 0, unless you have enabled bgp
bestpath med missing-as-worst .
If you have enabled bgp bestpath med missing-as-worst , the paths are assigned a
MED of 4,294,967,294.
If you have enabled bgp bestpath med missing-as-worst , the paths are assigned a
MED of 4,294,967,295 with effect to Codes fixed for Cisco bug ID CSCef34800.
o The bgp deterministic-med command can also influence this step.
Refer to How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection for a
demonstration.
7. Prefer eBGP over iBGP paths.
If bestpath is selected, go to Step 9 (multipath).
59
Note: Paths that contain AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the
confederation. Therefore, these paths are treated as internal paths. There is no distinction between
Confederation External and Confederation Internal.
8. Prefer the path with the lowest IGP metric to the BGP next hop.
Continue, even if bestpath is already selected.
9. Determine if multiple paths require installation in the routing table for BGP Multipath.
Continue, if bestpath is not yet selected.
10. When both paths are external, prefer the path that was received first (the oldest one).
This step minimizes route-flap because a newer path does not displace an older one, even if the
newer path would be the preferred route based on the next decision criteria (Steps 11, 12, and 13).
Skip this step if any of these items is true:
o You have enabled the bgp best path compare-routerid command.

o The router ID is the same for multiple paths because the routes were received from the
same router.
o There is no current best path.
The current best path can be lost when, for example, the neighbor that offers the path
goes down.
11. Prefer the route that comes from the BGP router with the lowest router ID.
The router ID is the highest IP address on the router, with preference given to loopback addresses.
Also, you can use thebgp router-id command to manually set the router ID.
Note: If a path contains route reflector (RR) attributes, the originator ID is substituted for the router
ID in the path selection process.
12. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster
list length.
This is only present in BGP RR environments. It allows clients to peer with RRs or clients in other
clusters. In this scenario, the client must be aware of the RR-specific BGP attribute.
13. Prefer the path that comes from the lowest neighbor address.
This address is the IP address that is used in the BGP neighbor configuration. The address
corresponds to the remote peer that is used in the TCP connection with the local router.
60
5 APPENDIX D: CONTACT INFORMATION
5.1 AT&T CONSULTING
Brett Michael Spunt

Senior Consultant, AT&T Consulting, Inc.
1150 South Olive St.
Los Angeles, CA 90015
brett.spunt@att.com
61

BGP Based Default Routing White-Paper PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BGP Based Default Routing White-Paper PDF

Uploaded by

Copyright:

Available Formats

AT&T Consulting Solutions, Inc.

BGP Based Default Routing

2.1 LAB ENVIRONMENT

2.1.1 Network Topology | Network Diagram

Primary WAN provider Secondary WAN provider

/30 Routed link L3-CORE-SW1

So, for example, on core internal-L3-core-sw1 or AVPN-WAN-rt1, the default routes

This will be covered under the section where we analyze internal-L3-core-sw1s

The router configuration specific to the solution is shown below:

ip address 131.89.81.253 255.255.255.255

description connected to edge-L3-core-sw1

ip address 131.89.81.229 255.255.255.252

ip ospf network point-to-point

ip ospf 2350 area 0.0.0.0

description ### Internet Circuit ###

ip address 1.1.1.1 255.255.255.252

router ospf 2350

area 0 authentication message-digest

network 131.89.81.228 0.0.0.3 area 0

network 131.89.81.253 0.0.0.0 area 0

default-information originate metric 1 metric-type 1

router bgp 2350

bgp router-id 131.89.81.253

network 1.1.1.0 mask 255.255.255.252

network 131.89.80.0 mask 255.255.254.0

neighbor 1.1.1.2 remote-as 1000

neighbor 1.1.1.2 soft-reconfiguration inbound

neighbor 1.1.1.2 prefix-list default-route-in in

neighbor 1.1.1.2 prefix-list external-block-only out

neighbor 10.90.1.251 remote-as 65523

neighbor 10.90.1.251 eBGP-multihop 255

neighbor 10.90.1.251 update-source Loopback0

neighbor 10.90.1.251 soft-reconfiguration inbound

ip prefix-list default-route-in seq 5 permit 0.0.0.0/0

ip prefix-list external-block-only seq 5 permit 131.89.80.0/23

OSPF uses the loopback0 interface as the OSPF router ID.

The /32 loopback0 interface is advertised to edge-L3-core-sw1 to assist in getting the

Internet-facing-rt1 OSPF specific config snippet:

network 131.89.81.228 0.0.0.3 area 0

## transit net to edge-L3-core-sw1 to establish OSPF session

network 131.89.81.253 0.0.0.0 area 0

default-information originate metric 1 metric-type 1

## get default route advertised to edge-L3-core-sw1 as type 1, which is preferred over

BGP also uses the loopback0 interface as the router ID.

Neighbor 1.1.1.2 prefix-list default-route-in in

ip prefix-list default-route-in seq 5 permit 0.0.0.0/0

Neighbor 1.1.1.2 prefix-list external-block-only out

ip prefix-list external-block-only seq 5 permit 131.89.80.0/23

Since there is no additional prefix-list seq number, everything else is denied.

Internet-facing-rt1 BGP specific config snippet:

neighbor 10.90.1.251 eBGP-multihop 255

neighbor 10.90.1.251 update-source Loopback0

Lastly, on internet-facing-rt1 under BGP, the default-information originate is all that is

The router configuration specific to the solution is shown below:

ip address 131.89.81.251 255.255.255.255

description TRANSIT- FW1::131.89.81.16/28

ip address 131.89.81.17 255.255.255.240

description connected to internet-facing-rt1

ip address 131.89.81.230 255.255.255.252

ip ospf network point-to-point

ip ospf 2350 area 0.0.0.0

router ospf 2350

redistribute static subnets route-map static-to-ospf