Correct routing method from Anycast to Unicast#128215
Correct routing method from Anycast to Unicast#128215ravisha22 wants to merge 1 commit intoMicrosoftDocs:mainfrom
Conversation
Updated routing method descriptions from Anycast to Unicast for accuracy.
prmerger-automator
bot
requested review from
AbdullahBell,
cherylmc,
halkazwini and
johndowns
|
@ravisha22 : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit b4aa541: ✅ Validation status: passed
For more details, please refer to the build report. |
There was a problem hiding this comment.
Pull request overview
Updates Azure Front Door scenario documentation to describe “Unicast” routing instead of “Anycast” routing.
Changes:
- Renamed “Anycast routing” to “Unicast routing” in the resiliency scenario bullet list.
- Renamed “Anycast” to “Unicast” in the “Client to Front Door” section description.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| - **Load balancing and failover:** Front Door is a global load balancer. Front Door monitors the health of your origin servers, and if an origin becomes unavailable, [Front Door can route requests to an alternative origin](routing-methods.md). You can also use Front Door to spread traffic across your origins to reduce the load on any one origin server. | ||
| - **Anycast routing:** Front Door itself has a [large number of PoPs](edge-locations-by-region.md), each of which can serve traffic for any request. [Anycast routing](front-door-traffic-acceleration.md#select-the-front-door-edge-location-for-the-request-anycast) steers traffic to the closest available Front Door PoP, and if a PoP is unavailable, clients are automatically routed to the next closest PoP. | ||
| - **Unicast routing:** Front Door itself has a [large number of PoPs](edge-locations-by-region.md), each of which can serve traffic for any request. [Unicast routing](front-door-traffic-acceleration.md#select-the-front-door-edge-location-for-the-request-anycast) steers traffic to the closest available Front Door PoP, and if a PoP is unavailable, clients are automatically routed to the next closest PoP. |
There was a problem hiding this comment.
The link label and surrounding text were changed to 'Unicast', but the URL anchor still references '...request-anycast'. This is internally inconsistent and can also mislead readers. Update the link target to a 'unicast' section if it exists, or keep the terminology aligned with the referenced 'anycast' section.
| ### Client to Front Door | ||
|
|
||
| Traffic from the client first arrives at a Front Door PoP. Front Door has a [large number of PoPs](edge-locations-by-region.md) distributed worldwide, and [Anycast](front-door-traffic-acceleration.md#select-the-front-door-edge-location-for-the-request-anycast) routes the clients to their closest PoP. | ||
| Traffic from the client first arrives at a Front Door PoP. Front Door has a [large number of PoPs](edge-locations-by-region.md) distributed worldwide, and [Unicast](front-door-traffic-acceleration.md#select-the-front-door-edge-location-for-the-request-anycast) routes the clients to their closest PoP. |
There was a problem hiding this comment.
This sentence describes Anycast behavior (routing clients to the closest PoP), but it’s now labeled 'Unicast' while still linking to an 'anycast' anchor. Either revert this wording to 'Anycast' (to match the described behavior and linked section) or rewrite the behavior description and link to match a true unicast explanation.
|
|
||
| - **Load balancing and failover:** Front Door is a global load balancer. Front Door monitors the health of your origin servers, and if an origin becomes unavailable, [Front Door can route requests to an alternative origin](routing-methods.md). You can also use Front Door to spread traffic across your origins to reduce the load on any one origin server. | ||
| - **Anycast routing:** Front Door itself has a [large number of PoPs](edge-locations-by-region.md), each of which can serve traffic for any request. [Anycast routing](front-door-traffic-acceleration.md#select-the-front-door-edge-location-for-the-request-anycast) steers traffic to the closest available Front Door PoP, and if a PoP is unavailable, clients are automatically routed to the next closest PoP. | ||
| - **Unicast routing:** Front Door itself has a [large number of PoPs](edge-locations-by-region.md), each of which can serve traffic for any request. [Unicast routing](front-door-traffic-acceleration.md#select-the-front-door-edge-location-for-the-request-anycast) steers traffic to the closest available Front Door PoP, and if a PoP is unavailable, clients are automatically routed to the next closest PoP. |
There was a problem hiding this comment.
The indentation of this bullet appears to have changed compared to the surrounding list items (it no longer visually aligns as a nested bullet). This can break the intended Markdown list nesting/formatting in rendered docs. Adjust indentation to match the surrounding list structure so it renders consistently.
|
@ravisha22 - This pull request was opened in the public repo. PMs should work in the private repo, per the Microsoft Docs contributor guide. We can keep this PR open for review and merge, but would you make future content updates in the private repo? Thank you! Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
bot
added
the
aq-pr-triaged
3 participants
Updated routing method descriptions from Anycast to Unicast for accuracy.