Archive | EPC (Embedded Packet Capture) RSS feed for this section

5G Network Slicing – Separating the Internet of Things from the Internet of Talk

1 Mar

Recognized now as a cognitive bias known as the frequency illusion, this phenomenon is thought to be evidence of the brain’s powerful pattern-matching engine in action, subconsciously promoting information you’ve previous deemed interesting or important. While there is far from anything powerful between my ears, I think my brain was actually on to something. As the need to support an increasingly diverse array of equally critical but diverse services and endpoints emerges from the 4G ashes, network slicing is looking to be a critical function of 5G design and evolution.

Euphoria subsiding, I started digging a little further into this topic and it was immediately apparent that the source of my little bout of déjà vu could stem from the fact that network slicing is in fact not one thing but a combination of mostly well-known technologies and techniques… all bundled up into a cool, marketing-friendly name with a delicately piped mound of frosting and a cherry on top. VLAN, SDN, NFV, SFC — that’s all the high-level corporate fluff pieces focused on. We’ve been there and done that.2

5g-slicing-blog-fluff.png

An example of a diagram seen in high-level network slicing fluff pieces

I was about to pack up my keyboard and go home when I remembered that my interest had originally been piqued by the prospect of researching RAN virtualization techniques, which must still be a critical part of an end-to-end (E2E) 5G network slicing proposition, right? More importantly, I would also have to find a new topic to write about. I dug deeper.

A piece of cake

Although no one is more surprised than me that it took this long for me to associate this topic with cake, it makes a point that the concept of network slicing is a simple one. Moreover, when I thought about the next step in network evolution that slicing represents, I was immediately drawn to the Battenberg. While those outside of England will be lost with this reference,3 those who have recently binge-watched The Crown on Netflix will remember the references to the Mountbattens, which this dessert honors.4 I call it the Battenberg Network Architecture Evolution principle, confident in the knowledge that I will be the only one who ever does.

5g-slicing-blog-battenberg-network-evolution.png

The Battenberg Network Architecture Evolution Principle™

Network slicing represents a significant evolution in communications architectures, where totally diverse service offerings and service providers with completely disparate traffic engineering and capacity demands can share common end-to-end (E2E) infrastructure resources. This doesn’t mean simply isolating traffic flows in VLANs with unique QoS attributes; it means partitioning physical and not-so-physical RF and network functions while leveraging microservices to provision an exclusive E2E implementation for each unique application.

Like what?

Well, consider the Internet of Talk vs. the Internet of Things, as the subtitle of the post intimates. Evolving packet-based mobile voice infrastructures (i.e. VoLTE) and IoT endpoints with machine-to-person (M2P) or person-to-person (P2P) communications both demand almost identical radio access networks (RAN), evolved packet cores (EPC) and IP multimedia subsystem (IMS) infrastructures, but have traffic engineering and usage dynamics that would differ widely. VoLTE requires the type of capacity planning telephone engineers likely perform in their sleep, while an IoT communications application supporting automatic crash response services5 would demand only minimal call capacity with absolutely no Mother’s Day madness but a call completion guarantee that is second to none.

In the case of a network function close to my heart — the IMS Core — I would not want to employ the same instance to support both applications, but I would want to leverage a common IMS implementation. In this case, it’s network functions virtualization (NFV) to the rescue, with its high degree of automation and dynamic orchestration simplifying the deployment of these two distinct infrastructures while delivering the required capacity on demand. Make it a cloud-native IMS core platform built on a reusable microservices philosophy that favors operating-system-level virtualization using lightweight containers (LCXs) over virtualized hardware (VMs), and you can obtain a degree of flexibility and cost-effectiveness that overshadows plain old NFV.

I know I’m covering a well-trodden trail when I’m able to rattle off a marketing-esque blurb like that while on autopilot and in a semi-conscious state. While NFV is a critical component of E2E network slicing, things get interesting (for me, at least) when we start to look at the virtualization of radio resources required to abstract and isolate the otherwise common wireless environment between service providers and applications. To those indoctrinated in the art of Layer 1-3 VPNs, this would seem easy enough, but on top of the issue of resource allocation, there are some inherent complications that result from not only the underlying demand of mobility but the broadcast nature of radio communications and the statistically random fluctuations in quality across the individual wireless channels. While history has taught us that fixed bandwidth is not fungible,6 mobility adds a whole new level of unpredictability.

The Business of WNV

Like most things in this business, the division of ownership and utilization can range from strikingly simple to ridiculously convoluted. At one end of the scale, a mobile network operator (MNO) partitions its network resources — including the spectrum, RAN, backhaul, transmission and core network — to one or more service providers (SPs) who use this leased infrastructure to offer end-to-end services to their subscribers. While this is the straightforward MNV model and it can fundamentally help increase utilization of the MNOs infrastructure, the reality is even easier, in that the MNO and SP will likely be the same corporate entity. Employing NFV concepts, operators are virtualizing their network functions to reduce costs, alleviate stranded capacity and increase flexibility. Extending these concepts, isolating otherwise diverse traffic types with end-to-end wireless network virtualization, allows for better bin packing (yay – bin packing!) and even enables the implementation of distinct proof-of-concept sandboxes in which to test new applications in a live environment without affecting commercial service.

2-and-4-layer-models-5g-slicing-blog.png

Breaking down the 1-2 and 4-layer wireless network virtualization business model

Continuing to ignore the (staggering, let us not forget) technical complexities of WNV for a moment, while the 1-2 layer business model appears to be straightforward enough, to those hell-bent on openness and micro business models, it appears only to be monolithic and monopolistic. Now, of course, all elements can be federated.7 This extends a network slice outside the local service area by way of roaming agreements with other network operators, capable of delivering the same isolated service guarantees while ideally exposing some degree of manageability.

To further appease those individuals, however, (and you know who you are) we can decompose the model to four distinct entities. An infrastructure provider (InP) owns the physical resources and possibly the spectrum which the mobile virtual network provider then leases on request. If the MVNP owns spectrum, then that component need not be included in the resource transaction. A widely recognized entity, the mobile virtual network operator (MVNO) operates and assigns the virtual resources to the SP. In newer XaaS models, the MVNO could include the MVNP, which provides a network-as-a-service (NaaS) by leveraging the InPs infrastructure-as-a-service (IaaS). While the complexities around orchestration between these independent entities and their highly decomposed network elements could leave the industry making an aaS of itself, it does inherently streamline the individual roles and potentially open up new commercial opportunities.

Dicing with RF

Reinforcing a long-felt belief that nothing is ever entirely new, long before prepending to cover all things E2E, the origin of the term “slicing” can be traced back over a decade in texts that describe radio resource sharing. Modern converged mobile infrastructures employ multiple Radio Access Technologies (RATs), both licensed spectrum and unlicensed access for offloading and roaming, so network slicing must incorporate techniques for partitioning not only 3GPP LTE but also IEEE Wi-Fi and WiMAX. This is problematic in that these RATs are not only incompatible but also provide disparate isolation levels — the minimum resource units that can be used to carve out the air interface while providing effective isolation between service providers. There are many ways to skin (or slice) each cat, resulting in numerous proposals for resource allocation and isolation mechanisms in each RF category, with no clear leaders.

At this point, I’m understanding why many are simply producing the aforementioned puff pieces on this topic — indeed, part of me now wishes I’d bowed out of this blog post at the references to sponge cake — but we can rein things in a little.  Most 802.11 Wi-Fi slicing proposals suggest extending existing QoS methods — specifically, enhanced DCF (distributed coordination function) channel access (EDCA) parameters. (Sweet! Nested acronyms. Network slicing might redeem itself, after all.) While (again) not exactly a new concept, the proposals advocate implementing a three-level (dimensional) mathematical probability model know as a Markov chain to optimize the network by dynamically tuning the EDCA contention window (CW), arbitration inter-frame space (AIFS) and transmit opportunity (TXOP) parameters,8 thereby creating a number of independent prioritization queues — one for each “slice.” Early studies have already shown that this method can control RF resource allocation and maintain isolation even as signal quality degrades or suffers interference. That’s important because, as we discussed previously, we must overcome the variations in signal-to-noise ratios (SNRs) in order to effectively slice radio frequencies.

In cellular networks, most slicing proposals are based on scheduling (physical) resource blocks (P/RBs), the smallest unit the LTE MAC layer can allocate, on the downlink to ensure partitioning of the available spectrum or time slots.

5g-slicing-blog-prb.png

An LTE Physical Resource Block (PRB), comprising 12 subcarriers and 7 OFDM symbols

Slicing LTE spectrum, in this manner, starts and pretty much ends with the eNodeB. To anyone familiar with NFV (which would include all you avid followers of Metaswitch), that would first require virtualization of that element using the same fundamental techniques we’ve described in numerous posts and papers. At the heart of any eNodeB virtualization proposition is an LTE hypervisor. In the same way classic virtual machine managers partition common compute resources, such as CPU cycles, memory and I/O, an LTE hypervisor is responsible for scheduling the physical radio resources, namely the LTE resource blocks. Only then can the wireless spectrum be effectively sliced between independent veNodeB’s owned, managed or supported by the individual service provider or MVNO.

5g-slicing-blog-virtual-eNobeB.png

Virtualization of the eNodeB with PRB-aware hypervisor

Managing the underlying PRBs, an LTE hypervisor gathers information from the guest eNodeB functions, such as traffic loads, channel state and priority requirements, along with the contract demands of each SP or MVNO in order to effectively slice the spectrum. Those contracts could define fixed or dynamic (maximum) bandwidth guarantees along with QoS metrics like best effort (BE), either with or without minimum guarantees. With the dynamic nature of radio infrastructures, the role of the LTE hypervisor is different from a classic virtual machine manager, which only need handle physical resources that are not continuously changing. The LTE hypervisor must constantly perform efficient resource allocation in real time through the application of an algorithm that services those pre-defined contracts as RF SNR, attenuation and usage patterns fluctuate. Early research suggests that an adaptation of the Karnaugh-map (K-map) algorithm, introduced in 1953, is best suited for this purpose.9

Managing the distribution of these contracted policies across a global mobile infrastructure falls on the shoulders of a new wireless network controller. Employing reasonably well-understood SDN techniques, this centralized element represents the brains of our virtualized mobile network, providing a common control point for pushing and managing policies across highly distributed 5G slices. The sort of brains that are not prone to the kind of cognitive tomfoolery that plague ours. Have you ever heard of the Baader-Meinhof phenomenon?

1. No one actually knows why the phenomenon was named after a West German left wing militant group, more commonly known as the Red Army Faction.

2. https://www.metaswitch.com/the-switch/author/simon-dredge

3. Quite frankly, as a 25-year expat and not having seen one in that time, I’m not sure how I was able to recall the Battenberg for this analogy.

4. Technically, it’s reported to honor of the marriage of Princess Victoria, a granddaughter of Queen Victoria, to Prince Louis of Battenberg in 1884. And yes, there are now two footnotes about this cake reference.

5. Mandated by local government legislation, such as the European eCall mandate, as I’ve detailed in previous posts. https://www.metaswitch.com/the-switch/guaranteeing-qos-for-the-iot-with-the-obligatory-pokemon-go-references

6. E.g. Enron, et al, and the (pre-crash) bandwidth brokering propositions of the late 1990s / early 2000s

7. Yes — Federation is the new fancy word for a spit and a handshake.

8. OK – I’m officially fully back on the network slicing bandwagon.

9. A Dynamic Embedding Algorithm for Wireless Network Virtualization. May 2015. Jonathan van de Betl, et al.

Source: http://www.metaswitch.com/the-switch/5g-network-slicing-separating-the-internet-of-things-from-the-internet-of-talk

LTE Network Architecture

3 Mar

The high-level network architecture of LTE is comprised of following three main components:

  • The User Equipment (UE).
  • The Evolved UMTS Terrestrial Radio Access Network (E-UTRAN).
  • The Evolved Packet Core (EPC).

The evolved packet core communicates with packet data networks in the outside world such as the internet, private corporate networks or the IP multimedia subsystem. The interfaces between the different parts of the system are denoted Uu, S1 and SGi as shown below:
LTE Architecture

The User Equipment (UE)

The internal architecture of the user equipment for LTE is identical to the one used by UMTS and GSM which is actually a Mobile Equipment (ME). The mobile equipment comprised of the following important modules:

  • Mobile Termination (MT) : This handles all the communication functions.
  • Terminal Equipment (TE) : This terminates the data streams.
  • Universal Integrated Circuit Card (UICC) : This is also known as the SIM card for LTE equipments. It runs an application known as the Universal Subscriber Identity Module (USIM).

A USIM stores user-specific data very similar to 3G SIM card. This keeps information about the user’s phone number, home network identity and security keys etc.

The E-UTRAN (The access network)

The architecture of evolved UMTS Terrestrial Radio Access Network (E-UTRAN) has been illustrated below.
LTE E-UTRANThe E-UTRAN handles the radio communications between the mobile and the evolved packet core and just has one component, the evolved base stations, called eNodeB or eNB. Each eNB is a base station that controls the mobiles in one or more cells. The base station that is communicating with a mobile is known as its serving eNB.
LTE Mobile communicates with just one base station and one cell at a time and there are following two main functions supported by eNB:

  • The eBN sends and receives radio transmissions to all the mobiles using the analogue and digital signal processing functions of the LTE air interface.
  • The eNB controls the low-level operation of all its mobiles, by sending them signalling messages such as handover commands.

Each eBN connects with the EPC by means of the S1 interface and it can also be connected to nearby base stations by the X2 interface, which is mainly used for signalling and packet forwarding during handover.
A home eNB (HeNB) is a base station that has been purchased by a user to provide femtocell coverage within the home. A home eNB belongs to a closed subscriber group (CSG) and can only be accessed by mobiles with a USIM that also belongs to the closed subscriber group.

The Evolved Packet Core (EPC) (The core network)

The architecture of Evolved Packet Core (EPC) has been illustrated below. There are few more components which have not been shown in the diagram to keep it simple. These components are like the Earthquake and Tsunami Warning System (ETWS), the Equipment Identity Register (EIR) and Policy Control and Charging Rules Function (PCRF).
LTE EPCBelow is a brief description of each of the components shown in the above architecture:

  • The Home Subscriber Server (HSS) component has been carried forward from UMTS and GSM and is a central database that contains information about all the network operator’s subscribers.
  • The Packet Data Network (PDN) Gateway (P-GW) communicates with the outside world ie. packet data networks PDN, using SGi interface. Each packet data network is identified by an access point name (APN). The PDN gateway has the same role as the GPRS support node (GGSN) and the serving GPRS support node (SGSN) with UMTS and GSM.
  • The serving gateway (S-GW) acts as a router, and forwards data between the base station and the PDN gateway.
  • The mobility management entity (MME) controls the high-level operation of the mobile by means of signalling messages and Home Subscriber Server (HSS).
  • The Policy Control and Charging Rules Function (PCRF) is a component which is not shown in the above diagram but it is responsible for policy control decision-making, as well as for controlling the flow-based charging functionalities in the Policy Control Enforcement Function (PCEF), which resides in the P-GW.

The interface between the serving and PDN gateways is known as S5/S8. This has two slightly different implementations, namely S5 if the two devices are in the same network, and S8 if they are in different networks.

Functional split between the E-UTRAN and the EPC

Following diagram shows the functional split between the E-UTRAN and the EPC for an LTE network:
LTE E-UTRAN and EPC

2G/3G Versus LTE

Following table compares various important Network Elements & Signaling protocols used in 2G/3G abd LTE.

2G/3G LTE
GERAN and UTRAN E-UTRAN
SGSN/PDSN-FA S-GW
GGSN/PDSN-HA PDN-GW
HLR/AAA HSS
VLR MME
SS7-MAP/ANSI-41/RADIUS Diameter
DiameterGTPc-v0 and v1 GTPc-v2
MIP PMIP

Source: http://ershoeb.blogspot.nl/2016/03/lte-network-architecture.html

UMTS/LTE/EPC Call Flows for Handovers

15 Jul

 

Source: http://www.slideshare.net/JaChangMa/lte-hocallflowsv2014-0626

The Hidden Face of LTE Security Unveiled – new framework spells out the five key security domains

19 May

Stoke is very excited to roll out what we believe to be the industry’s first LTE security framework, a strategic tool providing an overview of the entire LTE infrastructure threat surface.  It’s designed to strip away the mystery and confusion surrounding LTE security and serve a reference point to help LTE design teams identify the appropriate solutions to place at the five different points of vulnerability in evolved packet core (EPC), illustrated in the diagram below:

 1) Device and application security; 2) RAN-Core Border (the junction of the radio access network with the EPC or S1 link); 3) Policy and Charging Control (interface of EPC with other LTE networks); 4) Internet border; 5) IMS core

LTE_Security_Framework

Here’s why we felt this was necessary:  Now that the need to protect LTE networks is universally acknowledged, a feeding frenzy has been created among the security vendor community. Operators are being deluged with options and proposals from a wide range of vendors.  While choice is a wonderful thing, too much of it is not, and this avalanche of offerings has already created real challenges for LTE network architects. It’s a struggle for operators to distinguish between the hundreds of security solutions being presented to them, and the protective measures that are actually needed.

This is because the concepts and requirements for securing LTE networks have only been addressed in theory, despite being addressed by multiple standards bodies and industry associations. In LTE architecture diagrams, the critical security elements are never spelled out.

Without pragmatic guidelines as to which points of vulnerability in the LTE network must be secured, and how, there’s an element of guesswork about the security function. And, as we’ve learned from many deployments where security has been expensively retrofitted, or squeezed into the LTE architecture as a late-stage afterthought, this approach throws up massive functional problems.

Our framework will, we hope, help address the siren call of the all-in-one approach. While the appeal of a single solution is compelling, it’s a red herring. One solution can’t possibly address the security needs of the five security domains. Preventing signaling storms, defending the Internet border, providing device security – all require purpose-appropriate solutions and, frequently, purpose-built devices.

Our goal is to help bring the standards and other industry guidelines into clearer, practical perspective, and support a more consistent development of LTE security strategies across the five security domains.  And since developing an overall LTE network security strategy usually involves a great deal of cross-functional overlap, we hope that our framework will also help create alignment about which elements need to be secured, where and how.

Without a reference point, it is difficult to map security measures to the traffic types, performance needs and potential risks at each point of vulnerability. Our framework builds on the foundations of the industry bodies including 3GPP, NGMN and ETSI and you can read more about the risks and potential mitigation strategies associated with different security domains in our white paper, ‘LTE Security Concepts and Design Considerations,’.

A jpeg version of the framework can be downloaded here.  Stoke VP of Product Management/Marketing Dilip Pillaipakam will be addressing the topic in detail during his presentation at Light Reading’s Mobile Network Security Strategies conference in London on May 21, and we will make his slides and notes of proceedings available immediately after the event.  Meanwhile, we welcome your thoughts, comments and insights.

 

White Papers
Name Size
The Security Speed of VoLTE Webinar (PDF) 2.2 MB
Security at the Speed of VoLTE (Infonetics White Paper) 848 Kb
The LTE Security Framework (JPG) 140 Kb
Secure from Go (Part I Only): Why Protect the LTE Network from the Outset? 476 Kb
Secure from Go (Full Paper): Best Practices to Confidently Deploy
and Maintain Secure LTE Networks
1 MB
LTE Security Concepts and Design Considerations 676 Kb
Radio-to-core protection in LTE, the widening role of the security gateway
— (Senza Fili Consulting, sponsored by Stoke)
149 Kb
The Role of Best-of-Breed Solutions in LTE Deployments—(An IDC White Paper sponsored by Stoke) 194 Kb

 

Datasheets
Name Size
Stoke SSX-3000 Datasheet 1.08 Mb
Stoke Security eXchange Datasheet 976 Kb
Stoke Wi-Fi eXchange Datasheet 788 Kb
Stoke Design Services Datasheet 423 Kb
Stoke Acceptance Test Services Datasheet 428 Kb
Stoke FOA Services Datasheet 516 Kb

 

Security eXchange – Solution Brief & Tech Insights
Name Size
Inter-Data Center Security – Scalable, High Performance 554 Kb
LTE Backhaul – Security Imperative 454 Kb
Charting the Signaling Storms 719 Kb
Operator Innovation: BT Researches LTE for Fixed Moile Convergence 470 Kb
The LTE Mobile Border Agent™ 419 Kb
Beyond Security Gateway 521 Kb
Will Small Packets Degrade Your Network Performance? 223 KB
SSX Multi-Service Gateway 483 KB
Security at the LTE Edge 345 KB
Security eXchange High Availability Options 441 KB
Scalable Security for the All-IP Mobile Network 981 Kb
Scalable Security Gateway Functions for Commercial Femtocell Deployments and Beyond 1.05 MB
LTE Equipment Evaluation: Considerations and Selection Criteria 482 Kb
Stoke Industry Leadership in LTE Security Gateway 426 Kb
Stoke Multi-Vendor RAN Interoperability Report 400 Kb
Scalable Infrastructure Security for LTE Mobile Networks 690 Kb
Performance, Deployment Flexibility Drive LTE Security Wins 523 Kb

 

È

Wi-Fi eXchange – Solution Brief & Tech Insights
Name Size
Upgrading to Carrier Grade Infrastructure 596 Kb
Extending Fixed Line Broadband Capabilities 528 Kb
Mobile Data Services Roaming Revenue Recovery 366 Kb
Enabling Superior Wi-Fi Services for Major Event and Locations 493 Kb
Breakthrough Wi-Fi Offload Model: clientless Interworking 567 Kb

 

Source: http://www.stoke.com/Blog/2014/05/the-hidden-face-of-lte-security-unveiled-new-framework-spells-out-the-five-key-security-domains/ – http://www.stoke.com/Document_Library.asp

Embedded Packet Capture, let’s go fishing for some packets!

27 Feb

EPC (Embedded Packet Capture) is another useful troubleshooting tool to occasionally capture traffic to be analyzed locally or exported to remote device. Occasionally, in contrast with RITE (Router IP Traffic Export) or SPAN on switches which are meant to have permanent flow of copied traffic directed to a traffic analyzer or IDS (Intrusion Detection System).

The configuration workflow is straightforward, but I would like to make a conceptual graphical analogy to illustrate it.

Let’s imagine traffic flowing through a router interface like the following:

Embedded Packet Capture

1- Capture point:

Specify the protocol to capture, the interface and the direction, this is the Here you indicate which IP protocol you need to capture.

monitor capture point ip cef CAPTURE_POINT fastEthernet 0/0 both
monitor capture point ipv6 cef CAPTURE_POINT fastEthernet 0/0 both

2- Packet buffer:


Memory area where the frames are stored once captured. 

monitor capture buffer CAPTURE_BUFFER

 

Embedded Packet Capture

3- ACL:


If needed you can filter a specific type of traffic, available only for IPv4. 

(config)#access-list 100 permit icmp host 192.168.0.1 host 172.16.1.1#monitor capture buffer CAPTURE_BUFFER filter access-list 100 

 

 

Except the optional IPv4 ACL, configured at the global configuration mode, everything else is configured at the privileged EXEC mode.

Embedded Packet Capture

4- Associate capture point with capture buffer

monitor capture point associate CAPTURE_POINT CAPTURE_BUFFER

You can associate multiple capture points (on the same or multiple interfaces) to the same buffer.

Embedded Packet Capture

5- Start and stop capture process

monitor capture point start CAPTURE_POINTmonitor capture point stop CAPTURE_POINT

 concept6

If you are familiar with wireshark, it will be easier to remember the steps needed to capture traffic.

Wireshark analogy

wireshark and Embedded Packet Capture

Deployment 1

Two capture points are created to capture IPv4 and IPv6 traffic into separate capture buffers.

monitor capture point ipv6 cef CAPTURE_POINT6 fa0/0 bothmonitor capture buffer CAPTURE_BUFFER6 

monitor capture point associate CAPTURE_POINT6 CAPTURE_BUFFER6

!

monitor capture point ip cef CAPTURE_POINT4 fa0/0 both

monitor capture buffer CAPTURE_BUFFER4

monitor capture point associate CAPTURE_POINT4 CAPTURE_BUFFER4

Following is the result on the router

Deployment 2

Two capture points are created to capture IPv4 and IPv6 traffic into single capture buffer.

monitor capture point ipv6 cef CAPTURE_POINT6 fa0/0 bothmonitor capture point ip cef CAPTURE_POINT4 fa0/0 both! 

monitor capture buffer CAPTURE_BUFFER46

!

monitor capture point associate CAPTURE_POINT6 CAPTURE_BUFFER46

monitor capture point associate CAPTURE_POINT4 CAPTURE_BUFFER46

 

Following is the result on the router

Exporting

!Example of export to tftpR1#monitor capture buffer CAPTURE_BUFFER46 export ftp://login:password@192.168.0.32/Volume_1/ecp.pcap 

Writing Volume_1/ecp.pcap

R1#

!Example of export to tftp

R1# monitor capture buffer CAPTURE_BUFFER46 export tftp://192.168.0.145/ecp.pcap

!

R1#

And the file opened in wireshark:

EPC traffic opened with wireshark

Source: http://cciethebeginning.wordpress.com/2014/02/26/embedded-packet-capture-lets-go-fishing-for-some-packets/

%d bloggers like this: