Re: [c-nsp] Event Manager Script
Hi , thanks and sorry for the late replyI am facing some issues with the script , when the IP SLA is down , the router did not wait for the 5 minutes , it reloaded directly From: oboeh...@cisco.com To: gunner_...@live.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Event Manager Script Date: Sun, 2 Mar 2014 12:33:34 + Hi allI am trying to do a event manager script that will do the below and need some assistanceI want to ping to a specific destination and if the ping request timed out for a period of for example 5 minutes , the router should be reloaded not sure whether this is a good idea or not (the router could reload forever), here is a way to achieve the goal: ip sla 1 icmp-echo destination-addr frequency 20 ip sla schedule 1 life forever start-time now ! track 1 ip sla 1 reachability delay down 300 ! event manager applet reload-if-down event track 1 state down action 1.0 syslog msg Reloading the router due to unreachability action 2.0 reload hope this helps.. oli ___ 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] Event Manager Script
In IP SLA you can set the reaction-configuration thresholds. Try that. Jey S. Network Engineer CCIE #41608 Sent from my iPhone On 5 Mar 2014, at 08:32, M K gunner_...@live.com wrote: Hi , thanks and sorry for the late replyI am facing some issues with the script , when the IP SLA is down , the router did not wait for the 5 minutes , it reloaded directly From: oboeh...@cisco.com To: gunner_...@live.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Event Manager Script Date: Sun, 2 Mar 2014 12:33:34 + Hi allI am trying to do a event manager script that will do the below and need some assistanceI want to ping to a specific destination and if the ping request timed out for a period of for example 5 minutes , the router should be reloaded not sure whether this is a good idea or not (the router could reload forever), here is a way to achieve the goal: ip sla 1 icmp-echo destination-addr frequency 20 ip sla schedule 1 life forever start-time now ! track 1 ip sla 1 reachability delay down 300 ! event manager applet reload-if-down event track 1 state down action 1.0 syslog msg Reloading the router due to unreachability action 2.0 reload hope this helps.. oli ___ 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] Event Manager Script
can you just remove the action 2.0 reload from the script for the test so the router just spits out the syslog and then send the logs? I noticed that the maximum delay down value accepted by the parser is 180 (3 minutes), maybe it didn't accept the command when you pasted it? I just tested this (with 60 sec delay), and it seems to work fine (debug track enabled): router(config)# Mar 5 09:53:14.230: Track: 99 Down change delayed for 60 secs Mar 5 09:54:14.231: Track: 99 Down change delay expired Mar 5 09:54:14.231: Track: 99 Change #3 ip sla 99, reachability Up-Down Mar 5 09:54:14.231: %TRACKING-5-STATE: 99 ip sla 99 reachability Up-Down Mar 5 09:54:14.239: %HA_EM-6-LOG: reload-if-down: Reloading the router due to unreachability and as EEM only triggers on up-down transition, it only takes action when the probe was up at least once. so this is good.. oli From: M K gunner_...@live.commailto:gunner_...@live.com Date: Wednesday, 5 March 2014 09:26 To: Oliver Boehmer oboeh...@cisco.commailto:oboeh...@cisco.com, cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Event Manager Script Hi , thanks and sorry for the late reply I am facing some issues with the script , when the IP SLA is down , the router did not wait for the 5 minutes , it reloaded directly From: oboeh...@cisco.commailto:oboeh...@cisco.com To: gunner_...@live.commailto:gunner_...@live.com; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Event Manager Script Date: Sun, 2 Mar 2014 12:33:34 + Hi allI am trying to do a event manager script that will do the below and need some assistanceI want to ping to a specific destination and if the ping request timed out for a period of for example 5 minutes , the router should be reloaded not sure whether this is a good idea or not (the router could reload forever), here is a way to achieve the goal: ip sla 1 icmp-echo destination-addr frequency 20 ip sla schedule 1 life forever start-time now ! track 1 ip sla 1 reachability delay down 300 ! event manager applet reload-if-down event track 1 state down action 1.0 syslog msg Reloading the router due to unreachability action 2.0 reload hope this helps.. oli ___ 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] Event Manager Script
Hi Try with 120 seconds delay. Also use environment variable to depicting to get email whensoever event triggers. Ami On Wednesday, March 5, 2014 10:01 AM, Oliver Boehmer (oboehmer) oboeh...@cisco.com wrote: can you just remove the action 2.0 reload from the script for the test so the router just spits out the syslog and then send the logs? I noticed that the maximum delay down value accepted by the parser is 180 (3 minutes), maybe it didn't accept the command when you pasted it? I just tested this (with 60 sec delay), and it seems to work fine (debug track enabled): router(config)# Mar 5 09:53:14.230: Track: 99 Down change delayed for 60 secs Mar 5 09:54:14.231: Track: 99 Down change delay expired Mar 5 09:54:14.231: Track: 99 Change #3 ip sla 99, reachability Up-Down Mar 5 09:54:14.231: %TRACKING-5-STATE: 99 ip sla 99 reachability Up-Down Mar 5 09:54:14.239: %HA_EM-6-LOG: reload-if-down: Reloading the router due to unreachability and as EEM only triggers on up-down transition, it only takes action when the probe was up at least once. so this is good.. oli From: M K gunner_...@live.commailto:gunner_...@live.com Date: Wednesday, 5 March 2014 09:26 To: Oliver Boehmer oboeh...@cisco.commailto:oboeh...@cisco.com, cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Event Manager Script Hi , thanks and sorry for the late reply I am facing some issues with the script , when the IP SLA is down , the router did not wait for the 5 minutes , it reloaded directly From: oboeh...@cisco.commailto:oboeh...@cisco.com To: gunner_...@live.commailto:gunner_...@live.com; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Event Manager Script Date: Sun, 2 Mar 2014 12:33:34 + Hi allI am trying to do a event manager script that will do the below and need some assistanceI want to ping to a specific destination and if the ping request timed out for a period of for example 5 minutes , the router should be reloaded not sure whether this is a good idea or not (the router could reload forever), here is a way to achieve the goal: ip sla 1 icmp-echo destination-addr frequency 20 ip sla schedule 1 life forever start-time now ! track 1 ip sla 1 reachability delay down 300 ! event manager applet reload-if-down event track 1 state down action 1.0 syslog msg Reloading the router due to unreachability action 2.0 reload hope this helps.. oli ___ 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] (no subject)
Hi A small question please, on Cisco ME3400/3800 With this config: interface GigabitEthernet0/15 switchport trunk allowed vlan none switchport mode trunk speed 100 duplex full no cdp enable service instance 11 ethernet encapsulation dot1q 1-4094 bridge-domain 909 ! The cisco encapsule the Spaning tree and other L2 Protocole into the vlan 909 ? thanks Olivier ___ 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] Cisco mem issue
Has anyone experienced the recently announced mem issue? http://www.cisco.com/web/about/doing_business/memory.html affected parts: http://www.cisco.com/web/about/doing_business/memory_pu.html Proposed fix-on-fail solution seems risky. -- Tassos ___ 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] (no subject)
Hi Oliver Not by default, You'd have to enable l2protocol forward/peer under the service instance adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Olivier CALVANO Sent: Wednesday, March 05, 2014 11:41 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] (no subject) Hi A small question please, on Cisco ME3400/3800 With this config: interface GigabitEthernet0/15 switchport trunk allowed vlan none switchport mode trunk speed 100 duplex full no cdp enable service instance 11 ethernet encapsulation dot1q 1-4094 bridge-domain 909 ! The cisco encapsule the Spaning tree and other L2 Protocole into the vlan 909 ? thanks Olivier ___ 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] Cisco mem issue
On 05/03/2014 12:32, Tassos Chatzithomaoglou wrote: Has anyone experienced the recently announced mem issue? http://www.cisco.com/web/about/doing_business/memory.html affected parts: http://www.cisco.com/web/about/doing_business/memory_pu.html Proposed fix-on-fail solution seems risky. cheaper and easier than RMAing all customer equipment. As it stands, Cisco is booking a charge of $655m to handle this problem with a fix-on-fail approach: http://blogs.cisco.com/news/ciscos-commitment-to-customers/ Nick ___ 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] Cisco Security Advisory: Multiple Vulnerabilities in Cisco Wireless LAN Controllers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Multiple Vulnerabilities in Cisco Wireless LAN Controllers Advisory ID: cisco-sa-20140305-wlc Revision 1.0 For Public Release 2014 March 5 16:00 UTC (GMT) Summary === The Cisco Wireless LAN Controller (WLC) product family is affected by the following vulnerabilities: * Cisco Wireless LAN Controller Denial of Service Vulnerability * Cisco Wireless LAN Controller Unauthorized Access to Associated Access Points Vulnerability * Cisco Wireless LAN Controller IGMP Version 3 Denial of Service Vulnerability * Cisco Wireless LAN Controller MLDv2 Denial of Service Vulnerability * Cisco Wireless LAN Controller Crafted Frame Denial of Service Vulnerability * Cisco Wireless LAN Controller Crafted Frame Denial of Service Vulnerability Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140305-wlc -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTFyueAAoJEIpI1I6i1Mx3QjIQALqJuwk1Y8YJAG+QM86XNUw3 aT3rlIPdAazREbXTX4VjLVyvdlfdhq8nQOjWf11ipkOU2FvGG+CM4fjk2Mz/4yUv YENEQLb8PZIzAaQh+Jk40DSVlEaNw6QdM5qg/4mz35BDc03TPMOos3W1wB6/erJj D8ml9HxU9+l29RNDkWeeatJUIrpL2jP6YiYdctBSqpm0KP4i5sv8DIMMWvMMqny0 D3rUqlLbYKGA2M6Ho9yOB7f/OF9QckDDqhkMagV1xPMF8ii+1EgLyTD1g33+6Hi5 YS/MrHiRr9g8n0NZQdcM3hfOTZc09ucw5/3iPqhC2H/XGVJOSq8w9vGNjY6dpP9s p0CiNmoX2bISLCzKPkfM9LzeFBENJjhR0owGeGpSvwCgwJ9n97Z9xUqfok+X57QA fenzUOv7dY508+ULBiMr98DWdx59U7fjX61i1Gl361+f8yGljSI+Cp2ObWKHy+gD sa+Em7P7rNUZ/lkzC7vW0svqNNiZioNK9t3SP/MjSUE2qSwpPVUow+FrnR3q/o3l B5Fi3gMxOwCu2pLFgIiIvILDRWU3t0z1PlGv2sF0QmXgFAtd0/aPRDmHTqJ2mi1N stGO/bk1nOcUcPdPLLOy1GQeJzLCR1ow6+FRDCu7BixGjZp5U3/UZtjwoz/ebQnK WCGLHbeJbNdGzOFxAaqz =LECh -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/
[c-nsp] Cisco Security Advisory: Cisco Small Business Router Password Disclosure Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco Small Business Router Password Disclosure Vulnerability Advisory ID: cisco-sa-20140305-rpd Revision 1.0 For Public Release 2014 March 5 16:00 UTC (GMT) +- Summary === A vulnerability in the web management interface of the Cisco RV110W Wireless-N VPN Firewall, the Cisco RV215W Wireless-N VPN Router, and the Cisco CVR100W Wireless-N VPN Router could allow an unauthenticated, remote attacker to gain administrative-level access to the web management interface of the affected device. The vulnerability is due to improper handling of authentication requests by the web framework. An attacker could exploit this vulnerability by intercepting, modifying and resubmitting an authentication request. Successful exploitation of this vulnerability could give an attacker administrative-level access to the web-based administration interface on the affected device. Cisco has released free software updates that address this vulnerability. There are currently no known workarounds that mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140305-rpd -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (SunOS) iQIVAwUBUxdNdYpI1I6i1Mx3AQKOVQ//fDCH4hGeCpP1cWb2Huz9Oca8WqiDDzFZ yItR++/l1/vFnQpe7hXmuEt1g/eCSOgV7jF/ILCpEjGN7Kh2zF/uYenBX8t6QYsr nd/yO9gr82B/MwMPl8W5HU5jlpo+s82sbIr7X5TGv8+m3yTBLfboD27TQzkuzlZH EoaOd/UnCHWKYJR+ADjG6+HLPY1zvr+gcycsrI8eTPzZmWp5rMjhlNgApYTRcC7P g9EDG5qkkroEWufZpjC6ZX1KwE227WA8EFe0v34xlPjXYGdQK431qDK02QH85fkb lOHpqFfRGAjuVyIhp99cQ+bXCx1vsBoB9vul/L0It68yeo8HePnnAlnjNhEkhQZg cLAwZpEY/ndvcIjj03qfi/q9IFYLpjMrpaJhUJV1Z7Tan2gBf5u5ISlAvqqFIfgo U6X0Lg8nDvN133I1jLCpdpeUKVm19WXntx5oqo/5YWshdClfP2B7Jx7mKLv72Ff4 BpNMQCAXXfa4xV4YQrMPxUlcfwSs8+BVzMaKN0Ewbph/z6fbW/uTCTmy+D1Guu9q G2XA2/Hk7h8+O7gJf5OiHFl/5sHlGeLQ3HHN2+jnizOh66vm/Nko8wc7RtMSfWnh 0mOLK7HHYkPFvnZpLVEHHi7l1CcAHIj+qKt2ZX65I7GQgGWq76usZntIaiqAslij hc8D2np3qGo= =uInA -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] Cisco mem issue
Dell - Internal Use - Confidential I wasn't aware of this announcement, but we did experience this on a software upgrade of a 6506-E almost a year ago where a perfectly working WS-X6724-SFP wouldn't boot after a reload of the switch last summer. We just replaced it and considered it a one off type of failure, but it seems to be the exact symptoms described here. The switch had been up and working for probably 2+ years before that. That was out of a group of 6 6500-E switches that we rebooted which were all procured around the same time (I think mid 2009). Only one line card in one switch failed out of the 6. -Vinny -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos Chatzithomaoglou Sent: Wednesday, March 05, 2014 7:33 AM To: cisco-nsp Subject: [c-nsp] Cisco mem issue Has anyone experienced the recently announced mem issue? http://www.cisco.com/web/about/doing_business/memory.html affected parts: http://www.cisco.com/web/about/doing_business/memory_pu.html Proposed fix-on-fail solution seems risky. -- Tassos ___ 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] OAM/CFM question on IOS-XR
Hi, I've been working on a basic configuration for E-OAM starting with one domain. I have CFM working between the PEs (IOS-XR) devices tied to an EoMPLS instance, but have a few questions below: 1) I think I should be seeing MIPs in my traceroute when there is a P router in between the two PEs, correct? 2) If the P router in between these PEs is just a transit node, what configuration is required to create the MIPs? I have seen the MIP autocreate all, but it seems to be tied to a service configuration under CFM which would not apply in the case of a transit/P router. Thanks! ___ 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] EIGRP potentially silly question...
After a deployment of EIGRP with the intent of providing link utilization based load-sharing as opposed to round robin, I get the rude awakening that the default k-values for EIGRP do NOT include link utilization. Any shortcuts / workarounds / etc to resetting k-values site-wide without breaking each individual peering as the values are changed? (EIGRP won't peer with mismatched k-values...) Jeff ___ 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] EIGRP potentially silly question...
Nope. And to top it off DUAL only runs on link state events - so if one link suddenly gets saturated the router won't recalculate the metric and split traffic up - unless something else in the network happens (cycle an interface, add a route, soft-reset EIGRP). On Wed, Mar 5, 2014 at 8:22 PM, Jeff Kell jeff-k...@utc.edu wrote: After a deployment of EIGRP with the intent of providing link utilization based load-sharing as opposed to round robin, I get the rude awakening that the default k-values for EIGRP do NOT include link utilization. Any shortcuts / workarounds / etc to resetting k-values site-wide without breaking each individual peering as the values are changed? (EIGRP won't peer with mismatched k-values...) Jeff ___ 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/ -- Alex Presse How much net work could a network work if a network could net work? ___ 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] EIGRP potentially silly question...
You could create a second EIGRP process with a value for K2 router eigrp 2 metric weights 0 1 1 1 0 0 Any identical routes in this second new instance of EIGRP will have a higher metric than the original EIGRP process. And thusly will NOT be installed in the routing table - provided they are *identical*. This would allow you to build out the entire second EIGRP process without it coming live uncontrolled. Then you could selectively remove networks from the original EIGRP (or manually increase them via offset lists). As they get removed from old EIGRP the new EIGRP routes would automatically take over. You're still left with the unfortunate part about the metric never actually changing unless DUAL is triggered. And in my little bit of labbing this past hour it appears that just because one side updated the metric; the other side will *not* under certain circumstances So you can have two routers having different loading values for the same link(s). Resulting in asymmetric flows. I bet somebody has made an EEM script to do clear ip eigrp neighbors soft on an interval or interface loading thresholds. This would at least get it to work as intended. All in all; fucking ugly. I just use default K values and a variance value of 2 with some simple offset lists or bandwidth statements. Much easier to support and troubleshoot at 03:15 during a vacation. On Wed, Mar 5, 2014 at 8:22 PM, Jeff Kell jeff-k...@utc.edu wrote: After a deployment of EIGRP with the intent of providing link utilization based load-sharing as opposed to round robin, I get the rude awakening that the default k-values for EIGRP do NOT include link utilization. Any shortcuts / workarounds / etc to resetting k-values site-wide without breaking each individual peering as the values are changed? (EIGRP won't peer with mismatched k-values...) Jeff ___ 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/ -- Alex Presse How much net work could a network work if a network could net work? ___ 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] EIGRP potentially silly question...
something like pfr[0] may be useful in this instance, assuming the kit can run it. on newer kit, pfr-v2 is much less sucky than the pfr of old. q. [0] http://docwiki.cisco.com/wiki/PfR:Solutions:BasicLoadBalancing#PfR_Features_that_Enable_Load_Balancing -= sent via ipad. please excuse brevity, spelling, and grammar =- On Mar 5, 2014, at 22:14, Alex Pressé alex.pre...@gmail.com wrote: You could create a second EIGRP process with a value for K2 router eigrp 2 metric weights 0 1 1 1 0 0 Any identical routes in this second new instance of EIGRP will have a higher metric than the original EIGRP process. And thusly will NOT be installed in the routing table - provided they are *identical*. This would allow you to build out the entire second EIGRP process without it coming live uncontrolled. Then you could selectively remove networks from the original EIGRP (or manually increase them via offset lists). As they get removed from old EIGRP the new EIGRP routes would automatically take over. You're still left with the unfortunate part about the metric never actually changing unless DUAL is triggered. And in my little bit of labbing this past hour it appears that just because one side updated the metric; the other side will *not* under certain circumstances So you can have two routers having different loading values for the same link(s). Resulting in asymmetric flows. I bet somebody has made an EEM script to do clear ip eigrp neighbors soft on an interval or interface loading thresholds. This would at least get it to work as intended. All in all; fucking ugly. I just use default K values and a variance value of 2 with some simple offset lists or bandwidth statements. Much easier to support and troubleshoot at 03:15 during a vacation. On Wed, Mar 5, 2014 at 8:22 PM, Jeff Kell jeff-k...@utc.edu wrote: After a deployment of EIGRP with the intent of providing link utilization based load-sharing as opposed to round robin, I get the rude awakening that the default k-values for EIGRP do NOT include link utilization. Any shortcuts / workarounds / etc to resetting k-values site-wide without breaking each individual peering as the values are changed? (EIGRP won't peer with mismatched k-values...) Jeff ___ 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/ -- Alex Presse How much net work could a network work if a network could net work? ___ 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/
