Is the 1100PSU even available as primary for the 9300-48P model ? according to CCW , it is not.  Strange, because as secundary , you can choose the 1100W model, but not as primary (??) Also, the specs list that the POE budget of 9300-48P model is only 437W as "available poe budget" when using the 715PSU. does it mean you can only connect 29x 15W phones ? or 14x 30W APs ?   if we install the 1100W anyway as primary, will it boot (supported) ? will it increase the "available poe budget" to abvove 437W ?   Does installing a secundary power supply increase the PoE budget from 437 to 874W, allowing 28x 30W APs (but non-redundant then) ?   this is not at all clear and asks for some clarification from cisco.   ... View more

ok, so i have managed to get this working, thanks to some old Joe Clarke scripts :-) The script itself detects if the router has a primary or standby function and adjusts HSRP accordingly. the name of the route-maps are PRIMARY-MAP-OUT and BACKUP-MAP-OUT   event manager applet default-change event routing network 0.0.0.0/0 type modify action 0.1 set role "NONE" action 0.2 cli command "show ip bgp neighbor 172.31.255.246 | i map for outgoing" action 0.3 regexp ".*\s(.*)-MAP-OUT.*" "$_cli_result" match role action 0.4 if $role eq "PRIMARY" action 0.5 set hpriority "160" action 0.6 else action 0.7 set hpriority "150" action 0.8 end action 1.0 syslog msg "Default route changed to $_routing_lastgateway" action 1.1 syslog msg "Detected role: $role" action 2.0 if $_routing_lastgateway eq "172.31.255.2" action 3.0 cli command "enable" action 3.1 cli command "conf t" action 3.2 cli command "interface Fa0/0" action 3.3 cli command "standby 80 prio 50" action 3.4 syslog msg "Adjusted HSRP priority (Fa0/0) to 50" action 4.0 elseif $_routing_lastgateway eq 172.31.255.246 action 5.0 cli command "enable" action 5.1 cli command "conf t" action 5.2 cli command "interface Fa0/0" action 5.3 cli command "standby 80 prio $hpriority" action 5.4 syslog msg "Adjusted HSRP priority (Fa0/0) to $hpriority" action 6.0 end ... View more

yes, in fact i am using already iBGP session between the routers + tracking of physical interface state to lower HSRP priority on the inside. This works great (standard design) both for physical line failure and logical line failure (ie bgp down, or 0.0.0.0/0 removed). However, in case of logical failure (bgp down, interface up), it leads to assymetric routing (outbound to router A, from router A to router B, exit internet B, inbound traffic B, to router B, -but- since router B has local interface into fw vlan, it will route directly and not back across the iBGP link to router A). It is not a critical situation, it should work, however, using EEM scripting i wanted to catch this situation and increase routers B HSRP priority to remove the assymetry in this case. I agree, a lot of work for a situation that will not happen all that often :-) ... View more

Use case is simple: I have two routers: one is primary , one is secondary. But operational team can decide to switch primary to secondary and vica versa at any time. There is an EEM script running on the router, but its behavior depends on the router being primary or secondary. So when the function changes (ie route-maps get swapped) the script needs to behave differently. I know, when they switch the functions (route-maps) they can also adjust the script, but that is often forgotten, so why not let the script detect itself if it is running on the primary or secondary router ? ... View more

ha Georg, that might also be good alternative.   I have found that the following EEM script also runs fine in lab tests:   event manager applet check-default event routing network 0.0.0.0/0 type modify action 1.0 syslog msg "Default route changed to $_routing_lastgateway" action 2.0 if $_routing_lastgateway eq "2.2.2.2" action 3.0 cli command "enable" action 3.1 cli command "conf t" action 3.2 cli command "interface Fa0/0" action 3.3 cli command "standby 80 prio 50" action 4.0 elseif $_routing_lastgateway eq "1.1.1.1" action 5.0 cli command "enable" action 5.1 cli command "conf t" action 5.2 cli command "interface Fa0/0" action 5.3 cli command "standby 80 prio 150" action 6.0 end   1.1.1.1 is the next hop of the local ISP router (ebgp) 2.2.2.2 is the next hop of the iBGP session to the backup router/link (ibgp)   Principle is easy: if the default points to the locally connected ISP, match the downstream HSRP as primary (attract traffic) if the default is routed to the backup link (ibgp, remote ISP, non-local-link), lower the downstream HSRP priority. ... View more

Both next hops are always reachable. That doesn't show me to where the default route points that eventually makes it to the routing table. So both ip sla or ping tracking of the next hop isn't relevant. I am now looking at an EEM script example of Joe Clarke that looks promising. Here it seems you can explicitly check for the $_routing_lastgateway of a route. I am going to lab this up.   event manager applet link-check event routing network 0.0.0.0/0 type modify action 1.0 syslog msg "Route changed to $_routing_lastgateway" action 2.0 snmp-trap strdata "Route changed to $_routing_lastgateway"   ... View more

Both next hops can indeed be reachable (while not receiving any route). The default route received on the BGP sessions comes from multiple hops away. I need to determine from where it comes. Now, i was thinking about the route metric (there is something like route metric tracking). The BGP AS path is different for both routes. But the standard BGP "metric" is the same. A default is selected by BGP using Local Preference. But for the downstream HSRP priorities, i need to be able to determine from where the default comes (i have two upstream interfaces). ... View more

The track object will be used to change HSRP priorities of downstream interfaces. ... View more

We have the same problem, we are running fuji latest release 16.8.1a. We have even configured "source interface vrf" for dns, and even with this it doesn't work.   I think because it is for the following reasons: * we have 3 VRF: global, IT & mgmt * only IT & mgmt have ip interfaces. the global does not have any ip interfaces.   ip name-server vrf IT 1.1.1.1 2.2.2.2 ip name-server vrf Mgmt-vrf 1.1.1.1 2.2.2.2 ip domain list vrf IT DOMAIN1.COM ip domain list vrf Mgmt-vrf DOMAIN1.COM no ip domain lookup (=assuming this disabled dns lookup in the global vrf only) ip domain lookup vrf IT source-interface Loopback0 (Lo0 = part of vrf IT) ip domain lookup vrf Mgmt-vrf source-interface GigabitEthernet0/0 (Gi0/0= part of vrf Mgmt-vrf) ip domain name vrf IT DOMAIN1.COM ip domain name vrf Mgmt-vrf DOMAIN1.COM   because the global does not have any ip interfaces, we have not defined anything for dns in the "default" vrf.   however, it seems the "no ip domain-lookup" disables DNS in all VRFs:   ping SERVER1 % Unrecognized host or address, or protocol not running.   ping vrf IT SERVER1 % Unrecognized host or address, or protocol not running.   ping vrf Mgmt-vrf SERVER1 % Unrecognized host or address, or protocol not running.   i think this is wrong.   Anyway, after enabling "ip domain lookup", dns does not work in the default vrf (as expected) it does not work in the Mgmt-vrf and in the IT vrf it sometimes works and sometimes not (then you get: protocol not running ??)     I don't know why this is, both VRF are configured alike. Both have a default route towards the destination. I am connected to the router via the Gi0/0 interface (so via Mgmt-vrf). Don't know if this makes a difference. Also "show ip dns servers" gives inconsistent output:   #sh ip dns servers IP VRF TTL(s) RTT(ms) RTO(ms) EDNS DNSSEC RECURSION ----------------------------------------------------------------------------- 1.1.1.1 Mgmt-vr 683 1000 64000 Yes Yes Yes 2.2.2.2 IT 869 1451 1451 No Yes Yes 2.2.2.2 Mgmt-vr 685 1000 119000 Yes Yes Yes   note how EDNS is different in the IT and Mgmt-vrf , although it are the same dns servers ... View more