blog.packetflow.io Open in urlscan Pro
2a00:1450:400d:805::2013 Public Scan

Back to summary

Submitted URL:
http://packetflow.io/2015/01/extreme-networks-exos-cheat-sheet.html
Effective URL:
http://blog.packetflow.io/
Submission Tags: falconsandbox
Submission: On January 19 via api (January 19th 2023, 5:10:58 pm UTC) from US — Scanned from DE

Form analysis
0 forms found in the DOM

Text Content

Keeping the packets flowing.

ABOUT

* Home
* Networking
* The Lab
* About

MONDAY, NOVEMBER 14, 2016

RETHINKING MICRO-SEGMENTATION

TRADITIONAL SECURITY ARCHITECTURES

Traditional security architectures enforce security policy at rigidly defined
trust boundaries. At the most basic level, this is the perimeter of the network.
A firewall sits between the untrusted public Internet and the trusted private
network. If inbound access from the Internet is required, a DMZ is often created
to segment Internet exposed resources from the trusted internal network. A
network can be further segmented using additional zones on the perimeter
firewall, access-lists on distribution switches, and additional layers of
security at various points in the network.

In this traditional model, as security increases, so does configuration
complexity, management overhead, and margin for human error. In addition,
implicit trust between devices on a network segment is inherent to traditional
security architectures. If one device is breached, an attacker can use the
compromised device to launch an attack against other devices on the same network
segment. Therefore, traditional security architectures are often ill equipped to
secure east-west traffic in a modern data center.

WHAT IS MICRO-SEGMENTATION?

In two words: Trust nothing. The goal is to eliminate implicit trust and apply
security policy between all devices within the purview of the micro-segmentation
solution. By using this zero-trust model, micro-segmentation solutions aim to
prevent attackers from moving laterally through a network after breaching an
initial target.

There are a few fundamentally different approaches to micro-segmentation in the
data center. Several current micro-segmentation solutions are built into larger
data center orchestration and automation platforms. I'll avoid mentioning
specific products, because comparisons often end up like those of vi vs. Emacs
or which is the best Linux distribution.

That said, the solutions I am most familiar with enforce security policy in one
of two ways:
• Enforce policy in the network device and/or vSwitch
• Enforce policy in the hypervisor kernel

Despite where the actual enforcement occurs, at a high level the
micro-segmentation functionality itself is comparable. An engineer logs into a
controller, defines a security policy, and centrally pushes this security policy
to a number of devices in order to restrict traffic between endpoints. These
endpoints can be baremetal servers, VMs, containers, or other resources
supported by the micro-segmentation platform. The fundamental difference is the
point of policy enforcement - hypervisor, vSwitch, or network device.

Read more »
Posted by Matt Haedo 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: Illumio, micro-segmentation, Networking Field Day, NFD12, security, Tech
Field Day

THURSDAY, OCTOBER 6, 2016

BIG DATA ANALYTICS FOR YOUR NETWORK

The help desk just called. Users are reporting the wireless is down in your
office, and nobody can get on the network. The wireless seems fine to you.
You're connected. You ask a few people nearby, and they're connected too. You
log into the WLC and don't see any problems. Speedtest.net works fine. Maybe you
should just turn the controller off and then back on again. That worked last
time. No, that's a bad idea. It's the middle of the day and you actually need to
troubleshoot it.

After a bit of troubleshooting, you determine the cause of the issue is not the
wireless. The DHCP scope is exhausted. Users could connect, but they couldn't
obtain an IP address. You shorten the lease time, expand the scope, and call it
a day. While you're at it, you wonder if DHCP is the reason connecting has been
taking longer than usual, so you fire up Wireshark.

Discover, offer, request, acknowledge. You remember that from a CCNA class half
a lifetime ago. Looks good. Well, you think it looks good. It takes about 227
milliseconds from discover to offer. That's normal, right? You realize you're
not sure what normal is. You don't know your baseline, and you have no idea how
long DHCP should take from discover to offer or request to acknowledge. What
about dot1x? Is the RADIUS server slowing things down? You really have no idea.
It works. It's lunch time. Nobody is complaining - right now.

Ok, hopefully the way you run your network is nothing like this. However, let's
face it: this is an exaggerated version of the reality that many deal with on a
day to day basis. There is often little insight into the individual operations
that contribute to network performance as a whole. "The wireless is down" could
mean any number of things, many of which may be out of the purview of the team
managing the wireless network. Troubleshooting is often a reactive process. Even
when there is visibility into network operations and baselines are known, it can
be difficult to determine if your "normal" is actually optimal.

I recently attended a presentation by Nyansa at Networking Field Day 12. Nyansa
is a startup focusing on what they call Cloudsourced Network Analytics. Their
goal is to go beyond providing visibility in the form of pretty graphs and
actually provide actionable insight about how to improve the end user
experience.

Read more »
Posted by Matt Haedo No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: analytics, big data, correlation, networking, Networking Field Day,
NFD12, Nyansa, Tech Field Day, Voyance

FRIDAY, SEPTEMBER 9, 2016

MNEMONIC: SYSLOG SEVERITY LEVELS

Ever have trouble remembering syslog severity levels?

I was organizing some old study notes and came across this mnemonic. It's easy
to remember, and I'm sure many network engineers can relate.

EVERYONE ALWAYS COMPLAINS EVEN WHEN NOTHING IS DIFFERENT.

[E]veryone [A]lways [C]omplains [E]ven [W]hen [N]othing
[I]s [D]ifferent
[E]mergency [A]lert [C]ritical [E]rror [W]arning [N]otification
[I]nformational [D]ebugging

Level Description
0 - emergency System is unusable
1 - alert Immediate action needed
2 - critical Critical condition
3 - error Error condition
4 - warning Warning condition
5 - notification Normal but significant condition
6 - informational Informational message only
7 - debugging Appears during debugging only

More information about syslog (system message logging):
https://www.cisco.com/c/en/us/td/docs/routers/access/wireless/software/guide/SysMsgLogging.html

Posted by Matt Haedo 4 comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: ccie-rs-lab-v5-topic-5.1.c, ccie-rs-lab-v5-topic-5.1.c-i,
ccie-rs-wr-v5.1-topic-6.1.c, ccie-rs-wr-v5.1-topic-6.1.c-i, logging, mnemonic,
network engineering, networking, syslog

SATURDAY, SEPTEMBER 3, 2016

SPANNING TREE PROTOCOL VISUALIZATION - INITIAL CONVERGENCE

Spanning tree: everyone's favorite protocol! Thousands of pages have already
been written about spanning tree, so I've decided to take a different approach.

I find it helpful to visualize protocol elections and traffic flow in order to
better understand protocol behavior, so I created a visualization illustrating
the initial spanning convergence process. This visualization only addresses the
initial root bridge election and STP convergence process, for example, if all
switches were to boot at the same time. This does not address converging a new
STP topology after a topology change.

The visualization below is basically an embedded slideshow that can be advanced
by clicking on the image. There are notes for each slide that briefly explain
each step of the convergence process. The numbers on each side of the links
between switches represent the port number of each uplink.

Here are the basic steps of the initial STP convergence process:

1. Elect the root bridge.
2. Determine the root ports.
3. Determine the designated ports.
4. Remaining ports are blocking ports.

CLICK THE IMAGE TO ADVANCE THE VISUALIZATION.

Tap here if you are on a mobile device.

As you can see, the resulting topology (the logical forwarding topology that is
created after STP blocks redundant links) looks something like an upside-down
tree.

Here is an example of of what this tree might look like when redundant links are
blocked by STP in a larger L2 topology (although hopefully your network looks
nothing like this). The links shown in black can be used, because each port is
in the forwarding state. The links shown in red cannot be used, because one of
the ports is in the blocking state. Reducing the topology to a tree of
forwarding links is how spanning tree maintains a loop free L2 topology.

Once again, this is not meant to be a complete description of STP, but rather a
visualization and basic description of the initial convergence process.

Feel free to leave questions or comments below.

Posted by Matt Haedo 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: ccie-rs-lab-v5-topic-1.1.f, ccie-rs-lab-v5-topic-1.1.f-i, CCIE-RS-v5,
ccie-rs-wr-v5.1-topic-2.1.f, ccie-rs-wr-v5.1-topic-2.1.f-i, certification, L2,
networking, spanning tree, switching, visualization

TUESDAY, AUGUST 9, 2016

OPENGEAR AND THE EVOLUTION AND CONSOLIDATION OF NETWORK DEVICES

OPENGEAR AT TECH FIELD DAY EXTRA 2016

I recently attended Cisco Live 2016 in Las Vegas and was invited to attend Tech
Field Day Extra as a delegate. The first presenter was Opengear, a maker of
console access servers and remote management gateways. They describe their
products as "next generation Smart Solutions for managing and protecting
critical IT and communications infrastructure."

While the term "next generation" is frequently overused, I can't argue with
Opengear. Opengear extends the functionality of a console access server into a
more complete out-of-band management solution. First, the Opengear presentation
made me reevaluate what I should look for in an a console access server. What
should it do? What shouldn't it do, and what roles should be held by separate
devices?

Read more »
Posted by Matt Haedo No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: CLUS, CLUS2016, networking, Opengear, Tech Field Day, TFDx

FRIDAY, FEBRUARY 5, 2016

CONFIGURING ERSPAN ON CISCO ROUTERS AND SWITCHES

In two recent posts, I covered SPAN, for mirroring traffic to a port on a local
switch, and RSPAN, for mirroring traffic across a VLAN to a port on a remote
switch. What if we want to mirror traffic traffic to a destination across a L3
link? Cisco provides the ability to do this natively with a feature called
ERSPAN, or encapsulated RSPAN. However, this feature is only available on
higher end platforms such as Catalyst 6500 and 6800 series switches, 7600 series
routers, ASR1000, and CSR1000v (this is not a complete list).

ERSPAN

Like SPAN and RSPAN, configuring ERSPAN is pretty straightforward. ERSPAN
simply requires L3 connectivity between source and destination devices. The
ERSPAN monitor session then builds a GRE tunnel that transports mirrored frames
from the source port to the destination port.

Basic ERSPAN configuration is as follows:

! Source switch
monitor session SESSION-NUMBER type erspan-source
source-interface INTERFACE(S)|VLAN(S) {TX|RX|BOTH}
no shutdown
destination
erspan-id ERSPAN-ID
ip address DESTINATION-IP
origin ip address ORIGIN-IP

! Destination switch
monitor session SESSION-NUMBER type erspan-destination
destination-interface INTERFACE(S)
no shutdown
source
erspan-id ERSPAN-ID
ip address SOURCE-IP

It is important to note that when configuring the destination switch "source
IP," you should select the source IP on the destination switch itself - the GRE
tunnel endpoint. Source IP does not refer to the GRE tunnel origin IP address.
Therefore, the "ip address" command should match on the source and destination.

Below is a basic ERSPAN config to mirror data from R1 interface g3 to R3
interface g3. I created this topology using VIRL using CSR1000V routers for R1
and R3.

Read more »
Posted by Matt Haedo 3 comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: ccie-rs-lab-v5-topic-1.1.g, ccie-rs-lab-v5-topic-1.1.g-i, CCIE-RS-v5,
ccie-rs-wr-v5.1-topic-2.1.g, ccie-rs-wr-v5.1-topic-2.1.g-i, certification, L2,
L3, network engineering, networking, routing, RSPAN, switching

SATURDAY, JANUARY 30, 2016

CONFIGURING RSPAN ON CISCO CATALYST SWITCHES

I recently wrote a post on configuring port mirroring (SPAN) on Cisco Catalyst
switches. SPAN (switched port analyzer) allows you to mirror traffic from a
source or multiple sources on a switch to a destination interface or interfaces
on the same switch. RSPAN (remote SPAN) takes this a step further and allows
you to mirror traffic to an interface on a remote switch or switches.

RSPAN

RSPAN configuration is relatively simple and builds upon existing SPAN
functionality and configuration syntax.

* Create an RSPAN VLAN on the source switch, destination switch, and all
switches in the transit path.
* Take traffic from a specified source on switch A, and mirror it to an RSPAN
VLAN.
* Then, on switch B, use traffic from this VLAN as the source and mirror it to
a physical interface

As shown below, traffic mirrored from the switch on the right to the switch on
the left can traverse other switches as long as there is end to end L2
connectivity between them (ie. the RSPAN VLAN exists on all switches).

Basic RSPAN configuration is as follows:

Read more »
Posted by Matt Haedo 2 comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: ccie-rs-lab-v5-topic-1.1.g, ccie-rs-lab-v5-topic-1.1.g-i, CCIE-RS-v5,
ccie-rs-wr-v5.1-topic-2.1.g, ccie-rs-wr-v5.1-topic-2.1.g-i, certification,
Cisco, L2, network engineering, networking, RSPAN, switching

Load more posts
Older Posts Home

blog.packetflow.io Open in urlscan Pro 2a00:1450:400d:805::2013 Public Scan

Form analysis 0 forms found in the DOM

Text Content

blog.packetflow.io Open in urlscan Pro
2a00:1450:400d:805::2013 Public Scan

Form analysis
0 forms found in the DOM