Inquiry regarding the correct ASN to use for BGP AS Path Prepending in Azure Virtual WAN Route Maps

이재옥 145 평판 포인트
2026-04-23T01:15:29.0033333+00:00

Dear all,

I am currently configuring AS Path Prepending using the Route Map feature in Azure Virtual WAN to control traffic priority toward my on-premises network.

According to the official documentation (and the "Reserved ASNs" list in the portal), several ASNs including 12076, 8074, 8075, 65515, 65517, 65518, 65519, and 65520 are strictly reserved and cannot be used for prepending in Route Maps.

Since I am unable to use the standard Azure ASN (12076) or the vHub internal ASN (65515) for prepending, I would like to clarify the following:

Which ASN is recommended for AS Path Prepending? Is it permissible to use any arbitrary private ASN (e.g., in the range 64512–65534) that is not in the reserved list, or is there a specific ASN recommended by Microsoft for this purpose?

Risk of MSEE Blocking: If I use a private ASN or a different public ASN for prepending in an outbound Route Map, will the Microsoft Enterprise Edge (MSEE) or the Virtual Hub router strip these ASNs or block the route due to loop prevention mechanisms?

Best Practice: If Azure Route Maps restrict the use of Azure's own ASNs for prepending, what is the official "best practice" for achieving outbound AS Path Prepending from a Virtual Hub?

Scenario Detail:

Target Prefix: 192.168.0.0/24

Action: Outbound AS Path Prepend (to make this route less preferred on-premises)

Environment: Virtual WAN Hub with ExpressRoute Gateway

I look forward to your official guidance on this matter.

Best regards,

Azure Virtual WAN
Azure Virtual WAN

최적화되고 자동화된 분기 간 연결을 제공하는 Azure 가상 네트워킹 서비스입니다.

댓글 0개 설명 없음

질문 작성자가 수락한 답변
Ravi Varma Mudduluru 12,625 평판 포인트 Microsoft 외부 직원 중재자
2026-04-23T02:01:42.18+00:00

영문 답변을 번역한 내용이므로, 문법적으로 다소 어색한 부분이 있더라도 양해 부탁드립니다.

안녕하세요. @이재옥

Microsoft Q&A에 문의해 주셔서 감사합니다.

Virtual WAN vHub에서 AS-path를 prepend(경로 앞에 추가)하여 온프레미스 환경에서 해당 경로를 "더 긴 경로"(우선순위가 낮은 경로)로 인식하게 만들고자 할 때, 어떤 ASN을 사용해야 할지 파악하려는 상황으로 이해됩니다. 관련 문서의 내용과 저희가 권장하는 접근 방식은 다음과 같습니다.

Azure의 예약된 ASN 사용을 피하십시오.

• 공용(Public): 8074, 8075, 12076

• 사설(Private): 65515, 65517, 65518, 65519, 65520

ExpressRoute에서의 사설 ASN 제거(Stripping)

ExpressRoute 연결을 통해 이러한 prepend 작업을 수행하는 경우, ExpressRoute 게이트웨이가 사설 ASN(64512–65535 범위)을 제거(strip)한다는 점에 유의해야 합니다. 다시 말해, 해당 범위 내에서 예약되지 않은 사설 ASN을 선택하더라도, 실제로는 온프레미스 피어(peer) 장비까지 해당 ASN 정보가 전달되지 않습니다.

권장 모범 사례: 자체 공용 ASN 사용

• 자체 공용 ASN(이미 온프레미스 장비에서 사용 중인 ASN)을 보유하고 있다면, 해당 ASN을 prepend하십시오. 공용 ASN은 제거되지 않습니다. AS-path 내에서 귀하의 ASN이 반복되어 나타나게 되므로(예: 65000 65000 65000 …), 온프레미스 BGP 라우터는 이를 더 긴 경로로 인식하게 됩니다.

• Microsoft Enterprise Edge(MSEE) 및 Virtual Hub 라우터는 귀하의 공용 ASN을 제거하거나 차단하지 않습니다. 루프 방지(loop-prevention) 기능이 작동하더라도, Azure 소속이 아닌 ASN의 반복은 무시(허용)합니다.

공용 ASN을 보유하고 있지 않은 경우

• ExpressRoute가 아닌 다른 연결 방식(예: VPN)을 사용하는 경우, 앞서 언급한 예약된 목록에 포함되지 않는다면 64512–65534 범위 내의 사설 ASN을 선택하여 사용할 수 있습니다. 하지만 다시 한번 강조하자면, ExpressRoute 연결에서는 게이트웨이 단계에서 해당 사설 ASN이 제거되므로, 이 방법은 효과가 없습니다. • 또는, “경로 Prepend를 위한 Route-map 구성 방법” 문서에 안내된 대로 예시 ASN 중 하나(예: 65533)를 사용하여, Inbound Spoke-to-Hub 연결 구간에 Prepend를 적용하는 방안을 고려해 보십시오. 이 방법은 Hub가 트래픽을 전송할 Spoke를 선택하는 방식에 영향을 미치기는 하지만, On-premise 측의 경로 선호도(Path Preference)를 제어하는 ​​데에는 도움이 되지 않습니다.

루프 방지(Loop Prevention) 관련 유의 사항

• MSEE는 단지 알 수 없는 ASN을 Prepend했다는 이유만으로 해당 경로를 Black-hole 처리하지는 않습니다. 루프 방지 기능은 경로상에서 자신의 ASN을 발견했을 때에만 해당 경로를 폐기(Drop)합니다. 귀하께서는 12076(또는 그 외 Azure 관련 ASN)을 Prepend하고 계신 것이 아니므로, 이와 관련된 문제는 발생하지 않습니다.

참조 문서

• Route-map을 구성하여 경로를 선행 추가하는 방법 (시나리오 및 워크플로): https://learn-microsoft-com.translate.goog/en-us/azure/virtual-wan/route-maps-prepend-routes?_x_tr_sl=en&_x_tr_tl=ko&_x_tr_hl=en&_x_tr_pto=wapp

Route-map 모범 사례 및 ASN 제한 사항: https://learn-microsoft-com.translate.goog/en-us/azure/virtual-wan/route-maps-about?_x_tr_sl=en&_x_tr_tl=ko&_x_tr_hl=en&_x_tr_pto=wapp#route-map-limitations

제공된 정보가 도움이 되었다면 "답변 채택"과 "추천"을 눌러주세요. 다른 커뮤니티 회원들에게도 도움이 될 수 있습니다.

이 대답이 도움이 되었나요?

1명이 이 답변이 도움이 된다고 생각했습니다.

0 추가 답변

정렬 기준: 가장 유용함

답변

질문 작성자는 답변을 '승인됨'으로 표시하고, 중재자는 답변을 '추천됨'으로 표시할 수 있습니다. 이를 통해 사용자는 해당 답변이 작성자의 문제를 해결했다는 것을 알 수 있습니다.