No, routing protocol use real IP to communicate. Virtual IP is only used for HSRP and LAN users.
For the routing protocol, it does not require to know the virtual IP because the routing table includes the subnet and not the specific /32 host IP (unless you specific the /32 routes but when you use HSRP, you cannot use /32, due to two LAN ports share the same subnet). When the packet match the table and forward to the particular subnet and interface. Therefore, it does not require the virtual IP.
But, fot the rest of your answer, I am not sure if I understood the following: "When the packet match the table and forward to the particular subnet and interface. Therefore, it does not require the virtual IP."
As far as I know, the router will forward packets to the physical address of one of the routers in a hsrp node (because, this a address it sees in its routing table as a next hop address) and not just to its own interface (what if proxy arp is disabled on the other side?).
So, if I et this right, there is no way to meke this configuration work and lose the static routes?!
Routing protocols can run only on primary address (at least on Cisco routers), however they can advertise other addresses. RIP and EIGRP internal routes will always use neighbor as next-hop of advertised prefix, OSPF is slightly more complex but at the end next-hop will be either ASBR (and then recoursively looked up) or one of directly attached neighbors. The only protocol that can modify next-hop of advertised prefix is BGP and then only to...IP from which iBGP session originated (by applying next-hop self).
Since there is no way to source routing protocol packets from anything but primary address of an interface, and HSRP virtual address is not primary address, then it's clear why HSRP cannot be advertised as next-hop directly.
One possible trick is to have some dummy route pointing to HSRP address, then it can be redistributed either into OSPF NSSA area (if OSPF is running and not passive on HSRP facing interface) or into BGP (if it's eBGP with neighbor on the same subnet as HSRP or it's iBGP without setting 'next-hop-self'). But hard to see what's use of HSRP address beyond local subnet.
using a route-map you can set the BGP next-hop in an update to any valid host IP you want, including a HSRP virtual address. The route will only installed into the routing table though, if the next hop is reachable through IGP. So you would need f.e. OSPF in addition to announce the "HSRP LAN" network. As already pointed out, there seems to be little practical use for this though.
The underlying reason is, that each router will route based on its own routing table. Without beeing directly connected to the HSRP LAN, i.e. able to take advantage of the HSRP redundancy, there seems little sense in setting a next hop to a specific IP in a remote network.
If the router is directly connected to the HSRP LAN: what would be the point in using the dynamic routing protocol (like BGP)!?
By the way, you say "to meke this configuration work and lose the static routes". If you have routing protocol already running on those routers, then they don't need static routes. Additionally, if there are no host-like systems (including management IP interface of switches) on that subnet, then there is no need for HSRP on that segment either.
Even if you get a route pointing to HSRP redistributed via a routing protocol, then only systems that could get use of it are actually those, which're running given routing protocol. And since they're already running routing protocol, they can learn about all necessary destinations without dark business with advertising HSRP as next-hop.
If your intent is to reduce service unavailability time, then HSRP isn't that fast as you may think and routing protocols can be just as fast or even faster in some cases.
This is something I sure would never thought of using in a real world situation, but rather something I came up to as an interesting problem during my CCIE exam preparation, so I was wondering if there is some clever way to solve it.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...