We've created a PW that works between the ASR907 and the ASR903 with a single service instance on each side that expects a single VLAN tag. When we create a flow in the Spirent with 9000 MTU, we see close to 100% utilization, which is expected. So basically, setup works perfectly. This works with two kinds of Spirent generated flows: one, ethernet frames exclusively and the second same succesful results when using IPv4 payload within ethernet frames. At this point, we're good and everything works.
Our problem starts when we use the exact same flows (mind you, we change the VLAN tag) and instead of using a P2P PW, we use a P2P via VPLS configuration (a multipoint scenario with only two endpoints). As long as the Spirent test traffic is solely ethernet-based (no IPv4) we see close to 100% utilization with no drops on the Spirent. Basically, same successful scenario as mentioned above. But, when we change that flow to use ethernet+IPv4, the see around 40% traffic loss, being this (and the VLAN tag) the only changes we make to the Spirent.
Please keep in mind that we're using the exact same Spirent created devices and flows for both tests, 3 of which work as expected. The problem arises when we configure the Spirent to instead of ethernet-only frames, it should send IPv4 payload within the ethernet frames.
We tried creating, 2 separate VPLS services with 5G worth of trafic each via the Spirent, and see the same behavior.
Setting up some 3rd party devices for my Fire and Rescue trucks that will VPN back to our FPR-2110. I can blatantly see what's going on with the IKEv2 platform and protocol debugs on. It's selecting the wrong dynamic map!IKEv2-PLAT-4: (32): Cry...
On January 22, 2020, the Cisco Product Security Incident Response Team (PSIRT) disclosed a vulnerability in the web-based management interface of Cisco Firepower Management Center (FMC). The vulnerability could allow an unauthenticated, remote attac...
Meet the Authors Event - A Cybersecurity Deep Dive with Omar Santos
(Live event – Thursday, January 23rd, 2020 at 10:00 a.m. Pacific / 1:00 p.m. Eastern / 7:00 p.m. Paris)
This event will have place on Thursday 23rd, January 2020 at 10hrs PDT
Posting this for anyone interested in using a Raspberry PI as a flow collector for Stealthwatch. We created a very lightweight version of our software. It can create flows if the eth port is attached to a SPAN or you can forward NetFlow/IPFIX ...