[ixpmanager] sflow daemon

[Nick Hilliard]

>From the user perspective, just sflow stats.  I don't think there's any
other impact.

Nick

On 11/12/2013 10:32, Rowan Thorpe wrote:
> Brian,
> 
> I scanned back through this and preceding threads, so I understand what
> the core of the Juniper problem is, but if you don't mind could you
> please tell me a quick summary of what is actually visibly/tangibly
> "broken" by this Juniper issue, from the end-users' perspective? I ask
> because we are now about to migrate to using the exact same switches,
> and I am trying to be proactive, rather than reaching "testing phase"
> before dealing with it (and I haven't looked at the code for several
> months so I'm a bit rusty about what affects what). Are the issues just
> cosmetic/minor, causing one or two graphs not to render? Or is it a
> showstopper, making the entire interface dysfunctional? If I remember
> correctly, not being able to grok the MACs runs quite deep doesn't it?
> 
> Thanks,
> Rowan
> 
> BTW: I know Barry and Nick are dealing with the "Right Way (TM)" to
> fix the problem rather than with "one-off hacks", but I suspect that
> will take a while, and in the meantime, although we've had IXP-Manager
> running on a testing server for several months accessing our present
> (Extreme) switch, our IXP intended to take IXP-Manager live in about a
> week - with our *new* switches - so I'm investigating what assumptions
> I can make and what kludge I can implement to get us by for now in the
> colourful world of Juniper. One of our router team just told me that
> for *us*, for *now-and-the-near-future*, we are not using any non
> access-ports (".x", where x != 0), so I suspect I can just presume to
> receive all the xx.0 data and chop the ".0"s off the end and be done
> with it. Obviously this is a huge assumption, and therefore a really
> ugly and site-specific kludge (and one that should be gotten rid of as
> soon as a proper solution is found), but I mention it in case you are
> in a similar position, and it might provide a similar short-term
> solution. If so, let me know and I will forward you a link to whatever
> patch I can come up with. I guess that it can just be added to the
> normalize_mac() function I previously added to update-l2database.pl,
> which massages the received data before processing, and if I just set
> that to run from cron more frequently, and somehow stop the php code
> from scanning for MACs at all, it should work in an "almost realtime"
> way... (Barry or Nick: does that sound sane, or have I fundamentally
> misunderstood something?).
> 


-- 
Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 6169698
3 Westland Square    | INEX - Internet Neutral | Fax: +353 1 6041981
Dublin 2, Ireland    | Exchange Association    | Email: nick at inex.ie