Re: [c-nsp] Brief CPU spikes on 6500 Sup 720

[Lincoln Dale]

On 17/07/2010, at 9:58 AM, Aaron Riemer wrote:
> Enabled SNMP traps and MAC-notifications and this brought another issue to
> my attention. There is a huge amount of mac-flapping going on (not for this
> host) but our ESX hosts that have vmnics trunking to both our cores.
> 
> The VM guys are sending traffic for each VM host out both connected vmnic's
> causing the MAC to be learnt on the vmnic port and the trunk port between
> the core switches hence the flapping.

your VM guys have seemingly configured their setup for link aggregation (port 
channel) without LACP (i.e. "mode on") but failed to tell you network guys.

suggest you configure the interface(s) facing these VMW servers to be 
port-channels.

if its 'across chassis' and these are not VSS'd C6Ks then you need them to 
change the loadbalancing policy.

see the NIC teaming section of 



> 
> Could this be contributing to the problem and possibly explain why MAC
> addresses are removed from the CAM table? No TCN's are noted so this surely
> isn't the reason. MAC age is set to 4 hours same as default ARP timeout..

it could be contributing to it, yes.

be thankful that the C6K learns mac addresses in hardware.  if it did not, 
likely you wouldn't have an operational network.

there may be other issues going on that this has been masking.  but addressing 
this is a good start to then allow you to see if there anything else awry going 
on.

> 
> I would prefer the VM team dedicated a NIC for their VM's to eliminate this
> kind of behaviour.

the default is in fact that way.  ("Route based on the originating virtual 
switch port ID").


cheers,

lincoln.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Brief CPU spikes on 6500 Sup 720

[Aaron Riemer]

Hi Lee,

Putting a static mac entry in stops the flooding for that particular unicast
destination. Therefore the MAC must be disappearing from the switches CAM
table.

Enabled SNMP traps and MAC-notifications and this brought another issue to
my attention. There is a huge amount of mac-flapping going on (not for this
host) but our ESX hosts that have vmnics trunking to both our cores.

The VM guys are sending traffic for each VM host out both connected vmnic's
causing the MAC to be learnt on the vmnic port and the trunk port between
the core switches hence the flapping.

Could this be contributing to the problem and possibly explain why MAC
addresses are removed from the CAM table? No TCN's are noted so this surely
isn't the reason. MAC age is set to 4 hours same as default ARP timeout..

I would prefer the VM team dedicated a NIC for their VM's to eliminate this
kind of behaviour.

Has anyone else experienced this?

Cheers,

Aaron.

-Original Message-
From: Lee [mailto:ler...@gmail.com] 
Sent: Friday, 16 July 2010 8:09 AM
To: Aaron Riemer
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720

>   3) Packet captures confirmed ...

Does a "sh mac-add add [destination mac address from the capture]" on
the flooding switch show that mac address?  For the correct vlan?  On
the Sup as well as all DFC equipped cards?

Can you ping the source and destination from the core switch?  Does
that stop the unicast flooding?

Regards,
Lee


On 7/15/10, Aaron Riemer  wrote:
> Guys,
>
> We are still seeing these floods. They occur when our backups run and it
> doesn't matter if the traffic is routed into the vlan or switched within
the
> same vlan as the same problem occurs.
>
> Therefore:
>   1) asymmetric routing cannot be the problem for the L2 switched traffic
>   2) No TCN's are occurring within the VLAN STP (PVST).
>   3) Packet captures confirmed that all ports on VLAN1 on one core were
> receiving the unicast traffic destined for a host on this vlan.
>   4) From the packet captures we were able to deduce source / dest MAC
> addresses confirming that the destination MAC was in fact not aging out
and
> could be seen clear as day in the MAC table.
>
> Had TAC on the line troubleshooting it for a couple of hours tonight and
> still no closer to solving the problem. Mac-age time out is set to the
same
> as the arp timeout (4 hours)
>
> I don't believe the issue is linked to the CPU spikes but rather the
output
> drops that we are seeing oversubscribing our 6548 line cards.
>
> Anyone have any further ideas?
>
> Thanks,
>
> Aaron.
>
> -Original Message-
> From: Phil Mayers [mailto:p.may...@imperial.ac.uk]
> Sent: Wednesday, 14 July 2010 11:14 PM
> To: Aaron Riemer
> Cc: 'Matthew Huff'; 'JC Cockburn'; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Brief CPU spikes on 6500 Sup 720
>
> On 14/07/10 15:51, Aaron Riemer wrote:
>> Yes i have read all about unicast flooding:
>>
>> Can occur by:
>>
>> 1) Asymmetric routing
>> 2) Spanning Tree TCN
>> 3) MAC aging out
>>
>> I cannot see any TCN's or Asymmetric routing so i think we may have to
>> adjust the mac aging as you suggested.
>
> If you're running HSRP, the standby node has a route for the subnet as
> well as the active e.g. traffic might flow out through the active, and
> back through the standby as follows:
>
> host
>   |
>   active-standby
>   ||
> (cloud)   ^
>   ||
>   router --/
>   |
> target
>
> from   host->active->router-target
> return target->router->standby->host
>
> ...if "standby" has an ARP entry (default 4 hours) but not MAC table
> entry (default 5 minutes) it will unknown-unicast-flood the return
> traffic. If it's a lot of traffic, that will burn a lot of bandwidth...
>
> Whether this will happen will depend on your routing topology.
>
>>
>> I am just trying to work out why the hell this has only just started
>> occurring!
>
> Well, without knowing the source of the traffic it's impossible to tell.
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] A few very Quick IP SLA questions

[Mikael Abrahamsson]

On Fri, 16 Jul 2010, Drew Weaver wrote:

2) If the router has multiple paths to the destination does specifying 
the source-address mean that 100% of the time it will use the Interface 
that the indicated source address is assigned to?


For IPv4 I've found this to be generally true (using loopback interface), 
for IPv6 in 12.4(24)T it's not true (bug filed and ACKed as a problem).


--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] A few very Quick IP SLA questions

[Devon True]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/16/2010 11:14 AM, Drew Weaver wrote:
> Also the main reason for implementing this is because we had an instance 
> where a interface didn't go down, but no traffic would pass through it 
> (routing protocols failed, etc) and we have our default routes setup as such:
> 
> ip route 0.0.0.0 0.0.0.0 Vlan4091 x.x.25.97
> ip route 0.0.0.0 0.0.0.0 Vlan4092 x.x.25.101
> 
> So return traffic was still being sent down the 'dead but up/up' interface 
> which caused obvious heartache.
> 
> Would using a track on each of these routes (combined with aforementioned IP 
> SLA probes) be a good way to prevent this from occurring in the future?
> 
> I basically want to ensure that both the interface is up and that traffic can 
> pass from this router to its gateway before the route will be used.
> 
> Sorry this is so long, hopefully it makes at least some sense.
> 
> I thought about using BFD, but it seems like they have removed support for 
> BFD on VLANs in recent code.

We use a method where our edge routers inject a default-route into our
OSPF process. The edge routers inject this routes based on the
connectivity to the Internet-facing interfaces or to other edge routers.

Example:

ip access-list standard ExternalPaths
 permit isp1 0.0.0.3
 permit isp2 0.0.0.3
 permit otherEdge 0.0.0.3
 permit anotherEdge 0.0.0.3

route-map AdvDefault permit 999
 match ip address ExternalPaths
!
router ospf 1
 default-information originate route-map AdvDefault

I do not know if that solution is applicable to your environment.

http://blog.ioshints.info/2007/06/ospf-default-route-design-scenarios.html
http://www.nil.si/ipcorner/OSPFDefaultMysteries/

- --
Devon
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxAmKEACgkQWP2WrBTHBS/7bQCeOuwkXZ2QR6zTAH+q0L2FRK2W
3YUAoLUOBUyOYFTMMOObywk+nJokd9Jn
=vXFK
-END PGP SIGNATURE-
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] A few very Quick IP SLA questions

[Drew Weaver]

Hi, thanks for your response.

>2) If the router has multiple paths to the destination does specifying 
the source-address mean that 100% of the time it will use the Interface 
that the indicated source address is assigned to?

No .. should be load-balanced.
--
If that is the case and the whole purpose is to determine whether or not the 
individual interfaces are passing traffic then couldn't using this method 
present false positives about which Interface is actually having a problem? I 
am currently using the 'connected (/30)' IP address as the destination.


My question about 'reachability vs state' tracking was basically just me being 
confused at how the state could be 'OK' if there was no reachability or how the 
reachability could fine if the state was not OK. is there a better choice to 
pick in my specific example?

thanks,
-Drew


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] routing between VRF and global

[Kenny Sallee]

I solved this problem (leaking routes from VRF to global route table) by
creating a 'VRF' that is the 'global' route table.  The cisco solution is
like you mentioned (GRE, Cable loopage, or static routes - none that I
liked).  So it physically looks like this:  MPLS WAN Frame DS3 w/ many PVCs
(for each different customer) -->Cisco ASR w/ VRF's per PVC --> Routes
imported to a VRF called 'global-vrf' --> cabled to a 6500 with global
routes.  I run BGP MP-BGP and peer with our core over the 'global-vrf' so I
can dynamically advertise all my customer routes to our core.  So - the ASR
runs MP-BGP (no label switching) and I route-target import/export between
VRF's with import-maps to control stuff.  I don't have NAT requirements so I
don't have to worry about that.  NAT and WCCP are other features that are
lacking depending on the version of code on whatever platform...

On Fri, Jul 16, 2010 at 6:17 AM, Jeff Bacon wrote:

> I have a mesh of 6500s connected via various gig fiber links. The 6500s
> have multiple VRFs defined, but of course most things interesting live
> in the global zone.
>
> I want a host on a VRF on a 6500 to be able to connect to another
> destination that is reachable through the global zone. Most likely it
> will be on the same 6500, but ideally it would be the same one way or
> the other.
>
> Basically, how do you leak routes between VRF and global? Between VRF
> and VRF I get. VRF<>global, not so clear; "MPLS fundamentals" provides a
> couple of examples but it's aimed more at a "how to connect VRF to
> internet so you have one static global route entry... ick.
>
> I can see the possible solution of creating a GRE tunnel within the
> switch itself, with one end in the VRF and the other end in the global
> and using "tun vrf" to get them to link, but this seems just a shade
> ugly (though it also happens to provide a nice fixed point in space for
> applying ACLs, etc.)
>
> Or of course there's the "hairpin" solution. I might be able to live
> with that, probably better than the GRE answer... but that doesn't mean
> I have to like it, does it? :)
>
> Thanks,
> -bacon
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] A few very Quick IP SLA questions

[Shimol Shah]

Inline

On 7/16/10 11:14 AM, Drew Weaver wrote:

Hi all, happy Friday.

A few questions regarding configuring IP SLA.

I've configured two IP SLA probes as such:

ip sla 1
  icmp-echo x.x.25.97 source-ip x.x.25.98
  frequency 10
ip sla schedule 1 life forever start-time now

ip sla 2
  icmp-echo x.x.25.101 source-ip x.x.25.102
  frequency 10
ip sla schedule 2 life forever start-time now

1) If I want this probe to run forever, is it best to configure it as a 
recurring probe or have the lifetime be 'forever'?


I would do "forever"

2) If the router has multiple paths to the destination does specifying 
the source-address mean that 100% of the time it will use the Interface 
that the indicated source address is assigned to?


No .. should be load-balanced.

Not related but beware of

CSCtf11508IP SLA should not send probes when source-interface has no 
ip address





3) When using the 'track command' (for example: track 100 ip sla 1 reachability 
| state) What is the functional difference between reachability and state? 
Wouldn't they be the same thing?



Take a look at

http://www.cisco.com/en/US/docs/ios/ipapp/command/reference/iap_t1.html#wp1148364



Also the main reason for implementing this is because we had an instance where 
a interface didn't go down, but no traffic would pass through it (routing 
protocols failed, etc) and we have our default routes setup as such:

ip route 0.0.0.0 0.0.0.0 Vlan4091 x.x.25.97
ip route 0.0.0.0 0.0.0.0 Vlan4092 x.x.25.101

So return traffic was still being sent down the 'dead but up/up' interface 
which caused obvious heartache.

Would using a track on each of these routes (combined with aforementioned IP 
SLA probes) be a good way to prevent this from occurring in the future?



Yes.


Shimol




I basically want to ensure that both the interface is up and that traffic can 
pass from this router to its gateway before the route will be used.

Sorry this is so long, hopefully it makes at least some sense.

I thought about using BFD, but it seems like they have removed support for BFD 
on VLANs in recent code.

Thanks,
-Drew

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] routing between VRF and global

[Shimol Shah]

Maybe something like below document

Route Leaking from a Global Routing Table into a VRF and Route Leaking 
from a VRF into a Global Routing Table

=

http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml#global

Shimol

On 7/16/10 9:17 AM, Jeff Bacon wrote:

I have a mesh of 6500s connected via various gig fiber links. The 6500s
have multiple VRFs defined, but of course most things interesting live
in the global zone.

I want a host on a VRF on a 6500 to be able to connect to another
destination that is reachable through the global zone. Most likely it
will be on the same 6500, but ideally it would be the same one way or
the other.

Basically, how do you leak routes between VRF and global? Between VRF
and VRF I get. VRF<>global, not so clear; "MPLS fundamentals" provides a
couple of examples but it's aimed more at a "how to connect VRF to
internet so you have one static global route entry... ick.

I can see the possible solution of creating a GRE tunnel within the
switch itself, with one end in the VRF and the other end in the global
and using "tun vrf" to get them to link, but this seems just a shade
ugly (though it also happens to provide a nice fixed point in space for
applying ACLs, etc.)

Or of course there's the "hairpin" solution. I might be able to live
with that, probably better than the GRE answer... but that doesn't mean
I have to like it, does it? :)

Thanks,
-bacon

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] A few very Quick IP SLA questions

[Drew Weaver]

Hi all, happy Friday.

A few questions regarding configuring IP SLA.

I've configured two IP SLA probes as such:

ip sla 1
 icmp-echo x.x.25.97 source-ip x.x.25.98
 frequency 10
ip sla schedule 1 life forever start-time now

ip sla 2
 icmp-echo x.x.25.101 source-ip x.x.25.102
 frequency 10
ip sla schedule 2 life forever start-time now

1) If I want this probe to run forever, is it best to configure it as a 
recurring probe or have the lifetime be 'forever'?
2) If the router has multiple paths to the destination does specifying the 
source-address mean that 100% of the time it will use the Interface that the 
indicated source address is assigned to?
3) When using the 'track command' (for example: track 100 ip sla 1 reachability 
| state) What is the functional difference between reachability and state? 
Wouldn't they be the same thing?

Also the main reason for implementing this is because we had an instance where 
a interface didn't go down, but no traffic would pass through it (routing 
protocols failed, etc) and we have our default routes setup as such:

ip route 0.0.0.0 0.0.0.0 Vlan4091 x.x.25.97
ip route 0.0.0.0 0.0.0.0 Vlan4092 x.x.25.101

So return traffic was still being sent down the 'dead but up/up' interface 
which caused obvious heartache.

Would using a track on each of these routes (combined with aforementioned IP 
SLA probes) be a good way to prevent this from occurring in the future?

I basically want to ensure that both the interface is up and that traffic can 
pass from this router to its gateway before the route will be used.

Sorry this is so long, hopefully it makes at least some sense.

I thought about using BFD, but it seems like they have removed support for BFD 
on VLANs in recent code.

Thanks,
-Drew

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] routing between VRF and global

[Pavel Skovajsa]

Hello Jeff,
Yes, sound strange, but everybody does this.
>From my experience it seems like the only purpose to split the network into
VRFs is to subsequently join these VRF due to various business requirements
:)

I learned most of the stuff from the MPLS Architectures Volume 2 book. Their
solution is to inject the routes into MP-BPG and import them in your VRF
config. If you search the archives you may be able to find some examples as
well.

-pavel skovajsa

On Fri, Jul 16, 2010 at 3:17 PM, Jeff Bacon wrote:

> I have a mesh of 6500s connected via various gig fiber links. The 6500s
> have multiple VRFs defined, but of course most things interesting live
> in the global zone.
>
> I want a host on a VRF on a 6500 to be able to connect to another
> destination that is reachable through the global zone. Most likely it
> will be on the same 6500, but ideally it would be the same one way or
> the other.
>
> Basically, how do you leak routes between VRF and global? Between VRF
> and VRF I get. VRF<>global, not so clear; "MPLS fundamentals" provides a
> couple of examples but it's aimed more at a "how to connect VRF to
> internet so you have one static global route entry... ick.
>
> I can see the possible solution of creating a GRE tunnel within the
> switch itself, with one end in the VRF and the other end in the global
> and using "tun vrf" to get them to link, but this seems just a shade
> ugly (though it also happens to provide a nice fixed point in space for
> applying ACLs, etc.)
>
> Or of course there's the "hairpin" solution. I might be able to live
> with that, probably better than the GRE answer... but that doesn't mean
> I have to like it, does it? :)
>
> Thanks,
> -bacon
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] routing between VRF and global

[Jeff Bacon]

I have a mesh of 6500s connected via various gig fiber links. The 6500s
have multiple VRFs defined, but of course most things interesting live
in the global zone. 

I want a host on a VRF on a 6500 to be able to connect to another
destination that is reachable through the global zone. Most likely it
will be on the same 6500, but ideally it would be the same one way or
the other. 

Basically, how do you leak routes between VRF and global? Between VRF
and VRF I get. VRF<>global, not so clear; "MPLS fundamentals" provides a
couple of examples but it's aimed more at a "how to connect VRF to
internet so you have one static global route entry... ick.

I can see the possible solution of creating a GRE tunnel within the
switch itself, with one end in the VRF and the other end in the global
and using "tun vrf" to get them to link, but this seems just a shade
ugly (though it also happens to provide a nice fixed point in space for
applying ACLs, etc.)

Or of course there's the "hairpin" solution. I might be able to live
with that, probably better than the GRE answer... but that doesn't mean
I have to like it, does it? :)

Thanks,
-bacon

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nagios SNMP ASR1002

[Adam Armstrong]

That's because your ASR runs IOS-XE rather than IOS.

Try walking .1.3.6.1.4.1.9.9.91, your sensors will be in there.

adam.


I can't find my ASR in that list.

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lee Riemer
Sent: jeudi 15 juillet 2010 19:18
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Nagios SNMP ASR1002

Enter your image name and see exactly what MIBs it supports.

http://tools.cisco.com/ITDIT/MIBS/MainServlet

On 7/15/2010 11:02 AM, Adam Armstrong wrote:

On 15/07/2010 09:55, Rens wrote:

Hi all,



I want to add ENV monitoring in Nagios for ASR1000 but a snmp walk on
1.3.6.1.4.1.9.9.1 result in a snmp error because that entry doesn't
exist.

How do I activate Cisco-ENVMON-MIB?


I see no sensors on my monitored ASRs in CISCO-ENVMON-MIB either.

You may want to try CISCO-ENTITY-SENSOR-MIB, Cisco usually replicate
most of the sensors there, thats'w here they are on the ASR1004.

If you're after a nice NMS which keeps track of sensors and the like,
myself and a bunch of Belgians are the developers of
http://www.observernms.org

CISCO-ENTITY-SENSOR-MIB support is removed at the moment as we're
rewriting the sensor detection code, but it should be back soon. :>

adam.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nagios SNMP ASR1002

[Rens]

I can't find my ASR in that list.

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lee Riemer
Sent: jeudi 15 juillet 2010 19:18
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Nagios SNMP ASR1002

Enter your image name and see exactly what MIBs it supports.

http://tools.cisco.com/ITDIT/MIBS/MainServlet

On 7/15/2010 11:02 AM, Adam Armstrong wrote:
> On 15/07/2010 09:55, Rens wrote:
>> Hi all,
>>
>>
>>
>> I want to add ENV monitoring in Nagios for ASR1000 but a snmp walk on
>> 1.3.6.1.4.1.9.9.1 result in a snmp error because that entry doesn't 
>> exist.
>>
>> How do I activate Cisco-ENVMON-MIB?
>
> I see no sensors on my monitored ASRs in CISCO-ENVMON-MIB either.
>
> You may want to try CISCO-ENTITY-SENSOR-MIB, Cisco usually replicate 
> most of the sensors there, thats'w here they are on the ASR1004.
>
> If you're after a nice NMS which keeps track of sensors and the like, 
> myself and a bunch of Belgians are the developers of 
> http://www.observernms.org
>
> CISCO-ENTITY-SENSOR-MIB support is removed at the moment as we're 
> rewriting the sensor detection code, but it should be back soon. :>
>
> adam.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] L2VPN with IP address

[Pshem Kowalczyk]

Hi,


On 16 July 2010 18:49, Asbjorn Hojmark - Lists  wrote:
{cut}
>
> You can do that with 'routed pseudowires' on 7600 with ES+
> http://www.cisco.com/en/US/docs/ios/12_2sr/release/notes/122SRrn.html#wp3970796
>

Thank you. That's looks like a winner to me :-)

kind regards
Pshem
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] L2VPN with IP address

[Asbjorn Hojmark - Lists]

On Fri, 16 Jul 2010 12:40:17 +1200, you wrote:

> I
> could get a xconnect going between one of the bigger boxes and the
> small PE, without actually wasting port on the bigger router (by
> having some sort of logical interface) then I could run the BGP
> session directly. I had a look on Cisco website, but either it's not
> possible or that kind of bridging has a special name that I can't pin
> down. If you've heard of such feature - please let me know.

You can do that with 'routed pseudowires' on 7600 with ES+
http://www.cisco.com/en/US/docs/ios/12_2sr/release/notes/122SRrn.html#wp3970796

-A

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/