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.

 

    

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.

Policer	Shaper
Causes TCP resends as traffic is dropped	Delays traffic; involves less TCP resends
Inflexible; makes instant drop decisions	Adapts to network congestion by queuing excess traffic
Ingress or egress interface tool	Typically egress only
Rate limiting – no buffering	Rate limiting with buffering

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 in each case.

• Conforming – traffic that falls within the rate configured for the policer
• Exceeding – traffic that is above the policer rate, but still within the burst parameters
• Violating – traffic that is above both the policer rate and burst parameters

It is not productive to police voice traffic or call-signaling traffic because the incoming rates of these traffic types should be controlled at their origin by call admission control (CAC) mechanisms.

You can also use a policer as a marker to re-mark traffic upon an exceed and/or violate action rather than just drop it.

Although a policer can be deployed ingress or egress, it is typically deployed at the network edge on traffic ingress.  If packets will be dropped, there is little point in spending CPU cycles routing these packets.  Policers are also often deployed at the traffic egress interface to control bandwidth used or allocated to a particular class of traffic.

As mentioned earlier, shapers are similar to policers in that they also limit the transmission rate of packets but they do so by delaying packets that exceed the CIR.  This allows for conformance to SLAs.  Shaping is crucial for non-broadcast multi-access (NBMA) topologies such as ATM and Frame Relay, or potentially anywhere else where a speed mismatch may exist.  Examples of this would be line speed mismatches, aggregated traffic oversubscription, and SLA enforcement by a carrier.

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 of configurable methods for optimization in your environment. IP addresses, MAC addresses, and TCP/UDP port numbers can be leveraged. The complete list is:

• Source IP (src-ip)
• Destination IP (dst-ip)
• Source and Destination IP (src-dst-ip)
• Source MAC (src-mac)
• Destination MAC (dst-mac)
• Source and Destination MAC (src-dst-mac)
• Source Port (src-port)
• Destination Port (dst-port)
• Source and Destination Port (src-dst-port)

When more than one item is utilized in the load balancing method,  an XOR operation occurs, and for 2 links, the last bit is utilized.  Four links uses the last two bits, and eight links use the last three.  Below shows two switches with an EtherChannel with four links, configured to use the Source and Destination IP (src-dst-ip) method of load balancing.  The four different examples show how the links are used as different devices communicate across the two switches.

 

For best results, it is recommended to consider using MAC addresses or the Source IP address as your load-balancing method.  However, this all depends on your environment. For example, a router always uses it’s burned-in MAC address, so the destination MAC address remains the same for all frames destined through the router.  When two routers are forwarding traffic to each other, MAC addresses remain constant, so only one link is used.  Using IP addresses as the load-balancing method instead may be a better idea.  If most of the traffic is between the same two IP addresses, use IP port numbers instead.

If EtherChannel traffic consists of non-IP traffic, distribution according to MAC address is recommended.

If a frame can’t meet load-balancing criteria, switch reverts to “next lowest” method. For instance is MAC traffic is sent across an EtherChannel that’s configured to load-balance by IP addressing, MAC addresses will be used instead.

To prevent loops, inbound (received) broadcasts and multicasts are not sent back out any of the links.  Outbound frames are load-balanced normally.

 

EtherChannel Negotiation: PAgP vs. LACP

 

There are two EtherChannel negotiation protocols.  Port Aggregation Protocol (PAgP) is a Cisco-proprietary protocol, while Link Aggregation Control Protocol (LACP) is standards based.

PAgP dynamically modifies the EtherChannel if one of the ports’ VLAN, speed, etc. is changed so that all of the links in the EtherChannel match. PAgP can be configured in active mode (desirable), which actively attempts negotiation.  Passive mode (auto, the default) only negotiates an EtherChannel if the far end initiates it.

LACP assigns roles to end points.  The switch with the lowest system priority makes decisions about what ports will participate in the EtherChannel at any given time.  If you’re familiar with STP, this is similar to the way the Root Bridge is elected.  Ports are selected and become active in the EtherChannel according to their port priority. LACP Active mode (active) – actively negotiates, while passive mode (passive) negotiates only if the far end initiates it.

Lastly, the “on” mode forces the EtherChannel to be formed; no PAgP/LACP negotiation occurs when this mode is utilized.

Here’s a configuration Video:

PAgP EtherChannel Configuration

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 and took a packet capture to confirm the behavior, and then set it to 0 to immediately start sending packets with authentication and we were good to go.

Here’s a screenshot of the behavior in Wireshark with the parameter set to 20 seconds.  You’ll see the OSPF adjacency start forming at almost exactly 20 seconds.

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 XE Software and configured for OSPF are vulnerable. Devices that do not have OSPF enabled are not affected by this vulnerability.

The version of Cisco IOS-XE Software that is running on a Cisco device can be determined using the show version command from the Command Line Interface (CLI).

· Workarounds

The use of OSPF authentication is a valid workaround. OSPF packets without a valid key will not be processed. MD5 authentication is highly recommended, due to inherent weaknesses in plain text authentication. With plain text authentication, the authentication key will be sent unencrypted over the network, which can allow an attacker on a local network segment to capture the key by sniffing packets.
Refer to http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080094069.shtml for more information about OSPF authentication.
Additionally, an OSPF Time To Live (TTL) security check can be applied as a partial workaround.
Note: This workaround is valid to protect against remotely triggered attacks and does not protect against attackers that are layer 2-adjacent to vulnerable devices.
For more information about general Interior Gateway Protocol (IGP) hardening, refer tohttp://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080094069.shtml.

Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link:http://tools.cisco.com/security/center/viewAMBAlert.x?alertId=29974