url map hostname and path rule query

[mountaincode2]

Based off the following url map in this doc:
https://cloud.google.com/load-balancing/docs/url-map-concepts#example-url-map-workflow

creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
- '*'
pathMatcher: video-matcher
- hosts:
- example.net
pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
name: video-matcher
pathRules:
- paths:
- /video/hd
- /video/hd/*
service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
- paths:
- /video/sd
- /video/sd/*
service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

Say the domain name is "videos.com",  the following are my host and path rules for "videos.com":

I have a few queries:

1. What is the difference between "All unmatched (default)" and "*".

2. What happens if the hostname is unknown.com/video/hd.

Is the backend service selected as `org-site` or `video-hd`?

3. What happens if the hostname is unknown.com/hello.

Is the backend service selected as `org-site` or `video-site`?

4. In this case, would the default service of the path matcher `video-matcher` always take precedence over the default service of the url map `org-site`.

[mountaincode2]

Can someone please help me with this.

[FrancoGP]

Hi @mountaincode2 ,

Welcome to Google Cloud Community!

I think you got it sorted out already! Let's look into it

1.Technically there is no difference, when simple ruling is used we get by default this rules as a contingency that traffic should always get to at least a target. You can use it on other slots but it's more handy to mark with "*" as it's visually more referencial that is a custom rule. On it's own they do the same, but * would take priority over default layer.

2.If unknown.com is correctly configured into the lb and not defined directly as a host it should drop on bs-video-hd as "*" will supersede over the default and there is an existing Path Matcher

3.Similar to the one above will have * as Host Matcher but here there is no Path Matcher so will go through the next possible thing, in this case All unmatched (default). So bs-video-site

4.Pretty much yes! So the logic would go * > Default and host prior to path matching.

Hope that helps out!

[mountaincode2]

thank you, @FrancoGP .

a quick followup:

what do you mean by:

So the logic would go * > Default and host prior to path matching.

[FrancoGP]

Yeah sorry I left it out a bit confusing.

Basically that All unmatched (default) has to be considered as it is, a default, a layer only used if really REALLY no other option is available, while * is wildcard and actual operator, so it's an option and will always be considered higher than default.

And that the previous statement goes for both host and path. Default in path will only be considered if there is NOTHING else to compare to, if we have the actual correct path or *, it will always win.

Hope that made it a bit more clear 😅

[mountaincode2]

Thank you, @FrancoGP.

I am still confused about "all unmatched (default)" and * though.

The way i am thinking about it they both seem the same to me: * is a wildcard and represents all unmatched hostnames.

Where am i going wrong in my thinking about this. May i request you to provide examples of when the requests would be routed to 'bs-org-site'.

Thank you!

[FrancoGP · Accepted solution]

Yeah, sure!

In your example bs-org-site would never be reachable because it has already all other rules that contemplate any other scenario. * is a wildcard, is a decision that you allow any value for that variable. All unmatched (default) is technically a wildcard as well, but it's not (or shouldn't) be a decision, should be a void where things are thrown whenever nothing else can be done.

The logic goes that the lb will check first

• what is your host?
• Is your host explicitly in the list?
  • Yes: Cool, let's look at the path
  • No: Ok, is there any * defined?
    • Yes: Ok, let's use that, it means the administrator contemplated this
    • No: Ok, let's use the default, as it seems this is not a contemplated case and I will have to fall back to the "standard"

And the same process goes after for path.

Going back to the example, and taking in consideration the "flow chart", there is no path in which bs-org-site could be used, the most near thing would be on line 4. If you limit the scope of the path on bs-video-site (the one in the middle) there is a window in which there won't be a match between host and path (right now basically both are wildcards so it's impossible to not find a match) and drop to bs-org-site
This rule, the 4th rule you have in the example is contemplating all scenarios, so it won't let anything fall under the default, hence never reaching bs-org-site

* Should be used when you want to catch all because you thought it through, All Unmatched (default) has to just be there for whenever something escaped your sight. Technically they are the same, but for style/administration they are different, one is a swiss knife while the other is more like a last resort safety net