[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7BQJS1YY65EXEV1VRTEZRZP":3,"skill-same:01M7BQJS1YY65EXEV1VRTEZRZP":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M7BQJS1YY65EXEV1VRTEZRZP","azure-bgp",null,"Analyze and resolve BGP oscillation and BGP route leaks in Azure Virtual WAN–style hub-and-spoke topologies (and similar cloud-managed BGP environments). Detect preference cycles, identify valley-free violations, and propose allowed policy-level mitigations while rejecting prohibited fixes.","linyouxue\u002Fskill-repair-benchmark","linyouxue","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F216151464?v=4","01M7BJEVCXKD74KH6FG9CBVSQB","林宥学","01M7BJEVE02NP217V93BKZFC0J",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fevaluation\u002Fdata\u002Fskillsbench87\u002Freferences\u002Fazure-bgp-oscillation-route-leak\u002Fskills\u002Fazure-bgp\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: azure-bgp\ndescription: \"Analyze and resolve BGP oscillation and BGP route leaks in Azure Virtual WAN–style hub-and-spoke topologies (and similar cloud-managed BGP environments). Detect preference cycles, identify valley-free violations, and propose allowed policy-level mitigations while rejecting prohibited fixes.\"\n---\n\n# Azure BGP Oscillation & Route Leak Analysis\n\nAnalyze and resolve BGP oscillation and BGP route leaks in Azure Virtual WAN–style hub-and-spoke topologies (and similar cloud-managed BGP environments).\n\nThis skill trains an agent to:\n\n- Detect preference cycles that cause BGP oscillation\n- Identify valley-free violations that constitute route leaks\n- Propose allowed, policy-level mitigations (routing intent, export policy, communities, UDR, ingress filtering)\n- Reject prohibited fixes (disabling BGP, shutting down peering, removing connectivity)\n\nThe focus is cloud-correct reasoning, not on-prem router manipulation.\n\n## When to Use This Skill\n\nUse this skill when a task involves:\n\n- Azure Virtual WAN, hub-and-spoke BGP, ExpressRoute, or VPN gateways\n- Repeated route flapping or unstable path selection\n- Unexpected transit, leaked prefixes, or valley-free violations\n- Choosing between routing intent, UDRs, or BGP policy fixes\n- Evaluating whether a proposed \"fix\" is valid in Azure\n\n## Core Invariants (Must Never Be Violated)\n\nAn agent must internalize these constraints before reasoning:\n\n- ❌ BGP sessions between hubs **cannot** be administratively disabled by customers as it's owned by azure\n- ❌ Peering connections **cannot** be shut down as a fix as it break all other traffic running on the connections\n- ❌ Removing connectivity is **not** a valid solution as it break all other traffic running\n- ✅ Problems **must** be fixed using routing policy, not topology destruction\n\n**Any solution violating these rules is invalid.**\n\n## Expected Inputs\n\nTasks using this skill typically provide small JSON files:\n\n| File | Meaning |\n|------|---------|\n| `topology.json` | Directed BGP adjacency graph |\n| `relationships.json` | Economic relationship per edge (provider, customer, peer) |\n| `preferences.json` | Per-ASN preferred next hop (may cause oscillation) |\n| `route.json` | Prefix and origin ASN |\n| `route_leaks.json` | Evidence of invalid propagation |\n| `possible_solutions.json` | Candidate fixes to classify |\n\n## Reasoning Workflow (Executable Checklist)\n\n### Step 1 — Sanity-Check Inputs\n\n- Every ASN referenced must exist in `topology.json`\n- Relationship symmetry must hold:\n  - `provider(A→B)` ⇔ `customer(B→A)`\n  - `peer` must be symmetric\n- If this fails, the input is invalid.\n\n### Step 2 — Detect BGP Oscillation (Preference Cycle)\n\n**Definition**\n\nBGP oscillation exists if ASes form a preference cycle, often between peers.\n\n**Detection Rule**\n\n1. Build a directed graph: `ASN → preferred next-hop ASN`\n2. If the graph contains a cycle, oscillation is possible\n3. A 2-node cycle is sufficient to conclude oscillation.\n\n**Example pseudocode:**\n\n```python\npref = {asn: prefer_via_asn, ...}\n\ndef find_cycle(start):\n    path = []\n    seen = {}\n    cur = start\n    while cur in pref:\n        if cur in seen:\n            return path[seen[cur]:]  # cycle found\n        seen[cur] = len(path)\n        path.append(cur)\n        cur = pref[cur]\n    return None\n```\n\n### Step 3 — Detect BGP Route Leak (Valley-Free Violation)\n\n**Valley-Free Rule**\n\n| Learned from | May export to |\n|--------------|---------------|\n| Customer | Anyone |\n| Peer | Customers only |\n| Provider | Customers only |\n\n**Leak Conditions**\n\nA route leak exists if either is true:\n\n1. Route learned from a **provider** is exported to a **peer or provider**\n2. Route learned from a **peer** is exported to a **peer or provider**\n\n## Fix Selection Logic (Ranked)\n\n### Mandatory per-solution mechanism classification gate\n\nWhen the task provides a list of possible solutions, classify **every original solution string exactly once** before writing the output. Do not implement a finite allowlist of literal substrings and default every unmatched item to `false`; identify the operative routing mechanism from the whole description and apply the rules below.\n\nBuild a two-column decision record for each candidate:\n\n1. **Oscillation:** mark resolved only when the mechanism breaks a preference-cycle edge or makes forwarding deterministic despite the unstable BGP choice. Routing intent and an applicable deterministic UDR therefore count according to their `Applies to` sections below; timer tuning, dampening, waiting, restarting, ECMP, or ordinary path-selection tuning do not by themselves break the cycle.\n2. **Route leak:** mark resolved only when the mechanism prevents unauthorized origination, advertisement, acceptance, or use of the leaked route. This includes applicable export\u002Fno-export policy, ingress filtering, RPKI origin validation, routing intent, and deterministic UDR containment. A mechanism may resolve the leak without resolving oscillation.\n\n**Capability-category rule for origin validation:** When the task asks whether each proposed mechanism can resolve a problem category, classify origin validation by its stated mitigation capability in this Skill: it addresses the route-leak category but does not break a route-preference oscillation cycle. Do not override that capability label merely because the one observed announcement currently has an authorized origin; that observation diagnoses the current instance, whereas the requested solution classification asks what the proposed mechanism is capable of preventing. Keep any instance-level limitation in the explanation rather than silently changing the required category label.\n\n### Mandatory specificity and contradiction audit\n\nApply this precedence before writing the report and repeat it after any continuation or revision:\n\n| Mechanism described by the candidate | Oscillation | Route leak |\n|---|---:|---:|\n| Applicable routing intent or deterministic UDR | `true` | `true` |\n| Explicit preference change or explicit filtering that breaks an identified preference-cycle edge | `true` | `false`, unless a separate leak-control action is also stated |\n| Explicit valley-free export\u002Fno-export or applicable ingress control | `false`, unless it also breaks an identified cycle edge | `true` |\n| Origin validation | `false` | `true` |\n| Timer tuning, dampening, waiting, restart, ECMP, ordinary AS-path\u002FMED tuning, or maximum-prefix alone | `false` | `false` |\n| Prohibited operation | `false` | `false` |\n\nA technology label is not a concrete repair. A generic route map, route policy, or centralized-management proposal with no stated match condition, preference change, next-hop action, export restriction, or acceptance restriction must remain `false`\u002F`false`; do not invent missing behavior merely because that technology could implement a valid policy. Conversely, never add an exception that changes origin validation from the table's `false`\u002F`true` capability label. Treat either contradiction as a blocking pre-submission error and correct it before finishing.\n\nBefore submission, verify that the output key set is identical to the input solution set and audit every `false` decision against Tier 1–3 and the prohibited\u002Fcommon-pitfall sections. A candidate explicitly covered by an `Applies to` section must not remain `false` merely because its wording was absent from an ad-hoc keyword branch. Preserve the distinction that a UDR can neutralize the observed forwarding failure while masking, rather than removing, the underlying control-plane defect.\n\n### Tier 1 — Virtual WAN Routing Intent (Preferred)\n\n**Applies to:**\n- ✔ Oscillation\n- ✔ Route leaks\n\n**Why it works:**\n\n- **Routing intent operates above BGP** — BGP still learns routes, but does not decide forwarding\n- **Forwarding becomes deterministic and policy-driven** — Intent policy overrides BGP path selection\n- **Decouples forwarding correctness from BGP stability** — Even if BGP oscillates, forwarding is stable\n\n**For oscillation:**\n- Breaks preference cycles by enforcing a single forwarding hierarchy\n- Even if both hubs prefer each other's routes, intent policy ensures traffic follows one path\n\n**For route leaks:**\n- Prevents leaked peer routes from being used as transit\n- When intent mandates hub-to-hub traffic goes through Virtual WAN (ASN 65001), leaked routes cannot be used\n- Enforces valley-free routing by keeping provider routes in proper hierarchy\n\n**Agent reasoning:**\nIf routing intent is available, recommend it first.\n\n### Tier 2 — Export \u002F Route Policy (Protocol-Correct)\n\n**For oscillation:**\n\n- **Filter routes learned from a peer before re-advertising** — Removes one edge of the preference cycle\n- **Why this works**: In a cycle where Hub A prefers routes via Hub B and vice versa, filtering breaks one \"leg\":\n  - If Hub A filters routes learned from Hub B before re-announcing, Hub B stops receiving routes via Hub A\n  - Hub B can no longer prefer the path through Hub A because it no longer exists\n  - The cycle collapses, routing stabilizes\n\n**Example:**\nIf vhubvnet1 (ASN 65002) filters routes learned from vhubvnet2 (ASN 65003) before re-advertising, vhubvnet2 stops receiving routes via vhubvnet1, breaking the oscillation cycle.\n\n**For route leaks:**\n\n- **Enforce valley-free export rules** — Prevent announcing provider\u002Fpeer-learned routes to peers\u002Fproviders\n- **Use communities** (e.g., `no-export`) where applicable\n- **Ingress filtering** — Reject routes with invalid AS_PATH from peers\n- **RPKI origin validation** — Cryptographically rejects BGP announcements from ASes that are not authorized to originate a given prefix, preventing many accidental and sub-prefix leaks from propagating\n\n**Limitation:**\nDoes not control forwarding if multiple valid paths remain.\n\n### Tier 3 — User Defined Routes (UDR)\n\n**Applies to:**\n- ✔ Oscillation\n- ✔ Route leaks\n\n**Purpose:**\nAuthoritative, static routing mechanism in Azure that explicitly defines the next hop for network traffic based on destination IP prefixes, overriding Azure system routes and BGP-learned routes.\n\n**Routing Behavior:**\nEnforces deterministic forwarding independent of BGP decision processes. UDRs operate at the data plane layer and take precedence over dynamic BGP routes.\n\n**For oscillation:**\n- **Oscillation Neutralization** — Breaks the impact of BGP preference cycles by imposing a fixed forwarding path\n- Even if vhubvnet1 and vhubvnet2 continue to flip-flop their route preferences, the UDR ensures traffic always goes to the same deterministic next hop\n\n**For route leaks:**\n- **Route Leak Mitigation** — Overrides leaked BGP routes by changing the effective next hop\n- When a UDR specifies a next hop (e.g., prefer specific Virtual WAN hub), traffic cannot follow leaked peer routes even if BGP has learned them\n- **Leaked Prefix Neutralization** — UDR's explicit next hop supersedes the leaked route's next hop, preventing unauthorized transit\n\n**Use when:**\n- Routing intent is unavailable\n- Immediate containment is required\n\n**Trade-off:**\nUDR is a data-plane fix that \"masks\" the control-plane issue. BGP may continue to have problems, but forwarding is stabilized. Prefer policy fixes (routing intent, export controls) when available for cleaner architecture.\n\n## Prohibited Fixes (Must Be Rejected)\n\nThese solutions are **always invalid**:\n\n| Proposed Fix | Reason |\n|--------------|--------|\n| Disable BGP | Not customer-controllable |\n| Disable peering | prohibited operation and cannot solve the issue |\n| Shutdown gateways | Breaks SLA \u002F shared control plane |\n| Restart devices | Resets symptoms only |\n\n**Required explanation:**\n\nCloud providers separate policy control from connectivity existence to protect shared infrastructure and SLAs.\n\n**Why these are not allowed in Azure:**\n\nBGP sessions and peering connections in Azure (Virtual WAN, ExpressRoute, VPN Gateway) **cannot be administratively shut down or disabled** by customers. This is a fundamental architectural constraint:\n\n1. **Shared control plane**: BGP and peering are part of Azure's provider-managed, SLA-backed control plane that operates at cloud scale.\n2. **Availability guarantees**: Azure's connectivity SLAs depend on these sessions remaining active.\n3. **Security boundaries**: Customers control routing **policy** (what routes are advertised\u002Faccepted) but not the existence of BGP sessions themselves.\n4. **Operational scale**: Managing BGP session state for thousands of customers requires automation that manual shutdown would undermine.\n\n**Correct approach**: Fix BGP issues through **policy changes** (route filters, preferences, export controls, communities) rather than disabling connectivity.\n\n## Common Pitfalls\n\n- ❌ **Timer tuning or dampening fixes oscillation** — False. These reduce symptoms but don't break preference cycles.\n- ❌ **Accepting fewer prefixes prevents route leaks** — False. Ingress filtering alone doesn't stop export of other leaked routes.\n- ❌ **Removing peers is a valid mitigation** — False. This is prohibited in Azure.\n- ❌ **Restarting gateways fixes root cause** — False. Only resets transient state.\n\nAll are false.\n\n## Output Expectations\n\nA correct solution should:\n\n1. Identify oscillation and\u002For route leak correctly\n2. Explain why it occurs (preference cycle or valley-free violation)\n3. Recommend allowed policy-level fixes\n4. Explicitly reject prohibited fixes with reasoning\n\n## References\n\n- RFC 4271 — Border Gateway Protocol 4 (BGP-4)\n- Gao–Rexford model — Valley-free routing economics\n","# Azure BGP Oscillation & Route Leak Analysis\n\nAnalyze and resolve BGP oscillation and BGP route leaks in Azure Virtual WAN–style hub-and-spoke topologies (and similar cloud-managed BGP environments).\n\nThis skill trains an agent to:\n\n- Detect preference cycles that cause BGP oscillation\n- Identify valley-free violations that constitute route leaks\n- Propose allowed, policy-level mitigations (routing intent, export policy, communities, UDR, ingress filtering)\n- Reject prohibited fixes (disabling BGP, shutting down peering, removing connectivity)\n\nThe focus is cloud-correct reasoning, not on-prem router manipulation.\n\n## When to Use This Skill\n\nUse this skill when a task involves:\n\n- Azure Virtual WAN, hub-and-spoke BGP, ExpressRoute, or VPN gateways\n- Repeated route flapping or unstable path selection\n- Unexpected transit, leaked prefixes, or valley-free violations\n- Choosing between routing intent, UDRs, or BGP policy fixes\n- Evaluating whether a proposed \"fix\" is valid in Azure\n\n## Core Invariants (Must Never Be Violated)\n\nAn agent must internalize these constraints before reasoning:\n\n- ❌ BGP sessions between hubs **cannot** be administratively disabled by customers as it's owned by azure\n- ❌ Peering connections **cannot** be shut down as a fix as it break all other traffic running on the connections\n- ❌ Removing connectivity is **not** a valid solution as it break all other traffic running\n- ✅ Problems **must** be fixed using routing policy, not topology destruction\n\n**Any solution violating these rules is invalid.**\n\n## Expected Inputs\n\nTasks using this skill typically provide small JSON files:\n\n| File | Meaning |\n|------|---------|\n| `topology.json` | Directed BGP adjacency graph |\n| `relationships.json` | Economic relationship per edge (provider, customer, peer) |\n| `preferences.json` | Per-ASN preferred next hop (may cause oscillation) |\n| `route.json` | Prefix and origin ASN |\n| `route_leaks.json` | Evidence of invalid propagation |\n| `possible_solutions.json` | Candidate fixes to classify |\n\n## Reasoning Workflow (Executable Checklist)\n\n### Step 1 — Sanity-Check Inputs\n\n- Every ASN referenced must exist in `topology.json`\n- Relationship symmetry must hold:\n  - `provider(A→B)` ⇔ `customer(B→A)`\n  - `peer` must be symmetric\n- If this fails, the input is invalid.\n\n### Step 2 — Detect BGP Oscillation (Preference Cycle)\n\n**Definition**\n\nBGP oscillation exists if ASes form a preference cycle, often between peers.\n\n**Detection Rule**\n\n1. Build a directed graph: `ASN → preferred next-hop ASN`\n2. If the graph contains a cycle, oscillation is possible\n3. A 2-node cycle is sufficient to conclude oscillation.\n\n**Example pseudocode:**\n\n```python\npref = {asn: prefer_via_asn, ...}\n\ndef find_cycle(start):\n    path = []\n    seen = {}\n    cur = start\n    while cur in pref:\n        if cur in seen:\n            return path[seen[cur]:]  # cycle found\n        seen[cur] = len(path)\n        path.append(cur)\n        cur = pref[cur]\n    return None\n```\n\n### Step 3 — Detect BGP Route Leak (Valley-Free Violation)\n\n**Valley-Free Rule**\n\n| Learned from | May export to |\n|--------------|---------------|\n| Customer | Anyone |\n| Peer | Customers only |\n| Provider | Customers only |\n\n**Leak Conditions**\n\nA route leak exists if either is true:\n\n1. Route learned from a **provider** is exported to a **peer or provider**\n2. Route learned from a **peer** is exported to a **peer or provider**\n\n## Fix Selection Logic (Ranked)\n\n### Mandatory per-solution mechanism classification gate\n\nWhen the task provides a list of possible solutions, classify **every original solution string exactly once** before writing the output. Do not implement a finite allowlist of literal substrings and default every unmatched item to `false`; identify the operative routing mechanism from the whole description and apply the rules below.\n\nBuild a two-column decision record for each candidate:\n\n1. **Oscillation:** mark resolved only when the mechanism breaks a preference-cycle edge or makes forwarding deterministic despite the unstable BGP choice. Routing intent and an applicable deterministic UDR therefore count according to their `Applies to` sections below; timer tuning, dampening, waiting, restarting, ECMP, or ordinary path-selection tuning do not by themselves break the cycle.\n2. **Route leak:** mark resolved only when the mechanism prevents unauthorized origination, advertisement, acceptance, or use of the leaked route. This includes applicable export\u002Fno-export policy, ingress filtering, RPKI origin validation, routing intent, and deterministic UDR containment. A mechanism may resolve the leak without resolving oscillation.\n\n**Capability-category rule for origin validation:** When the task asks whether each proposed mechanism can resolve a problem category, classify origin validation by its stated mitigation capability in this Skill: it addresses the route-leak category but does not break a route-preference oscillation cycle. Do not override that capability label merely because the one observed announcement currently has an authorized origin; that observation diagnoses the current instance, whereas the requested solution classification asks what the proposed mechanism is capable of preventing. Keep any instance-level limitation in the explanation rather than silently changing the required category label.\n\n### Mandatory specificity and contradiction audit\n\nApply this precedence before writing the report and repeat it after any continuation or revision:\n\n| Mechanism described by the candidate | Oscillation | Route leak |\n|---|---:|---:|\n| Applicable routing intent or deterministic UDR | `true` | `true` |\n| Explicit preference change or explicit filtering that breaks an identified preference-cycle edge | `true` | `false`, unless a separate leak-control action is also stated |\n| Explicit valley-free export\u002Fno-export or applicable ingress control | `false`, unless it also breaks an identified cycle edge | `true` |\n| Origin validation | `false` | `true` |\n| Timer tuning, dampening, waiting, restart, ECMP, ordinary AS-path\u002FMED tuning, or maximum-prefix alone | `false` | `false` |\n| Prohibited operation | `false` | `false` |\n\nA technology label is not a concrete repair. A generic route map, route policy, or centralized-management proposal with no stated match condition, preference change, next-hop action, export restriction, or acceptance restriction must remain `false`\u002F`false`; do not invent missing behavior merely because that technology could implement a valid policy. Conversely, never add an exception that changes origin validation from the table's `false`\u002F`true` capability label. Treat either contradiction as a blocking pre-submission error and correct it before finishing.\n\nBefore submission, verify that the output key set is identical to the input solution set and audit every `false` decision against Tier 1–3 and the prohibited\u002Fcommon-pitfall sections. A candidate explicitly covered by an `Applies to` section must not remain `false` merely because its wording was absent from an ad-hoc keyword branch. Preserve the distinction that a UDR can neutralize the observed forwarding failure while masking, rather than removing, the underlying control-plane defect.\n\n### Tier 1 — Virtual WAN Routing Intent (Preferred)\n\n**Applies to:**\n- ✔ Oscillation\n- ✔ Route leaks\n\n**Why it works:**\n\n- **Routing intent operates above BGP** — BGP still learns routes, but does not decide forwarding\n- **Forwarding becomes deterministic and policy-driven** — Intent policy overrides BGP path selection\n- **Decouples forwarding correctness from BGP stability** — Even if BGP oscillates, forwarding is stable\n\n**For oscillation:**\n- Breaks preference cycles by enforcing a single forwarding hierarchy\n- Even if both hubs prefer each other's routes, intent policy ensures traffic follows one path\n\n**For route leaks:**\n- Prevents leaked peer routes from being used as transit\n- When intent mandates hub-to-hub traffic goes through Virtual WAN (ASN 65001), leaked routes cannot be used\n- Enforces valley-free routing by keeping provider routes in proper hierarchy\n\n**Agent reasoning:**\nIf routing intent is available, recommend it first.\n\n### Tier 2 — Export \u002F Route Policy (Protocol-Correct)\n\n**For oscillation:**\n\n- **Filter routes learned from a peer before re-advertising** — Removes one edge of the preference cycle\n- **Why this works**: In a cycle where Hub A prefers routes via Hub B and vice versa, filtering breaks one \"leg\":\n  - If Hub A filters routes learned from Hub B before re-announcing, Hub B stops receiving routes via Hub A\n  - Hub B can no longer prefer the path through Hub A because it no longer exists\n  - The cycle collapses, routing stabilizes\n\n**Example:**\nIf vhubvnet1 (ASN 65002) filters routes learned from vhubvnet2 (ASN 65003) before re-advertising, vhubvnet2 stops receiving routes via vhubvnet1, breaking the oscillation cycle.\n\n**For route leaks:**\n\n- **Enforce valley-free export rules** — Prevent announcing provider\u002Fpeer-learned routes to peers\u002Fproviders\n- **Use communities** (e.g., `no-export`) where applicable\n- **Ingress filtering** — Reject routes with invalid AS_PATH from peers\n- **RPKI origin validation** — Cryptographically rejects BGP announcements from ASes that are not authorized to originate a given prefix, preventing many accidental and sub-prefix leaks from propagating\n\n**Limitation:**\nDoes not control forwarding if multiple valid paths remain.\n\n### Tier 3 — User Defined Routes (UDR)\n\n**Applies to:**\n- ✔ Oscillation\n- ✔ Route leaks\n\n**Purpose:**\nAuthoritative, static routing mechanism in Azure that explicitly defines the next hop for network traffic based on destination IP prefixes, overriding Azure system routes and BGP-learned routes.\n\n**Routing Behavior:**\nEnforces deterministic forwarding independent of BGP decision processes. UDRs operate at the data plane layer and take precedence over dynamic BGP routes.\n\n**For oscillation:**\n- **Oscillation Neutralization** — Breaks the impact of BGP preference cycles by imposing a fixed forwarding path\n- Even if vhubvnet1 and vhubvnet2 continue to flip-flop their route preferences, the UDR ensures traffic always goes to the same deterministic next hop\n\n**For route leaks:**\n- **Route Leak Mitigation** — Overrides leaked BGP routes by changing the effective next hop\n- When a UDR specifies a next hop (e.g., prefer specific Virtual WAN hub), traffic cannot follow leaked peer routes even if BGP has learned them\n- **Leaked Prefix Neutralization** — UDR's explicit next hop supersedes the leaked route's next hop, preventing unauthorized transit\n\n**Use when:**\n- Routing intent is unavailable\n- Immediate containment is required\n\n**Trade-off:**\nUDR is a data-plane fix that \"masks\" the control-plane issue. BGP may continue to have problems, but forwarding is stabilized. Prefer policy fixes (routing intent, export controls) when available for cleaner architecture.\n\n## Prohibited Fixes (Must Be Rejected)\n\nThese solutions are **always invalid**:\n\n| Proposed Fix | Reason |\n|--------------|--------|\n| Disable BGP | Not customer-controllable |\n| Disable peering | prohibited operation and cannot solve the issue |\n| Shutdown gateways | Breaks SLA \u002F shared control plane |\n| Restart devices | Resets symptoms only |\n\n**Required explanation:**\n\nCloud providers separate policy control from connectivity existence to protect shared infrastructure and SLAs.\n\n**Why these are not allowed in Azure:**\n\nBGP sessions and peering connections in Azure (Virtual WAN, ExpressRoute, VPN Gateway) **cannot be administratively shut down or disabled** by customers. This is a fundamental architectural constraint:\n\n1. **Shared control plane**: BGP and peering are part of Azure's provider-managed, SLA-backed control plane that operates at cloud scale.\n2. **Availability guarantees**: Azure's connectivity SLAs depend on these sessions remaining active.\n3. **Security boundaries**: Customers control routing **policy** (what routes are advertised\u002Faccepted) but not the existence of BGP sessions themselves.\n4. **Operational scale**: Managing BGP session state for thousands of customers requires automation that manual shutdown would undermine.\n\n**Correct approach**: Fix BGP issues through **policy changes** (route filters, preferences, export controls, communities) rather than disabling connectivity.\n\n## Common Pitfalls\n\n- ❌ **Timer tuning or dampening fixes oscillation** — False. These reduce symptoms but don't break preference cycles.\n- ❌ **Accepting fewer prefixes prevents route leaks** — False. Ingress filtering alone doesn't stop export of other leaked routes.\n- ❌ **Removing peers is a valid mitigation** — False. This is prohibited in Azure.\n- ❌ **Restarting gateways fixes root cause** — False. Only resets transient state.\n\nAll are false.\n\n## Output Expectations\n\nA correct solution should:\n\n1. Identify oscillation and\u002For route leak correctly\n2. Explain why it occurs (preference cycle or valley-free violation)\n3. Recommend allowed policy-level fixes\n4. Explicitly reject prohibited fixes with reasoning\n\n## References\n\n- RFC 4271 — Border Gateway Protocol 4 (BGP-4)\n- Gao–Rexford model — Valley-free routing economics\n",{"name":5,"description":7},"main","cdcb6d230f3b15c3c33f8a2bdd16439f43602cbe","evaluation\u002Fdata\u002Fskillsbench87\u002Freferences\u002Fazure-bgp-oscillation-route-leak\u002Fskills\u002Fazure-bgp",1,"https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark","https:\u002F\u002Fgithub.com\u002Flinyouxue","2026-11-14 20:28:35",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add linyouxue\u002Fskill-repair-benchmark --skill azure-bgp",{"tool":37,"command":38},"bunx","bunx skills add linyouxue\u002Fskill-repair-benchmark --skill azure-bgp",{"tool":40,"command":41},"pnpm","pnpm dlx skills add linyouxue\u002Fskill-repair-benchmark --skill azure-bgp","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fevaluation\u002Fdata\u002Fskillsbench87\u002Freferences\u002Fazure-bgp-oscillation-route-leak\u002Fskills\u002Fazure-bgp\u002FSKILL.md",true,[],[46,53,60,67,72,77],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M7E1HGVRY73NBJ022CJG13X6","video-frame-extraction","Extract frames from video files and save them as images using OpenCV","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fvideo-frame-extraction\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7E1HAG5R7CJ9C8NYJS771MB","openai-vision","Analyze images and multi-frame sequences using OpenAI GPT vision models","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fopenai-vision\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7E1H7DADKB6QBWKC2KQ63SZ","image-ocr","Extract text content from images using Tesseract OCR via Python, including structured field extraction from receipts and forms","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fimage-ocr\u002FSKILL.md",[],[],{"skillNo":68,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M7E1H0WBNT43TENGQY7AVZHD","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fvideo-frame-extraction\u002FSKILL.md",[],[],{"skillNo":73,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7E1GTC7D4N4Q2EF03875J9E","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fopenai-vision\u002FSKILL.md",[],[],{"skillNo":78,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7E1GQ92CWFMGH53KSSE4WER","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fimage-ocr\u002FSKILL.md",[],[]]