[ixpmanager] sflow daemon

Rowan Thorpe rowan at rowanthorpe.com
Wed Dec 11 10:32:10 GMT 2013


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?).

-- 
"There is a great difference between worry and concern. A worried
person sees a problem, and a concerned person solves a problem."
 - Harold Stephens



More information about the ixpmanager mailing list