Extracting Traffic from Rolling Capture Files
Every so often I need to extract a subset of traffic from a set of rolling timestamped pcap files. One common place I do this is with Security Onion; one of the great features of SO is its full-packet-capture feature: you can easily pivot from Snort, Suricata, or Bro logs to a full packet capture view, or download the associated pcap file.But what if you don't have an associated alert or Bro log entry? Or if you're doing pcap on some system that's not as user-friendly as Security Onion, but nonetheless supports rolling captures?
The way I usually do this is with find and xargs. Here's an example of my most common workflow, using timestamps as the filtering criteria for find:
> find . -newerct "16:07" ! -newerct "16:10" | xargs -I {} tcpdump -r {} -w /tmp/{} host 8.8.8.8
> cd /tmp
> mergecap -w merged.pcap *.pcap
Translated:
- Find all files in the current directory created after 16:07 but not created after 16:10. This requires GNU find 4.3.3 or later. It supports many different time and date formats.
- Using xargs, filter each file with the "host 8.8.8. Continue reading
Extracting Traffic from Rolling Capture Files
Every so often I need to extract a subset of traffic from a set of rolling timestamped pcap files. One common place I do this is with Security Onion; one of the great features of SO is its full-packet-capture feature: you can easily pivot from Snort, Suricata, or Bro logs to a full packet capture view, or download the associated pcap file.But what if you don't have an associated alert or Bro log entry? Or if you're doing pcap on some system that's not as user-friendly as Security Onion, but nonetheless supports rolling captures?
The way I usually do this is with find and xargs. Here's an example of my most common workflow, using timestamps as the filtering criteria for find:
> find . -newerct "16:07" ! -newerct "16:10" | xargs -I {} tcpdump -r {} -w /tmp/{} host 8.8.8.8
> cd /tmp
> mergecap -w merged.pcap *.pcap
Translated:
- Find all files in the current directory created after 16:07 but not created after 16:10. This requires GNU find 4.3.3 or later. It supports many different time and date formats.
- Using xargs, filter each file with the "host 8.8.8. Continue reading
LTE’s Move into the Unlicensed Spectrum Continues
A lot has been going on with the proposals for LTE Operation in Unlicensed Spectrum . The FCC recently requested industry input on LTE-U (LTE Unlicensed) and LAA (LTE Licensed-Assisted Access), 3GPP’s formal action to move both the LAA and...SK Telecom Chooses Accedian for Performance Monitoring
SK Telecom looks to Accedian Networks for help with its mobile network.
Revisiting Apple and IPv6
A few weeks ago I wrote about Apple's IPv6 announcements at the Apple Developers Conference. While I thought that in IPv6 terms Apple gets it, the story was not complete and there were a number of aspects of Apple's systems that were not quite there with IPv6. So I gave them a 7/10 for their IPv6 efforts. Time to reassess that score in the light of a few recent posts from Apple.SDN router using merchant silicon top of rack switch
The talk from David Barroso describes how Spotify optimizes hardware routing on a commodity switch by using sFlow analytics to identify the routes carrying the most traffic. The full Internet routing table contains nearly 600,000 entries, too many for commodity switch hardware to handle. However, not all entries are active all the time. The Spotify solution uses traffic analytics to track the 30,000 most active routes (representing 6% of the full routing table) and push them into hardware. Based on Spotify's experience, offloading the active 30,000 routes to the switch provides hardware routing for 99% of their traffic.David is interviewed by Ivan Pepelnjak, SDN ROUTER @ SPOTIFY ON SOFTWARE GONE WILD. The SDN Internet Router (SIR) source code and documentation is available on GitHub.
Highlight: Inside Cisco IOS Software Architecture
The post Highlight: Inside Cisco IOS Software Architecture appeared first on 'net work.
Plexxi Announces New Network Switch Series to Power the Next Era of IT
Its not very often that something comes along that has the potential to be transformative through a new and truly differentiated approach. With Plexxi’s announcement this morning of our new Switch 2 Series , coupled with Plexxi Control and Plexxi Connect, we’re making strides to change the way networks function to support the business. Based on the needs of individual data and application workloads, the Switch 2 Series uses the innovation of Plexxi Control to dynamically change fabric topology in real time, intelligently forwarding traffic and delivering needed network capacity.
The next era of IT is being forged by the evolution of virtualization, hyperconvergence, Big Data and scale-out applications. Storage and compute have rapidly evolved over the last decade to keep pace but networking architectures have remained relatively unchanged.
Here is the evolution of networking, as we see it:
Platform One:
The network has, for decades, been built in the same multi-tier (core, leaf/spine) approach making it static and defined by it’s physical cabling. This architecture was perfectly suited for stationary users and non-mobile applications, which created predictable north/south traffic. The traditional approach for introducing new applications in platform 1 was to “pour” them into the static network, and then Continue reading
Plexxi ‘Switch 2’ Adds a Layer-1 Wormhole
Plexxi tries to cut latency to the bone.
Can You Avoid Networking Software Bugs?
One of my readers sent me an interesting reliability design question. It all started with a catastrophic WAN failure:
Once a particular volume of encrypted traffic was reached the data center WAN edge router crashed, and then the backup router took over, which also crashed. The traffic then failed over to the second DC, and you can guess what happened then...
Obviously they’re now trying to redesign the network to avoid such failures.
Read more ...HP Adds NEC As an OpenNFV Partner
Bit by bit, an NFV ecosystem takes shape.
Checking Faulty Cables
I recently had to work with a 3rd part to diagnose a link between our devices and came across this handy command. The link in question was a pretty hefty (75m-ish) UTP cable run between a Cisco and HP switch. I have visibility of the Cisco switch, into the structured cabling into the patch panel, and the 3rd parties cable. Unfortunately I didn’t have a DC Operations tech with access to a Fluke, or the ability to interpret the output of a Fluke, but they did have a laptop with a 100Mbps NIC (this becomes important later on).
So I started by running the diagnostic on the production connection. It’s not working, so I don’t have to worry about taking stuff down. This gives me the following:
test cable-diagnostics tdr interface gi7/21
TDR test started on interface Gi7/21
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.
switchA#show cable-diagnostics tdr interface gi7/21
TDR test last run on: July 09 10:30:20
Interface Speed Pair Cable length Distance to fault Channel Pair status
——— —– —- ——————- ——————- ——- ————
Gi7/21 auto 1-2 77 +/- 6 m N/A Invalid Continue reading