Arista EOS: locally-originated BGP paths have weight 0 and local-pref 100, not 32768 and 0

[dhalperi]

Problem

Batfish models locally-originated BGP paths on Arista EOS with weight
32768, but the device actually uses weight 0. This produces a
test_bgp_rib_routes "weight difference" failure on every Arista lab
that has a network statement, aggregate-address, or equivalent
local origin.

Evidence

Reproducer snapshot: snapshots/eos_ceos_bgp_weight_experiment. Each
test router has two prefixes where a received path competes with a
locally-originated path:

• 10.100.0.0/24 — stock network 10.100.0.0/24, received path has
  weight 10000 via neighbor <peer> weight 10000.
• 10.200.0.0/24 — network 10.200.0.0/24 route-map SET_WEIGHT_50000
  (route-map sets weight 50000), same received-side weight.

EOS 4.36 output on both multi-agent and ribd agents:

• 10.100.0.0/24: received (weight 10000) wins. Device explicitly
  prints Not best: Path weight on the local path, which shows
  weight 0.
• 10.200.0.0/24: local (weight 50000) wins via the same Path weight step.

The effective default weight for a locally-originated BGP path on
Arista EOS is therefore 0, not 32768. Route-map set weight on a
network statement does apply.

The EOS manual §16.5.6.108 ("default weight for paths that the router
originates is 32768") describes the no neighbor weight reset
semantics, not the actual effective default of a locally-originated
path.

Scope

Affects Arista EOS only. Cisco IOS/IOS-XE and most other vendors do
use 32768 as the default local weight; Batfish's DEFAULT_LOCAL_WEIGHT
is correct for those vendors.

Impact — sickbay entries this replaces

The following sickbay.yaml entries currently reference issues #6
and/or #7 for this root cause and should be re-pointed here:

• eos_ceos_ebgp (BGP weight validation fails for local routes in ribd mode #6)
• eos_ceos_bgp_unnumbered (BGP weight validation fails for local routes in ribd mode #6)
• eos_ibgp_local_preference (BGP weight validation fails for local routes in ribd mode #6)
• eos_ospf_bgp (BGP weight validation fails for local routes in ribd mode #6)
• mix_vendor_bgp_vrf (BGP weight validation fails for local routes in ribd mode #6)
• eos_bgp_aggregate (BGP weight validation fails for local routes in ribd mode #6)
• eos_iosxe_aws_demo (BGP weight validation fails for local routes in ribd mode #6, BGP weight validation inconsistent in multi-agent mode for local vs received routes #7)
• cv_demo_base_panos (BGP weight validation fails for local routes in ribd mode #6, BGP weight validation inconsistent in multi-agent mode for local vs received routes #7)
• eos_evpn_l3_design_guide (BGP weight validation inconsistent in multi-agent mode for local vs received routes #7)
• eos_evpn_l3_design_guide_vlan_based (BGP weight validation inconsistent in multi-agent mode for local vs received routes #7)

Next Steps

1. Fix Batfish: for Arista EOS vendor config, locally-originated BGP
   paths (from network, aggregate-address, and redistribute) should
   start with weight 0 rather than DEFAULT_LOCAL_WEIGHT (32768).
2. Once Batfish emits weight 0 for these paths, the validator weight
   comparison will match and the sickbay entries can be removed.

Closes #6, closes #7.

[dhalperi]

Extended the reproducer lab to also isolate the local-preference
step of best-path selection. Two new prefixes, 10.101.0.0/24 and
10.102.0.0/24, each network-statement-originated by the test
routers. On the received side, an inbound route-map sets:

• 10.101.0.0/24: set local-preference 50
• 10.102.0.0/24: set local-preference 150

Both with weight left at 0 on both sides, so local-preference is the
deciding best-path step. Result on EOS 4.36, same in multi-agent and
ribd:

• 10.101.0.0/24: local wins. Device emits "Not best: Local
  preference" on the received path. → local-pref(local) > 50.
• 10.102.0.0/24: received wins. Device emits "Not best: Local
  preference" on the local path. → local-pref(local) < 150.

Combined: the effective local-preference of a locally-originated BGP
path on Arista EOS is 100 (the standard BGP default), not 0.

This is a second modeling bug in addition to the weight one:

• Batfish currently sets local-preference 0 on locally-originated paths
  (AristaConfiguration.java ~L898) — should be 100 (DEFAULT_LOCAL_PREFERENCE).
• Batfish currently sets weight 32768 on locally-originated paths
  (AristaConfiguration.java ~L899) — should be 0.

Both originate from the same redistributionPolicy block and affect
the same paths (network, aggregate, redistributed connected/static/etc).

Fix plan updated: remove both SetLocalPreference(0) and
SetWeight(DEFAULT_LOCAL_BGP_WEIGHT) from the Arista BGP
redistribution policy. The resulting paths will inherit
BGP's industry-standard defaults (local-pref 100, weight 0), which
match empirical EOS behavior.

[dhalperi]

The core fix has landed:

• Weight: Arista: do not set weight 32768 on locally-originated BGP paths batfish#9913 — locally-originated BGP paths
  (network, redistribute) now use weight 0 instead of 32768.
• Local-preference: Arista: do not set local-preference 0 on locally-originated BGP paths batfish#9915 — locally-originated
  BGP paths now use the BGP default LP (100) instead of 0.
• Validator: lab-validation PR pending — None local-pref
  (field absent in newer EOS JSON) treated as 100 instead of 0.

Remaining scope: aggregate routes still use weight 32768 and
LP 0 via the shared BgpProtocolHelper.toBgpv4Route code path.
This affects eos_bgp_aggregate, eos_ospf_bgp, and cv_demo_base_panos.
Fixing aggregates requires a vendor-specific override in
BgpProtocolHelper; leaving this issue open for that follow-up.