Single sflow source

[simwood-simon]

Hi folks

Whilst sflow-rt itself can receive samples from multiple sources, it seems the active-routes plugin bases its analysis on the last arm.sflow.ip set.

Is this intentional or a bug?

Thanks Simon

[sflow-rt]

The behavior is intentional. The active-routes application is designed to optimize the use of limited hardware routing tables in merchant silicon based switches: Internet router using merchant silicon IPv6 Internet router using merchant silicon

As you correctly point out, sFlow-RT can receive sFlow from many sources (and it can peer with many BGP routers). You can easily build general purpose route analytics applications for sFlow-RT: Real-time BGP route analytics

The following tutorial gives an introduction to developing sFlow-RT applications: Writing Applications

[simwood-simon]

Thanks. I'm familiar with the use case and it matches ours exactly, but it'd be quite unusual to deploy a single device. We run an active/active pair in ever site, where the routes to be installed in the FIB in a single site will be same (even if the next hop is actually the neighboring device). Being able to utlisise the stats for more than one source would be really handy.

On Wed, Apr 12, 2017 at 19:46, sflow-rt notifications@github.com wrote: The behavior is intentional. The active-routes application is designed to optimize the use of limited hardware routing tables in merchant silicon based switches: Internet router using merchant silicon [http://blog.sflow.com/2016/07/internet-router-using-merchant-silicon.html] IPv6 Internet router using merchant silicon [http://blog.sflow.com/2016/12/ipv6-internet-router-using-merchant.html]

As you correctly point out, sFlow-RT can receive sFlow from many sources (and it can peer with many BGP routers). You can easily build general purpose route analytics applications for sFlow-RT: Real-time BGP route analytics [http://blog.sflow.com/2016/07/real-time-bgp-route-analytics.html]

The following tutorial gives an introduction to developing sFlow-RT applications: Writing Applications [http://sflow-rt.com/writing_applications.php]

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [https://github.com/sflow-rt/active-routes/issues/2#issuecomment-293671783] , or mute the thread [https://github.com/notifications/unsubscribe-auth/AH4iDCTQ-sb6QWFjqMZ4hsWwZPYkSSB7ks5rvRv_gaJpZM4M7uFw] .

[sflow-rt]

It probably wouldn't be too hard to modify the script to add additional bgpAddSource() commands so that sFlow from both switches is used to update the route analytics and it would be possible to peer with both switches.

[simwood-simon]

Thanks. We'll look into trying that.

On Thu, Apr 13, 2017 at 0:07, sflow-rt notifications@github.com wrote: It probably wouldn't be too hard to modify the script to add additional bgpAddSource() commands so that sFlow from both switches is used to update the route analytics and it would be possible to peer with both switches.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [https://github.com/sflow-rt/active-routes/issues/2#issuecomment-293732174] , or mute the thread [https://github.com/notifications/unsubscribe-auth/AH4iDDBxc-JBLZri4BzyvPIPEC_MA4OIks5rvVkngaJpZM4M7uFw] .

[sflow-rt]

Please let me know if you run into difficulties and consider submitting pull request once you get it working since redundant router support would be a useful addition to the project.

Here is a link to the sFlow-RT mailing list with suggestions for debugging code in sFlow-RT "Best" way to debug apps?

[sflow-rt]

Can you explain the setup for the active / active pair ? It seems likely that they would not be carrying the same traffic and so the optimal FIB for each router would be different. Instead of feeding sFlow from both switches to each RIB, it might make more sense to keep them separate - essentially the same behavior as running two independent copies of the active-routes application in tandem. Does this make sense?

[simwood-simon]

So per PoP this’d be a pair of Aristas with MLAG to the inside of the network. These will have a large amount (circa 600) of peering sessions across the two, with some duplication but not entirely, as well as a default route transit on at least one of them. Given outbound traffic could hit either switch, the active routes are as relevant to both boxes, even if the route installed might be to the neighbouring switch. In a failure situation, the installed routes will obviously change but the prefixes remain just as relevant and, actually, I wouldn’t want to see the 90% of traffic that flows to peers, swing over to transit until it was picked up by a separate application.

I don’t imagine our architecture is that unique but our use case might be; as a very very heavily peered network with most traffic being b2c running test instances of SIR and your active-routes application (we’re still evaluating and will likely write our own at least in part) it looks like 5k routes in the FIB per PoP will be more than ample. We’re not desperately trying to optimise the use of 30k routes like many.

On 14 Apr 2017, at 15:34, sflow-rt notifications@github.com wrote:

Can you explain the setup for the active / active pair ? It seems likely that they would not be carrying the same traffic and so the optimal FIB for each router would be different. Instead of feeding sFlow from both switches to each RIB, it might make more sense to keep them separate - essentially the same behavior as running two independent copies of the active-routes application in tandem. Does this make sense?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sflow-rt/active-routes/issues/2#issuecomment-294164101, or mute the thread https://github.com/notifications/unsubscribe-auth/AH4iDGQG0qK_94ZdzYKOMWSpanrjeRx-ks5rv4PhgaJpZM4M7uFw.

[sflow-rt]

There are enhancements and bug fixes relating to the BGP functionality in sFlow-RT, please download the latest version from sFlow-RT.com. There is also an OpenAPI spec at /api-docs and a REST API explorer at /api/ for experimenting with queries that you might find useful.

Arista eAPI may be of interest since it shows how to issue eAPI requests to your Arista switches from sFlow-RT.