As I mentioned in a previous post, I have been studying the materials for the Cisco CCDE. One thing that has come up only a time or two is that of MTU. MTU, or maximum transmission unit, is the maximum size a chunk of data can be for a given interface. In this article, we are speaking specifically of IP MTU and this is an important distinction that I will clarify later. Network design should incorporate a clear understanding of MTU challenges and operators need to understand what to look for when it is not properly built and configured.
A simplistic example of a problematic design is when there is a link with a smaller MTU somewhere between two endpoints capable of creating larger packets (see the image below). While this environment may work fine, understanding the interaction required between the hosts and the network devices is very important to network design.
A few years ago I wrote an article that outlined some of the behavior that can be witnessed when there are MTU discovery issues. Let’s quickly recount what path MTU discovery (PMTU-D) is, how it works, how it fails and some logic around appropriate design. Continue reading
I have spent some time studying the CCDE materials. One broken design example that has come up involves route reflector clients that don’t align with the physical topology. This article examines that example and some solutions to the problem.
To illustrate this example we have built the topology below. I used loopback addresses 18.104.22.168 through 22.214.171.124 (based on csr1000v-x). The router on the top is a eBGP neighbor with csr1000v-1 and csr1000v-2. The four routers forming a square in the center have an initial configuration of OSFP and BGP (iBGP as shown). Both Route Reflectors are peered with both clients.
Route Reflector Initial Configuration
Posted in Design
In the last article, Learning TrustSec, An Introduction to Inline Tagging, we took a quick look at manual configuration of SGT Inline Tagging in a manual configuration. We also performed some validation with show commands and proved the operation by enabling enforcement.
In today’s article, we will perform slightly deeper validation of the inline imposition itself. For this process, we will use Netflow and Embedded Packet Capture. I happen to know that there is already EIGRP traversing the link that will help produce some output. Let’s just jump right in with a very basic Netflow configuration.
In my last article, Basic TrustSec – Implementing Manual SGTs and SGACLs,
we talked about a basic TrustSec configuration. In that example, we shared the understanding of having two devices connected to a single switch and enforcing traffic policies via SGACL. We know that there are more scalable and automated ways to configure TrustSec enabled networks, but our goal is to work toward understanding the building blocks.
In today’s article, we will expand our knowledge and connect the two devices to different switches. The trunks between these switches will be configured to carry the associated source SGT’s (Security Group Tags). The topology used for this discussion is as follows.
Trustsec is a mature and interesting policy mechanism available in most Cisco gear. The features and capabilities vary depending on device type and class. One of the frustrations I have is that almost every Trustsec reference I find focuses on the use of ISE. While I consider ISE a key component, I think a manual configuration is a better way to understand the components of the solution.
This post is the first in a series that will go through the configuration of Trustsec in various places in the network. I hope to examine classification and tag assignment, propagation techniques and enforcement. Ultimately, I will introduce ISE but it will be the tool that makes this technology dynamic and robust. The goal is to build a better foundation by taking a step by step approach into the world of Trustsec.
In this article, I will simply build a network with a Catalyst 9300 and two devices. One device will be assigned an SGT of 2 and the other will receive an SGT of 3. I understand that many are concerned about the fact that they don’t have this class of switch at the access layer. Future articles will address how Trustsec can be leveraged with varying device types in different places in the network.
Just a quick thought here today. Thinking about the organization you work for or the organizations you work with, how would you say they view technology?
- Key to Success – Technology is an enabler AND a primary differentiator
- Important – The core business requires a commitment to technology to succeed
- Just Another Budget Item – Technology is a necessary evil