0

Creating a Dynamic Lab Environment with vEOS and GNS3 – Part II

SETTING UP A DHCP AND FILE SERVER FOR USE WITH ZTP

0

Creating a Dynamic Lab Environment with vEOS and GNS3 – Part I

GETTING STARTED

Preliminary Installation Setup

Creating the Management Network

SETTING UP vEOS

Creating a Base Image

0

How Rapid Spanning Tree Protocol (RSTP) Handles Topology Changes

For this exploration I'm using Arista's Virtual Extensible Operating System (vEOS) version 4.15.0F running in GNS3(Which is pretty awesome).  The virtual switches have been configured in rapid-pvst mode.

Here is the topology:
EtherSwitches have been added only to capture traffic off monitoring sessions set up on Switch1 and Switch2 to look at in Wireshark.  The Ubuntu server can be ignored for the purposes of this blog entry.

Only VLAN 1 is present on all switches and Switch1 is configured to be the primary root, while Switch2 is configured to be the secondary. Here's the current state of the network:

First it's important to note that only a single thing will trigger a topology change event - the transition of a non-Edge port from a non-Forwarding to a Forwarding state. Why?  Because this newly Forwarding port could possibly provide a better path to a given destination MAC address than there was before, and the CAM table will need to be updated to reflect that and prevent the same MAC being displayed on more than one port.  It sounds strange that a loss of a Forwarding port doesn't trigger a topology change event, but think about it - in a Continue reading

0

BGP in an Arista Data Center

The following is a practical analysis of the use of BGP in the DC on Arista platforms based largely on Petr Lapukhov's work with BGP in hyperscale DCs

Why Layer 3 (L3)?

There are several reasons to run a L3 routing protocol over legacy layer 2 (L2) designs in the data center. Leveraging standards-based routing protocols to avoid vendor lock-in, provide for faster convergence, minimize L2 fault domains, and provide for better traffic engineering.

Extension of L2

Naturally something that comes into question in a L3 switch fabric is, “What if I need L2 adjacency between hosts?” For Arista, the extension of L2 services across a L3 switch fabric is provided by Virtual eXtensible LAN (VXLAN). While closely related, in-depth discussion of the “network overlay” provided by VXLAN is outside the scope.

0

SPAN Destination ports and VLAN Membership

Recently at work, a discussion sprouted up around how to handle/configure local session Switched Port Analyzer (SPAN) destination ports.  A suggestion was made to create a new VLAN just for these SPAN destination ports and place them there.  The justification was that they would be out of VLAN 1, and easily identifiable.  Personally I thought it was a waste of a VLAN for a few simple SPAN destination ports, as SPAN destination ports do not participate in spanning tree, and do not forward traffic.  However, ultimately in this case it was a good decision due to security requirements.
Some key characteristics to know about SPAN destination ports:

• A destination port can be a physical port that is assigned to an EtherChannel group, even if the EtherChannel group has been specified as a SPAN source. The port is removed from the group while it is configured as a SPAN destination port.
  
• The port does not transmit any traffic except that traffic required for the SPAN session unless learning is enabled.
  
• The state of the destination port is up/down by design. The interface shows the port in this state in order to make it evident that the port Continue reading

0

Spanning Tree Exercise and Revisiting Root Guard

This was actually spurned from a comment I received on another one of my blog posts that you can find here.  Seeing that comment, I white boarded it and realized that I may have been completely wrong in regards to how Root Guard could “break a network”. 

Let’s say we have the following topology:

• Core 1 is the root for VLAN 10 with a configured priority of 4096, and is the secondary root for VLAN 20 with a configured priority of 8192.  We alternate this with Core 2 in order to load balance VLAN traffic.
• Access 3 and 4 are left in default configuration regarding spanning tree.
• Two workstations are present – one in VLAN 10, and another in VLAN 20.  Their default gateways are SVIs that are on the Core switches.
• For simplicity, switch MAC addresses are the number contained in their names.  Example: Access 4’s MAC address is “4”.
• All link costs are the same.
• All links between switches are trunks transporting all VLANs.

Let’s work through the spanning tree topologies.

Core 1 – Root bridge for VLAN 10.  All ports designated.

Core 2 – Port 1 will be a root port Continue reading

0

OSPF Adjacency Building Process

Ever curious regarding how two routers configured for OSPF become fully adjacent?  The following diagram of the process was modeled directly from RFC 2328, and the steps described gleaned from the Routing TCP/IP Vol I book.  Since we can see mention of a DR, this example must be based on a multi-access network.

1. RT1 becomes active and sends a Hello.  At this point, RT1 hasn’t seen any neighbors, so it reports such and sets its DR and BDR fields to 0.0.0.0.
2. Upon receipt by RT2, RT2 will build a data structure for RT1 and set RT1’s state to Init.  RT2 will then send a Hello packet reporting that it has seen RT1, and will report itself as the DR.
3. RT1 now sees its own RID in the received Hello packet from RT2, so RT1 will now create a data structure for RT2 and set its state to ExStart.  RT1 then begins Master/Slave negotiation with a DD packet with a sequence number of “x”, the Init bit set  to indicate that it is the start of an exchange, the More bit set to indicate that it is not the last DD packet to Continue reading

0

OSPF Link State Advertisements (LSAs) and Areas – Part II

For a table describing the different LSA types, check out the first post of this series.

In the first part of the series, we looked at LSA Types 1, 2, and 3 – Router, Network, and Network Summary, respectively.  To move on to the next two LSA types, we need to bring in another Autonomous System (AS).  In the diagram below, we’ve added R5 which has an interface in EIGRP AS 1, and is redistributing that into OSPF Area 4.  The fact that R5 has an interface inside of the OSPF AS, as well as the EIGRP AS, makes R5 an Autonomous System Boundary Router (ASBR). 

The EIGRP-oriented subnet that is being redistributed is considered an external route to the OSPF domain, so a Type 5 LSA, or ASBR External, is flooded into OSPF Area 4 containing a LSID and netmask of the subnet, plus the External Type. This important because it tells other routers whether or not to add the internal link costs within the OSPF domain to the metric to reach that subnet.  A type 2 external route specifies that only the external cost is taken into consideration.

When R2 catches wind of Continue reading

0

Exploring OSPF Messages in a Multi-access Network

 

The following network is configured with OSPF with all interfaces in area 0.  Since this is a multi-access network, a Designated Router (DR) is elected which improves OSPF performance by reducing the amount of LSA flooding. R3 is the current DR, with R2 as the BDR.  R4’s interface to SW1 has been configured as a passive interface to prevent an adjacency from forming and simulate R4 being a “new” router on the network.  Wireshark is monitoring the link between R4 and SW1.

I won’t go into all the details regarding Wireshark output and the OSPF process.  If you want a more detailed analysis, take a look at my previous blog article here.  In this article, we’ll only be taking a closer look at what happens specifically in a multi-access environment.

Upon re-enabling R4’s interface for OSPF, we see R4 sends a Hello packet to the All OSPF Routers multicast address (224.0.0.5) and that no DR or BDR is listed.  R4 is “new” to the network as far as OSPF is concerned, so it has no idea about the current topology.

R1, R2, and R3 all send Hello packets with the Continue reading

0

OSPF Link State Advertisements (LSAs) and Areas – Part I

If every router in an enterprise environment was in a single OSPF area, at some point you’re going to encounter scalability issues due to any changes in the environment causing an SPF recalculation in all routers in that single area.

LSAs and their use within areas provide a mechanism for maximizing performance in OSPF by logically segmenting groups of contiguous links so that every router in the entire autonomous system does not have to have exact copies of the Link State Database (LSDB) and to reduce the amount of LSA flooding.  SPF calculations are also isolated to each individual area rather than the entire environment.  Different LSAs are used in different situations, and are treated differently depending on the type of OSPF area involved.

The following table represents the different LSA types, and was taken from the CCIE R&S OCG.

TYPE	NAME	DESCRIPTION
1	Router	One per router containing its RID and all interface IP addresses; also represents stub networks.
2	Network	One per transit network.  Created by the DR and represents the subnet and router interfaces connected in the subnet.
3	Network Summary	Created by Area Border Routers (ABRs) to represent one area’s type 1 and Continue reading

0

Exploring OSPF Messages Between New Neighbors

A basic network is setup and OSPF is configured.  R1 is then prevented from forming an OSPF adjacency with R2 due to R1’s serial interface being configured as a passive interface.

Only Hello packets are seen from R2.

From this Wireshark output we can see:

1. OSPF Version 2 is utilized
2. This is a Hello packet
3. The Hello packet is sourced from a router with OSPF Router ID 2.2.2.2.  Duplicate RIDs will prevent an OSPF adjacency and cause other issues.
4. The interface that sourced this Hello packet resides in OSPF area 0.  This item is used to verify that the two connected router interfaces are within the same OSPF area – this is a requirement in order to form an OSPF adjacency.
5. No authentication is used
6. A /30 network mask is used on R2’s connected interface.  This item is used to verify that the two connected router interfaces are using the same subnet mask, which is a requirement in order to form an OSPF adjacency in addition to the two interfaces being within the same primary subnet.
7. Hello and Dead timers.  These must be the same on both connected routers in order to Continue reading

0

Late Night fun with a Meme Generator

I was watching a movie the other night with my wife and decided to hop on memegenerator.net and play around with memes.  Thought I’d share my creations.

 

    

0

Quality of Service (QoS) – Policing and Shaping Notes

Policers and shapers identify traffic violations in an identical manner, but treat them differently.  Policers perform instantaneous checks and immediately take action when a violation occurs.  Actions can include marking, dropping, and even just transmitting the packet.  Shapers on the other hand are traffic-smoothing tools.  Its objective is to send all traffic out a given interface, but to smooth it out so that it never exceeds a given rate – usually in order to meet SLAs.  Excess traffic is buffered and delayed until the traffic once again dips below the defined maximum rate.

While policing and shaping tools are not employed to directly provide QoS for real-time traffic, they do regulate/stabilize traffic flows so that unexpected bursts in data traffic do not induce jitter and latency that adversely affects real-time traffic.

Policers determine whether each packet conforms, exceeds, or violates the policies configured for traffic, and takes the prescribed action Continue reading

0

EtherChannel – Quick and Dirty

EtherChannel allows you to aggregate several switch links into a single, fast, fault-tolerant, logical interface. 16 links can be defined for an EtherChannel, however, a maximum of 8 will be active at any one time.  The other links are placed on standby.

While having multiple links between two switches can possibly create bridging loops, EtherChannel avoids this by bundling the links into a single logical interface.  This logical interface can be configured as an access or trunk interface.

For ports to be members of the same EtherChannel, there are some restrictions. Ports must:

• Belong to the same VLAN
• Have identical STP settings
• Have identical speed/duplex settings
• Note: In addition, if the EtherChannel is to be used as a trunking interface, all ports must be in trunking mode, have the same native VLAN, and pass the same set of VLANs.

The full duplex maximum bandwidth for 8 links is as follows:

• Fast EtherChannel (FEC): 1600 Mbps
• Gigabit EtherChannel (GEC): 16Gbps
• 10-Gigabit EtherChannel (10GEC): 160Gbps
• Note:  This is theoretical; maximum bandwidth is not likely to be achieved due to unequal load balancing, and other factors.

Load Balancing

 

EtherChannel load balancing across the links can occur in a number Continue reading

0

Brocade Auth-Change-Wait-Time

 

The other day I was at work doing an interoperability test with Cisco and Brocade multilayer switches, and we ran into a strange issue that really highlighted my “tunnel view” to the Cisco world.

We were setting up basic OSPF stuff using md5 authentication and we couldn’t get the Cisco and Brocade to form an adjacency.  A debug ip ospf adjacency command on the Cisco switch revealed that the Cisco was using “type 2” authentication, and the Brocade was using “type 0”. 

Here’s a quick breakdown of the authentication types:

Type 0	No authentication
Type 1	Clear text authentication
Type 2	md5 authentication

I set up a SPAN on the Cisco switch and sure enough, we were getting the OSPF Hello packets from the Brocade with no authentication.

After some digging, it turns out the Brocade has an Auth-Change-Wait-Time command in interface configuration mode.  This is set to 300 seconds (5 minutes) by default.  While I don’t quite understand it, the description states it allows for graceful authentication implementation.  So after you enable md5 on the interface, it waits 300 seconds before actually sending OSPF Hellos with authentication.  We toyed around with it Continue reading

0

OSPF LSA Manipulation Vulnerability – 8/1/2013

Vulnerability Details

OSPF LSA Manipulation Vulnerability in Multiple Cisco Products

· Summary

Multiple Cisco products are affected by a vulnerability involving the Open Shortest Path First (OSPF) Routing Protocol Link State Advertisement (LSA) database. This vulnerability could allow an unauthenticated attacker to take full control of the OSPF Autonomous System (AS) domain routing table, blackhole traffic, and intercept traffic.
The attacker could trigger this vulnerability by injecting crafted OSPF packets. Successful exploitation could cause flushing of the routing table on a targeted router, as well as propagation of the crafted OSPF LSA type 1 update throughout the OSPF AS domain.
To exploit this vulnerability, an attacker must accurately determine certain parameters within the LSA database on the target router. This vulnerability can only be triggered by sending crafted unicast or multicast LSA type 1 packets. No other LSA type packets can trigger this vulnerability.
OSPFv3 is not affected by this vulnerability. Fabric Shortest Path First (FSPF) protocol is not affected by this vulnerability.

· Affected Products

Cisco devices that are running Cisco IOS Software and configured for OSPF are vulnerable. Devices that do not have OSPF enabled are not affected by this vulnerability.

Cisco devices that are running Cisco IOS Continue reading

0

Quality of Service (QoS) Congestion-Avoidance Notes

Congestion-avoidance tools are complementary to, and dependent upon, queuing algorithms. Queuing/scheduling algorithms manage the front of a queue, while congestion-avoidance mechanisms manage the tail of a queue.

Congestion-avoidance tools are designed for TCP traffic, because TCP has built-in flow-control mechanisms that operate by gradually increasing traffic flows until packet loss has occurred.  Once packet loss has occurred, the transmission rate is reduced before slowly ramping up again.  This means that if no mechanism is in place to control TCP, any particular flow has the ability to eat up all available bandwidth.

When there are no congestion-avoidance tools in place, and queues fill, tail drop occurs, which means all traffic is dropped. 

In a constricted channel without congestion-avoidance tools, TCP connections eventually synchronize with each other – they ramp up together, lose packets together, and back off together.  This is called global synchronization and basically results in “waves” of TCP traffic.

Congestion-avoidance tools has no real benefit or use for UDP traffic, because UDP traffic does not have any retry logic.

Random Early Detection (RED)

RED combats global synchronization by preemptively and randomly dropping packets before queues fill.  Instead of waiting for the queues to fill, Continue reading

0

Quality of Service (QoS) Congestion Management Notes

Of all the tools within the QoS toolset, congestion management tools, also known as queuing tools, provide the biggest impact on application service levels.  Whenever packets enter a device faster than can exit it, congestion exists and this is where queuing tools come into play.  Queuing tools are only engaged when congestion exists, otherwise packets are sent as soon as they arrive.  When congestion does exist, packets must be buffered, or queued, to mitigate dropping.

Packet markings, or lack thereof, affect queuing policies, so queuing policies are complementary and have a dependence on classification and marking policies.

Scheduling vs. Queuing

These two terms are often incorrectly used interchangeably – they are two different things.  Scheduling determines how a frame or packet exits a device. Whenever packets enter a device faster than they can exit it, as is the case with speed mismatches (ex. Gigabit Ethernet traffic heading to a WAN interface), congestion can occur.  Devices have buffers that allow the temporary storing and subsequent scheduling of these backed-up packets, and this process is called queuing.

Inbound traffic > Queuing (During congestion) > Scheduling > Outbound traffic

• Queuing – orders packets in linked output buffers. Only Continue reading

0

Quality of Service (QoS) Classification and Marking Notes

The first part of building a QoS policy is to identify the traffic that you need to treat preferentially (give better priority), or differentially.  This is accomplished via classification and marking.

• Classification – sorts packets into different traffic types that policies can then be applied to.
• Marking (or re-marking) – establishes a trust boundary on which scheduling tools later utilize.  The edge of the network where markings are either accepted or rejected is known as the trust-boundary.
• Classifier tools – Inspect one or more fields in a packet to identify the type of traffic that is being carried. After being identified, it is passed to the appropriate mechanism to handle that type of traffic class.
• Marking tools – actually write a field within the packet (or frame, cell, label) to preserve the classification decision.  By marking traffic at a trust boundary, subsequent nodes do not have to perform the same in-depth analysis to determine how to treat the packet.

Classification Tools

These tools can examine a number of criteria within layers 1, 2, 3, 4, and 7.

• L1 – Physical interface, subinterface, PVC, port
• L2 – MAC, 802.1Q/p CoS, VLAN, MPLS EXP, ATM Cell Continue reading

0

Optimizing and Protecting Spanning Tree – Lab Testing

Unfortunately the equipment I was using didn’t support PVST+ (Sup2Ts in 6503 Catalyst Switches), so I skipped testing UplinkFast and BackboneFast as these are incorporated in 802.1w (RSTP) and 802.1s (MSTP, which is basically an extension of RSTP).

BPDU Guard

For this test, SwitchD will be treated as a Rogue Switch being attached to the network.  Initially, SwitchC’s port 2/1 is configured as an access port with only PortFast enabled.

1. 1. Disconnect link between SwitchC and SwitchD
2. 2. Configure SwitchC port 2/1 as an access port in VLAN 10 with PortFast enabled.
3. 3. Configure SwitchD port 2/1 as an access port in VLAN 10. Configure the priority on VLAN 10 to be 0.
4. 4. Reconnect link between SwitchC and SwitchD and check topology for VLAN 10. SwitchD should be the root for VLAN 10.
5. 5. Disconnect link between SwitchC and SwitchD
6. 6. Enable BPDU Guard on Switch C port 2/1
7. 7. Reconnect link between SwitchC and SwitchD. SwitchC port 2/1 should move to an err-disable state. Verify with sh interfaces status err-disabled. Verify SwitchD is no longer the root for VLAN 10.

*Jul  5 22:02:06.023: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet2/1 with BPDU Guard enabled. Disabling Continue reading