In the previous article, we created an interesting situation with an iBGP configuration. In that example, we made Edge2 aware of a route via BGP that the intermediary hops would not see. In this article, we will fix this problem using MPLS and label switching. Before getting started, I feel compelled to rename these routers based on their target role in an MPLS our network.
- MPLS – multiprotocol label switching – using labels or tags to forward packets over a network (as opposed to traditional destination based routing)
- LSR – Label switch router (transit router), aka P router, switches labels
- LER – Label edge router or Edge LSR, often called a PE router, may push (impose) labels
- LSP – Label Switched Path
- Push – insert/impose a lable
- Swap – change a label
- Pop – remove a label
As we left it in our previous configuration, the router on the right sees a route to 126.96.36.199 via BGP but it cannot reach that destination. It is worth mentioning that I disabled BGP sync (following the last example I shared in the previous article). Continue reading
Posted in Design
Yes, we are going to talk about destination routing. I know it sounds boring and archaic, and it is. But it is also necessary to contrast against another topic that I intend to introduce. As I scour PacketU, I see a substantial number of page views on articles about segmentation and VRFs. One thing I often tell my customers is that once a VRF-lite implementation reaches a certain scale, the configuration can become unwieldy.
This article is a first in a series where we will discuss MPLS. This technology enables VPNv4 and is a common method of networking. MPLS can connect VRFs without compromising their segmentation characteristics. In this first article, we are going to examine traditional destination-based routing. This is meant to nail down some of the typical behavior of an IPv4 routed network. These characteristics will not go away entirely, but it is important to understand how routing changes as we introduce label switching concepts.
Throughout this series, we will use a common topology. In later articles, we will expand as necessary to introduce the relevant topics.
To illustrate a point, I have pre-configured OSPF on all links and loopback 0 of all routers. In a minute, I will bring up an iBGP session between the edge nodes, configure another loopback interface and advertise it via BGP only. Continue reading
Posted in Design
In the last article, we performed a packet walk of a simple VPNv4 network. This article will expand our deployment by allowing the CE_Sites to advertise their own routes via BGP. For this configuration, we will use some overlapping and some unique private AS numbers.
One thing that must be considered is whether or not the same BGP AS is used throughout a given VRF. For example, if we use 64512 at both CE_Site_1 and CE_Site_2 the BGP routes will be dropped as they are advertised toward the customer site. This is demonstrated by doing a simple configuration to advertise 188.8.131.52 from CE_Site_1.
CE_Site_1 BGP Configuration
Posted in Design
As networks begin leveraging intelligent DNS products, there is often a need to do some magic at the Internet edge to redirect to the target provider. Some products actually have this capability embedded. Even though the ASA doesn’t specifically have a defined configuration to do this, we can achieve the same outcome with a few simple NAT rules.
An initial thought would be to build a NAT policy as follows
//define the objects
object network obj_any
subnet 0.0.0.0 0.0.0.0
object network Umbrella1
object network Umbrella2
object service UDP-53
service udp destination eq domain
//define the nat rules
nat (any,outside) source dynamic any interface destination static obj_any Umbrella1 service UDP-53 UDP-53
nat (any,outside) source dynamic any interface destination static obj_any Umbrella2 service UDP-53 UDP-53
This will sort of work. However, there are two words of caution I would share with this approach. First, DNS sometimes leverages TCP. Second, the last NAT rule will never be used. In this case, even requests to 184.108.40.206 would match the first rule and be re-written to the destination 220.127.116.11. Continue reading
Posted in How-To
I recently listened to Packet Pushers show 395 recently. It is a great discussion on optical networking. One thing I wanted to make everyone aware of was a series of comments on the varying quality of optics and some justification around the premium prices often found on vendor branded optics. While the entire episode is worth a listen, the discussion around vendor optics begins at about 35:20 into the recording.
I work for a vendor and it is doubtful that people would view my opinion as unbiased. I encourage everyone to take a listen below and form their own opinions.
If you are a tech guy or girl, the Packet Pushers Podcast is a perfect addition to the podcatcher. Continue reading
A few days ago I shared an article that described redirecting DNS requests with ASA. A good use case for this might be if an organization is using Cisco Umbrella but there is no way to get every host is pointed toward the correct DNS server(s) in a timely manner. In that case, a configuration of destination NAT in the ASA can force those misconfigured clients to use one of the OpenDNS addresses.
This article is very similar, but we will share a method for doing this with Firepower Threat Defence. The concept is the same but all configuration is done in Firepower Management Console. Before starting on the NAT configuration, it is important to configure the following network objects (Objects, Object Management, Network).
- obj_any – 0.0.0.0/0
- Umbrella1 – 18.104.22.168
- Umbrella2 – 22.214.171.124
It is also important to confirm the existence of two port objects (Objects, Object Management, Network).
- DNS_over_TCP – TCP Port 53
- DNS_over_UDP – UDP Port 53
Most of the configuration will be done on the NAT policy for the device we are managing (Device, NAT, select edit for the appropriate NAT policy). Continue reading
Posted in How-To