well then if nobody else out there gets it right, then that just screams "opportunity" for Observium!
we can just all hope that it doesn't wind up giving Adam Mike and Tom too much brain damage.
:-)
R.
PS: DNS separation I could see as logical for VDCs. But for VRFs? That's banannas to have to try do. Don't even know that it'd fully function. (e.g., traps etc. are pinned to source from just one vrf; how to map back the event blame of $other_vrf_"device" as culprit?) Screws loose in San Jose, for sure.
Chris & Darius wrote:
Date: Wed, 24 Jul 2013 16:01:59 -0400 From: Chris Moody chris@node-nine.com To: Observium Network Observation System observium@observium.org Subject: Re: [Observium] remedies to overcome vrf dance? Message-ID: 51F032B7.5060607@node-nine.com Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
I can say we've had nothing but pain in trying to get all the context-mapping stuff recognized by pretty much every tool we use. Because of how Cisco implemented this, even some of our inventory apps are confused and think we have 3x more Nexus chassis than we actually do because in their logic, each context-mapped VRF is a separate device.
IMHO, I -hate- the way Cisco has "updated" SNMP on the Nexus platform.
One workaround we've had to use is to use DNS names per L3 interface, so that we can refer to the vrf/device as say 'Nexus1_mgmt0.foo.com'(which is part of the 'management' vrf) & 'Nexus1_eth1-1.foo.com'(which is part of the 'vrf1' vrf). This way applications think of them as separate devices due to the hostname/IP differences.
-Chris
On 7/24/13 1:29 PM, Darius Seroka wrote:
Hi Rob,
I posted a similar comment a few weeks/months back but my problem was with c6500's. Indeed it was the way cisco describes the vrf's so only thing that can be done is getting them to do their oid's more uniformly across their product range. I was not able to open a support request with the c6500s so dont have any tickets to refer to.