[ixpmanager] sflow daemon

Brian Thompson brian.thompson at iovation.com
Wed Dec 11 18:04:17 GMT 2013


Nick,  I am not sure who you are referring to as the "user"


Anything to do with layer 2 basicly:
Peering DB
Sflow
Mac Addresses



*Brian Thompson*
Senior Infrastructure Engineer // Senior Second Guesser

Direct: 503.943.6779
Mobile: 503.707.9018 // Twitter: iovation
*www.iovation.com <http://www.iovation.com/>*



On Wed, Dec 11, 2013 at 9:43 AM, Nick Hilliard <nick at inex.ie> wrote:

> 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
> _______________________________________________
> INEX IXP Manager mailing list
> ixpmanager at inex.ie
> https://www.inex.ie/mailman/listinfo/ixpmanager
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20131211/fd8aa17b/attachment.html>


More information about the ixpmanager mailing list