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.