WCCP Router ID Change on Firepower 2110

[robo764]

On one of our sites, we have a Firepower 2110 configured for WCCP.  Previously, it's WCCP Router ID was an unused ethernet port that was configured with an IP address, but not physically connected to anything.  It was this way, when I inherited, so I'm not sure of the history. I had been under the impression that a Router ID had to be "up" but that's not really the issue.  We enabled interface monitoring on our FMC and it started throwing critical alerts constantly due to the "wccp router id" interface being enabled/configured, but down/down. We disabled the interface, to try and quell the alerts, which brought an end to that IP address being the Router ID for WCCP.  I have two questions I haven't been able to answer:

1. How was WCCP functioning with a Router ID that was configured to an interface that was down/down?  Does the IP address not have to be reachable? Is it possible it was reachable, in the past, but it didn't need to stay that way (i.e. it only needed to be "up" long enough for the system to set it to its WCCP Router ID)? 
2. Enabling the interface again (though it's still down/down) did not result in the Router ID changing back.  Is there a way to have WCCP use that IP address?  I'm not sure of the process for selection.  I know it uses the highest IP address, but I don't know if it requires the current interface to be disabled to select again?  It either requires a trigger for a new selection, or it does, in fact, require that the interface in question be "up/up" before it can regain its status as WCCP Router ID. 

[ccieexpert]

my guess is that the interface was up at some point in time for it to be chosen for router id... It is funny what it worked while in a down state... because it has to be sourced from that interface... i will try to do some testing and report back..

[robo764]

As a ridiculous/maddening coincidence, the tunnel interface (that was just recently selected as the new WCCP Router I went down last night.  As a result, the WCCP Router ID reverted back to the down/down ethernet interface.  So the firepower is now using an interface that was *definitely* down/down, when it was selected, as the Router ID. 

[MHM Cisco World]

Route ID is different that packet source IP

FW use router ID it up.or down 

But FW always use UP IP as packet source 

MHM

[ccieexpert]

https://www.cisco.com/c/en/us/td/docs/security/asa/special/wccp/asa-wccp.html

• The ASA selects the highest IP address configured on any interface as the WCCP router ID. This address is used to establish a GRE tunnel with the device. When the ASA redirects packets to the WCCP-enabled device, the ASA sources the redirect from the router ID IP address (even if it is sourced out a different interface) and encapsulates the packet in a GRE header. For WCCP to work, the interface whose IP address is chosen as the router ID must be in the UP state and there must be a route to the device.

[MHM Cisco World]

Sorry but I dont get full your answer 

Anyway I think it issue of routing not issue of router-id.

Router-id used inside packet but source use in header and it mandatory to forward packet 

MHM

[robo764]

"For WCCP to work, the interface whose IP address is chosen as the router ID must be in the UP state and there must be a route to the device."

Yeah, this is what was throwing me off. I couldn't find a firepower-specific document that talked about WCCP like the ASA doc, so I had thought the behavior was the same.  Evidence would lead me to believe that's not true, however.  There is, in fact, routing to the device/Router ID, but only due to it being an interface on the same device (firepower) and subnet. It's obviously not "reachable" due to it being down/down. 

[tvotna]

It's highly likely that interface need not be in the "up"state to use its IP address as the source of GRE frames, although official documentation and CSCvp67215 tells us otherwise. The fact that RID is unconfigurable has always been a pain. Also, beware of CSCwh68068 on FTD.

[MHM Cisco World]

https://integratingit.wordpress.com/2022/02/25/wsa-transparent-proxy-using-wccp/

check this 
MHM