junos: add route-level community lab for static, aggregate, and generate routes - #235
Merged
Merged
Conversation
…ate routes
Two-node vJunos-router lab testing which community forms Junos accepts
in `routing-options {static|aggregate|generate}` at route and
`defaults` level, and what the eBGP peer receives. Juniper's
`community (Routing Options)` reference describes large communities as
static-only; on 25.4R1.12 they are accepted in all six contexts and
reach the peer. Extended communities (`target:`, `origin:`) are
rejected by the CLI parser in all six. A `DEFAULTS` virtual-router
exercises the `defaults` blocks over a second eBGP session.
Batfish drops aggregate/generate routes carrying a route-level large
community and ignores large communities in their `defaults` blocks;
test_main_rib_routes and test_bgp_rib_routes are sickbayed against
batfish/batfish#10367.
lab_builder: `_junos_commit_check` now treats an `error:` response to a
`set` line as a rejection. Previously the rejected line was never
loaded, so `commit check` passed and the check reported "accepted".
Junos BGP parser: strip the `Aggregator:` line that aggregate routes
append to the `as-path` field.
----
Prompt:
```
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/community-edit-routing-options.html confuses me. It says that extended communities are not supported on static routes, and that large communities are ONLY supported on static routes. Can you build minimal Junos BGP labs to test this out?
```
Follow-up: extend the lab to exercise `defaults` with large
communities and what the peer receives, as a regression test.
dhalperi
enabled auto-merge (squash)
September 28, 2026 23:30
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #235 +/- ##
=======================================
Coverage 83.58% 83.59%
=======================================
Files 96 96
Lines 4703 4705 +2
=======================================
+ Hits 3931 3933 +2
Misses 772 772
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
dhalperi
added a commit
that referenced
this pull request
Sep 29, 2026
Two-node vJunos-router 25.4R1.12 lab for the undocumented `disable-linklocal-addr` statement. It is hidden from `set protocols bgp ?` but accepted at the protocol, group, and neighbor levels (including internal groups and routing instances); it takes no argument and is rejected under `family inet6` and `routing-options`. Without it, IPv6 UPDATEs carry a 32-byte MP_REACH next hop (global plus link-local); with it at any level, only the 16-byte global address. The receiver's installed route is the same either way, and committing the statement sends no UPDATE until the next refresh. The README includes the raw traceoptions, tcpdump, and CLI output. lab_builder: add a `bgp_update_next_hops` check that route-refreshes a Junos neighbor and parses the receiver's BGP update trace. `_junos_commit_check` now also treats a bare `syntax error.` response to a `set` line as a rejection; the `error:` match added in #235 missed it for unknown keywords. ---- Prompt: ``` • In batfish/lab-validation, create a public, anonymized Junos lab for `protocols bgp disable-linklocal-addr`. First use `commit check` on vJunos-router 25.4R1.12 to determine exactly where Junos accepts the statement: protocol, group, and neighbor hierarchies. Record rejected forms as well as accepted forms. If accepted, build a minimal two-router IPv6 eBGP topology. Advertise an IPv6 prefix and compare the sender's advertised route and receiver's installed route with and without `disable-linklocal-addr`. Capture enough raw Junos output to establish its effect on global and link-local BGP next-hop addresses. Document the Junos version, configuration, commands, and observed results. Add automated checks for the supported hierarchy and behavior. Do not change Batfish. Commit the lab and open a lab-validation PR. ```
dhalperi
added a commit
that referenced
this pull request
Sep 29, 2026
Two-node vJunos-router 25.4R1.12 lab for the undocumented `disable-linklocal-addr` statement. It is hidden from `set protocols bgp ?` but accepted at the protocol, group, and neighbor levels (including internal groups and routing instances); it takes no argument and is rejected under `family inet6` and `routing-options`. Without it, IPv6 UPDATEs carry a 32-byte MP_REACH next hop (global plus link-local); with it at any level, only the 16-byte global address. The receiver's installed route is the same either way, and committing the statement sends no UPDATE until the next refresh. The README includes the raw traceoptions, tcpdump, and CLI output. lab_builder: add a `bgp_update_next_hops` check that route-refreshes a Junos neighbor and parses the receiver's BGP update trace. `_junos_commit_check` now also treats a bare `syntax error.` response to a `set` line as a rejection; the `error:` match added in #235 missed it for unknown keywords. ---- Prompt: ``` • In batfish/lab-validation, create a public, anonymized Junos lab for `protocols bgp disable-linklocal-addr`. First use `commit check` on vJunos-router 25.4R1.12 to determine exactly where Junos accepts the statement: protocol, group, and neighbor hierarchies. Record rejected forms as well as accepted forms. If accepted, build a minimal two-router IPv6 eBGP topology. Advertise an IPv6 prefix and compare the sender's advertised route and receiver's installed route with and without `disable-linklocal-addr`. Capture enough raw Junos output to establish its effect on global and link-local BGP next-hop addresses. Document the Junos version, configuration, commands, and observed results. Add automated checks for the supported hierarchy and behavior. Do not change Batfish. Commit the lab and open a lab-validation PR. ```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two-node vJunos-router lab testing which community forms Junos accepts
in
routing-options {static|aggregate|generate}at route anddefaultslevel, and what the eBGP peer receives. Juniper'scommunity (Routing Options)reference describes large communities asstatic-only; on 25.4R1.12 they are accepted in all six contexts and
reach the peer. Extended communities (
target:,origin:) arerejected by the CLI parser in all six. A
DEFAULTSvirtual-routerexercises the
defaultsblocks over a second eBGP session.Batfish drops aggregate/generate routes carrying a route-level large
community and ignores large communities in their
defaultsblocks;test_main_rib_routes and test_bgp_rib_routes are sickbayed against
batfish/batfish#10367.
lab_builder:
_junos_commit_checknow treats anerror:response to asetline as a rejection. Previously the rejected line was neverloaded, so
commit checkpassed and the check reported "accepted".Junos BGP parser: strip the
Aggregator:line that aggregate routesappend to the
as-pathfield.Prompt:
Follow-up: extend the lab to exercise
defaultswith largecommunities and what the peer receives, as a regression test.