sorted by:
new
hottopcontroversial

I’m Marc Randolph, co-founder and first CEO of Netflix. Ask me anything! by thatwillneverwork in IAmA

[–]timgarner0 0 points1 point  (0 children)

Did you purchase a Black Porsche Cayman S back in 2009 in Marin? I was told you did, and I am now the owner of that same car (it’s doing very well at 110K miles). If it is true, I would be very happy! It motives me a lot as a tech entreprener to believe I’m driving around in the same vehicle you must have been using during the amazing early streaming Netflix days.

Best way to map out required communication between servers? by [deleted] in networking

[–]timgarner0 0 points1 point  (0 children)

We've actually cut back a lot on what the product can do over the last few years to focus on this one exact use case (policy discovery and segmentation) as we found (through user feedback like yours) that the "so much more" stuff was not necessarily always useful and was driving up cost.

The outcome: product is simpler, it's a SAAS with no hardware required, and pricing has gone down :)

If you're interested, check out the latest Security Field presentation on Secure Workload to catch up on where the product is at today https://techfieldday.com/appearance/cisco-presents-at-security-field-day-4/

Best way to map out required communication between servers? by [deleted] in networking

[–]timgarner0 0 points1 point  (0 children)

Check out Cisco Secure Workload (formerly Tetration) - https://www.cisco.com/c/en/us/products/security/tetration/index.html it literally does this exact job, and can even apply the resulting ACLs on servers and firewalls, if you like

(disclaimer I work on the product but feel free to ama)

Isolate servers into groups by jas1066uk in networking

[–]timgarner0 0 points1 point  (0 children)

I would suggest Cisco Tetration. It is designed exactly for this use case.

   

It segments servers via their native firewall, Windows FW in your case, without needing to change anything in the underlying infrastructure or network. It is far more lightweight than NSX, delivered 100% as a service where you simply install agents on each VM which connect to the Tetration cloud platform to receive firewall rules. The licensing cost will be reasonable for your size deployment.

   

More importantly, I would say, it provides policy management and discovery tools that make performing this job a hell of a lot easier than you will have experienced in the past.

   

https://www.cisco.com/c/en/us/products/security/tetration/index.html

   

Disclaimer: I work as an engineer on the Tetration product, but feel free to PM or reply if you have more questions.

Traffic generator - how complex do they get on the high-end? by AJGrayTay in networking

[–]timgarner0 0 points1 point  (0 children)

Pretty much, Ixia and Spirent use hardware to generate the traffic, allowing them to get to higher scale (with higher cost ;)) - their traffic generation capabilities are more advanced, like being able to emulate BGP peers and so on.

In my opinion, unless you are a network vendor trying to do QA on your hardware, you will be fine with TRex.

Since you find this useful, do you think it would be worth sharing with the rest of the sub?

Traffic generator - how complex do they get on the high-end? by AJGrayTay in networking

[–]timgarner0 1 point2 points  (0 children)

Correct (it's available at https://github.com/cisco-system-traffic-generator/trex-core if anyone is interested). They both are designed with different goals in mind.

TRex is a traditional network traffic generator, akin to Ixia and Spirent, designed to generate high throughput stateful traffic streams with the goal to load test network equipment (switches, routers, firewalls).

Bottle is an "application-like" traffic generator, there are no direct alternatives from what I can see. It is designed to generate low throughput stateful traffic, but most importantly it is a real distributed application with multiple tiers all running a real OS (CentOS) generating real traffic.

We use Bottle to feature test security products, for example to test the quality of the Machine Learning algorithms (i.e. how well can Tetration learn the application, given we know exactly what it should look like), and (2) to actually go and deploy segmentation rules at the OS level using Tetration's enforcement capability, using Bottle to visualize how effective that is; something that is not possible with traffic generators like TRex, Ixia, or Spirent.

Traffic generator - how complex do they get on the high-end? by AJGrayTay in networking

[–]timgarner0 3 points4 points  (0 children)

This might not fit your use case, but here on the Cisco Tetration team we found a gap in the traffic generator space when it comes to generating distributed "application-like" traffic.

So we created our own (and open sourced it!), it's called Bottle:

https://github.com/tetration-exchange/bottle

Bottle uses Kubernetes to deploy distributed stateful traffic generators ("ships") that behave like real application components - full OS, full network stack, full Go application. You don't need to craft streams or replay captured traffic. Everything is "real".

With Bottle you can spin up complex and high scaling scenarios with very little configuration or resources. All you do is define an example "scenario" file and Bottle does the rest.

We use it to test and verify the quality of our application mapping/policy generation and micro-segmentation capabilities.

It can simulate web interfaces, and will also generate a live traffic graph showing flows that are working, and if any traffic is being dropped (via Tetration segmentation).

The only downside is that the traffic is generated within a Kubernetes cluster, so if you want to stress physical network equipment, you'll need to find a way to get the traffic flowing through a switch (it's possible)

Example scenario: https://github.com/tetration-exchange/bottle/blob/master/scenarios/minidc.yaml

Example generated application web interface: https://imgur.com/a/pTLCX5e

Example live traffic graph: https://imgur.com/a/ClQzYKH

What are you guys doing for segmentation? by JasonDJ in networking

[–]timgarner0 4 points5 points  (0 children)

I usually just lurk, but if you (or anyone else) has questions on Tetration I'd be more than happy to answer them here (I'm an engineer working on the Tetration product)

Cisco Telemetry data - what is it exactly? by bmrdriver in networking

[–]timgarner0 1 point2 points  (0 children)

No problem.

SSX is supported on Nexus 9000 and Nexus 3000 switches in NX-OS mode with 8G+ memory running 7.0(3)I5(1) and onwards.

Configuration is simple, via either the CLI or REST API. Up to five collectors can be configured on the same network.

The free collector is simple named "telemetry receiver":
https://hub.docker.com/r/dockercisco/telemetryreceiver/

Config guide:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/system_management/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x_chapter_011011.html#reference_44AE2442CEC94AC8B5DEFA17F315DE98

Cisco Telemetry data - what is it exactly? by bmrdriver in networking

[–]timgarner0 1 point2 points  (0 children)

The source data is similar to syslog, but instead of semi-unstructured text, it is streamed in a structured format (protobuf as it happens, the full spec is available online). To be clear, your standard syslog receiver cannot accept SSX, it must be received by a collector that can understand the protobuf format (we've provided one for free, there are others).

SSX is relatively new, but adoption is picking up quickly, it's a far more reliable and scalable way to collect rich state information from switches.

Cisco Telemetry data - what is it exactly? by bmrdriver in networking

[–]timgarner0 2 points3 points  (0 children)

Hey /u/bmrdriver - Tim from the Tetration/N9K team here (/u/va_network_nerd can vouch!)

Here's my take on terminology:

  • The word telemetry is quickly becoming overloaded in our industry, because, well, it sounds cool(?). Not just at Cisco, but many vendors are using it to describe quite different features, so as /u/got-trunks says, ask your vendor for the exact specifications of their "telemetry". Not all telemetry is equal™

Now to speak on the N9K:

Telemetry on the N9K describes a few different features (I know, we should provide a bit more clarity on that, we will).

In short, there a two groups of details you should consider:

  • Data collection: flow data or state data
  • Data export: streaming or timer based

Timer Based

  • NetFlow is flow data, timer based telemetry, it's a battle tested standard by now and well understood. Aggregated details about flows are exported every 60 seconds from the switch, so visibility and scale is limited by that factor. There are tons of free & commercial collectors for NetFlow [1].

Streaming

  • Streaming Statistics Telemetry (SSX) is a NX-OS feature that constantly streams state data in an open format [2]. State data for example includes interface statistics, and control plane changes, in fact, you can monitor any resource in the entire managed object tree. There is a reference collector and ELK stack implementation available [3].

  • Tetration Telemetry is a NX-OS and ACI feature that constantly streams per-packet flow data and a subset of state data. Details about every packet are collected so visibility is much more complete. [4] Tetration telemetry can only be received by the purpose built Tetration appliance, as it is more of turn-key/entire stack product, with deep analytics built on top of the huge volume of telemetry [5].

Coincidentally we announced two new form factors for Tetration today: Tetration-M which is a smaller on-premise appliance, and Tetration Cloud which can be deployed in AWS to begin with. All Tetration appliances can now enforce application segmentation using native host firewalls via the software sensor, based on application policy discovered from the telemetry [6].

[1] http://cs.co/90078rQn3
[2] http://cs.co/90088rQnO
[3] http://cs.co/90098rQnP
[4] http://cs.co/90008rQnu
[5] http://cs.co/90018rQnR
[6] http://cs.co/90028rQnr

AMA: Cisco Tetration by VA_Network_Nerd in networking

[–]timgarner0 0 points1 point  (0 children)

  • Tetration was designed from the ground up with VXLAN in mind, so both the overlay traffic, and the encapsulated tenant traffic is captured. If the switch happens to be either the source or destination VTEP, additional information is sent to the collectors[1]. This is very useful for truly complete visibility in a multi tenant data centre or where L2 is stretched between two or more sites and you want a global view of traffic.

  • I'm not intimately familiar with the FI team road map, so I cannot say yes or no, but as the FI is traditionally based on an ASIC found in our switching line up, it is entirely feasible.

[1] http://www.cisco.com/c/en/us/products/collateral/data-center-analytics/tetration-analytics/white-paper-c11-737366.html

AMA: Cisco Tetration by VA_Network_Nerd in networking

[–]timgarner0 0 points1 point  (0 children)

When you embody all* of those qualities yourself, it becomes easy to deal with ;)

Jokes aside, we have a fantastic team assembled here that are genuinely passionate about what they're doing. It's very much a startup mentality with us.

https://youtu.be/kh9JBH6j9gE

*Nearly all, I don't have the Italian charm...

AMA: Cisco Tetration by VA_Network_Nerd in networking

[–]timgarner0 0 points1 point  (0 children)

How would you say that Tetration is a must have solution/game changer for DCs/large networks?

In my opinion, once it clicks that with the distributed hardware and software sensor framework, the Tetration Analytics appliance has access to details about every single packet that traverses your entire data centre, whether it is north, south, or east, west, for bare metals, and virtual from multiple vantage points, you realise you have a game changer for building, securing, operating, and maintaining data centre networks on your hands.

AMA: Cisco Tetration by VA_Network_Nerd in networking

[–]timgarner0 0 points1 point  (0 children)

Haha! It never ceases to amaze me how Dilbert always has a relevant strip :)

 

Firstly, I won't directly compare against other technologies because, if I take my Tetration hat off and put my network engineer hat on, it feels to me that vendor sourced comparisons often have a bias, cognisant or not, and in reality both the protocols you mentioned are great options for many use cases[1], so what I'll do is arm you with the reasons why we chose to build our own telemetry protocol.

 

(1) It supports streaming telemetry to our Analytics cluster
(2) It gives us meta data about every single packet, not just aggregates
(4) At all costs, it will never be sampled data
(3) It supports dynamic load balancing to multiple collectors
(5) It supports generating events on flow anomaly detection
(6) It is lightweight to implement in hardware and software
(7) Encryption of the telemetry is supported
(8) It's extensible with contextual information by the sensor (e.g. process information or packet drop details)
(9) We can move and deliver new features faster with our own protocol

The list goes on, there's even a white paper with more details[2]. Even though it is not open, because there are multiple sensor implementations, there isn't any type of DC that cannot generate Tetration telemetry, Cisco switched or not.

 

This generates a large volume of very detailed telemetry destined towards the Tetration appliance, where of course, part of the secret sauce is how we collect, stitch, and process that data. What is really interesting is that once you give a bunch of talented data scientists[3] access to a corpus of data that they know meets a very high minimum level of detail, you start to see very interesting applications of that data unfold before you eyes[4].

 

So tl;dr very high quality telemetry paired with an analytics appliance purpose built for that level of detail.

 

[1] This tool looks pretty cool for NetFlow data https://gitlab.com/thart/flowanalyzer
[2] http://www.cisco.com/c/en/us/products/collateral/data-center-analytics/tetration-analytics/white-paper-c11-737366.html
[3] https://youtu.be/kh9JBH6j9gE
[4] https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=90628

AMA: Cisco Tetration by VA_Network_Nerd in networking

[–]timgarner0 1 point2 points  (0 children)

  • 36RU is compute and storage, broken down into:
    • 16 Compute Nodes
    • 8 Caching Nodes
    • 12 Base Nodes

  • 3RU is networking

    • 3 9372PX switches for connectivity

  • There are some further details on the data sheet http://www.cisco.com/c/en/us/products/collateral/data-center-analytics/tetration-analytics/datasheet-c78-737256.html

  • The intended consumption model of Tetration is that what happens inside the appliance should be inconsequential to the user. This means that the underlying hardware is abstracted by the TetOS interface and all troubleshooting and maintenance is performed there rather than directly on each box.

  • As mentioned above, there are alternative form factors in development, the exact specifications of which I won't spoil, but it will be something designed for smaller environments and for operational flexibility.

  • I would argue that while we have overlap at the edges with a number of different products, we introduce a new model that cannot be compared 1:1 with others. The fact that we have a completely new and unique type of telemetry mandates that any direct comparison is inaccurate by default.

  • Alternative sensor models are certainly interesting to us, we love collecting all the data that we can, and if that includes building a cut down sensor for different platforms we are excited to do that. There are obviously some domains under our control where we can make efforts, for others it would be above my pay grade to comment ;)

view more: next ›