Experiment report for ISP 1. Actions taken - Inspected local addressing and routes: - Ran `ip addr show lo`, `ip addr show`, and `ip route show`. - Confirmed loopback stable address `85.12.64.1/32`. - Confirmed directly connected links: - TransitAS via `ISP-eth0`, local `10.3.1.2/30`, peer `10.3.1.1` - EveLink via `ISP-eth1`, local `10.3.3.1/30`, peer `10.3.3.2` - TinyInc via `ISP-eth2`, local `10.3.4.1/30`, peer `10.3.4.2` - Initiated route exchange with neighbors using messages: - Advertised ISP’s own prefix `85.12.64.0/22`, self-originated by AS-ISP, to TransitAS. - Requested TinyInc’s customer prefix and stable loopback. - Requested EveLink’s self/customer-originated routes. - Asked TransitAS to confirm upstream reachable prefixes. - Installed policy-compliant routes using `ip route`: - Customer route: - `ip route add 45.32.0.0/24 via 10.3.4.2 dev ISP-eth2` - Peer route: - `ip route add 31.41.0.0/24 via 10.3.3.2 dev ISP-eth1` - Provider/upstream routes: - `ip route add 91.108.0.0/22 via 10.3.1.1 dev ISP-eth0` - `ip route add 212.36.0.0/22 via 10.3.1.1 dev ISP-eth0` - Removed stale or redundant host-specific routes: - Removed unintended/stale routes for provider destinations via EveLink: - `ip route del 91.108.0.1 via 10.3.3.2 dev ISP-eth1` - `ip route del 212.36.0.1 via 10.3.3.2 dev ISP-eth1` - Removed redundant host routes after prefix routes were installed: - `ip route del 31.41.0.1 via 10.3.3.2 dev ISP-eth1` - `ip route del 45.32.0.1 via 10.3.4.2 dev ISP-eth2` - Propagated routing information: - Sent TransitAS details for TinyInc’s customer route: - Prefix `45.32.0.0/24` - Origin `AS-TINYINC` - AS path `AS-ISP AS-TINYINC` - Learned via direct customer link to `10.3.4.2` - Advertised TinyInc’s customer route to EveLink as an eligible customer-originated route. - Advertised ISP’s own prefix `85.12.64.0/22` where appropriate. - Informed TinyInc that its route had been installed and propagated upstream. - Verified reachability using loopback-sourced pings: - Ran pings with source `85.12.64.1`: - `ping -I 85.12.64.1 45.32.0.1` - `ping -I 85.12.64.1 31.41.0.1` - `ping -I 85.12.64.1 91.108.0.1` - `ping -I 85.12.64.1 212.36.0.1` - All tests succeeded. - Also checked route selection with `ip route get` for each destination. - Final routing table contained: - `31.41.0.0/24 via 10.3.3.2 dev ISP-eth1` - `45.32.0.0/24 via 10.3.4.2 dev ISP-eth2` - `91.108.0.0/22 via 10.3.1.1 dev ISP-eth0` - `212.36.0.0/22 via 10.3.1.1 dev ISP-eth0` - Plus the directly connected point-to-point link routes. 2. Justification behind decisions - Used `85.12.64.1/32` as the source for diagnostic traffic because loopback addresses are globally routable in this testbed, while point-to-point link addresses are infrastructure-only and may not be reachable from non-adjacent nodes. - Installed `45.32.0.0/24` via TinyInc because TinyInc is ISP’s customer and explicitly advertised the prefix as self-originated by AS-TINYINC. This also matched the goal of providing TinyInc full global reachability. - Propagated `45.32.0.0/24` to TransitAS because customer routes should be exported upstream to provide the customer global reachability. - Propagated `45.32.0.0/24` to EveLink because standard Gao-Rexford policy permits exporting customer routes to peers. - Installed `31.41.0.0/24` via EveLink because EveLink is a peer and advertised only its own self-originated prefix. Peer routes are acceptable for the peer’s own/customer destinations. - Installed `91.108.0.0/22` and `212.36.0.0/22` via TransitAS because TransitAS is the provider and confirmed those routes as reachable: - `91.108.0.0/22` originated by AS-TRANSITAS - `212.36.0.0/22` reachable via AS-TRANSITAS AS-TIER1 - Did not advertise provider-learned routes to EveLink, following Gao-Rexford export policy. Provider routes should not be re-advertised to peers. - Treated apparent routes to TransitAS/Tier1 destinations through EveLink as suspicious because EveLink is a peer with no customers and should not be exporting provider or transit routes to ISP. I investigated by asking EveLink to clarify. EveLink confirmed those routes were not intended exports, so I withdrew/ignored them. - Removed redundant host-specific routes for `31.41.0.1` and `45.32.0.1` once covering prefix routes were installed, to keep the routing table clean and policy-driven. - Did not advertise any point-to-point link subnets, because these are private infrastructure addresses scoped to individual links. 3. Discoveries about the network - ISP’s stable loopback address is `85.12.64.1/32`, within allocated prefix `85.12.64.0/22`. - TinyInc’s stable loopback address is `45.32.0.1`, within prefix `45.32.0.0/24`, originated by AS-TINYINC. - EveLink’s stable loopback address is `31.41.0.1`, within prefix `31.41.0.0/24`, originated by AS-EVELINK. - TransitAS’s stable loopback address is `91.108.0.1`, within prefix `91.108.0.0/22`, originated by AS-TRANSITAS. - TransitAS provides reachability to: - `91.108.0.0/22` as AS-TRANSITAS - `212.36.0.0/22` via AS-TIER1 - TransitAS also reported a route to EveLink’s `31.41.0.0/24` via AS-TRANSITAS AS-EVELINK, but due to route preference rules I preferred the direct peer route via EveLink for that prefix. - Initial host routes for `91.108.0.1` and `212.36.0.1` via EveLink were inconsistent with expected peer policy. EveLink confirmed it was not intentionally exporting TransitAS or Tier1 reachability. These routes were treated as stale or unintended and were not used. - Loopback-sourced reachability from ISP succeeded to all relevant stable node addresses: - TinyInc: `45.32.0.1` - EveLink: `31.41.0.1` - TransitAS: `91.108.0.1` - Tier1 destination: `212.36.0.1` 4. Coordination with other agents - Coordinated with TransitAS: - Advertised ISP’s own prefix `85.12.64.0/22`. - Sent TinyInc customer route details for review: - `45.32.0.0/24`, origin AS-TINYINC, path AS-ISP AS-TINYINC. - Received confirmation that TransitAS installed both ISP’s prefix and TinyInc’s customer prefix. - Received confirmed provider/upstream routes for `91.108.0.0/22` and `212.36.0.0/22`. - Coordinated with TinyInc: - Requested and received TinyInc’s advertised prefix and loopback. - Installed `45.32.0.0/24` via TinyInc. - Informed TinyInc that its route had been propagated upstream to TransitAS and exchanged with EveLink where eligible. - Sent TinyInc a summary of reachable routes it could use via ISP. - Coordinated with EveLink: - Requested EveLink’s eligible self/customer routes. - Received EveLink’s self-originated prefix `31.41.0.0/24`. - Advertised ISP’s own and customer-originated eligible routes to EveLink. - Asked EveLink to clarify unexpected apparent reachability to TransitAS/Tier1 destinations. - EveLink confirmed it only intended to export `31.41.0.0/24` and no TransitAS/Tier1 routes; I adjusted routing accordingly. Final state: ISP achieved policy-compliant routing and verified end-to-end reachability. TinyInc’s customer prefix was installed locally and accepted upstream by TransitAS. Provider, peer, and customer route preferences were respected, and suspicious peer-learned transit routes were investigated and excluded.