In the previous article, we took a look at building a simple label switched path (LSP) through an MPLS network. This article takes the configuration a step further and leverages multiple labels to connect and isolate VRFs over an MPLS core. This is known as MPLS VPNv4. My goal is to introduce a method to bring together VRF segmentation concepts and provide a framework for a scalable deployment.
Before we get started, I am going to rename the routers once again based on their target function. An LER in a VPNv4 configuration is known as a PE node. An LSR router is known as a P node. I am also introducing CE (customer edge) nodes into the topology.
Desired End State
In this example, we will allow CE_Site_1 to communicate with CE_Site_2. Likewise, we want CE_Site_3 to communicate with CE_Site_4.
- P Router – provider router, is considered transit in a label switched path, the term is often used interchangeably with LSR
- PE Router – provider edge router and sits on the provider side of the provider/customer interconnection. Has most of the intelligence and configuration for an LSP and allows a scale-out architecture. The term PE is more common but may be used interchangeably with LER
- CE Router – customer edge router, is the router that sits on the customer side of the provider/customer interconnection
- LDP – Label Distribution Protocol – Establishes adjacencies and exchanges label mapping information between MPLS nodes
- PHP – Penultimate Hop Popping, removing (pop operation) an MPLS label at the next to last hop
Posted in Design
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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 would match the first rule and be re-written to the destination 184.108.40.206. 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