The IX route server
On the IX, R1 has an address on the shared peering LAN (192.0.2.25/24) and peers with the IX's route server at 192.0.2.1, AS64511. The route server isn't in the forwarding path. It collects routes from every member and reflects them to every other member without changing the next hop or adding its own AS. So when another member's route arrives:
- the AS path is just the member's AS (64502), not 64511 64502, and
- the next hop is the member's own peering-LAN address (192.0.2.40), so traffic goes directly across the IX switch to them.
Real IXs run two route servers on different hardware; you peer with both. (Bilateral sessions, set up directly with individual members, are configured exactly the same way: a neighbor on the peering LAN with its own remote AS.)
The IX export map is the same idea as transit: only OUR-PREFIXES leaves, everything else is denied. Never announce your transit routes to an IX. You would be offering free transit to every member.
Commit the IX session before adding import policy and look at what arrives. In this lab, the other member is announcing a private-range prefix (10.99.0.0/16) alongside its real one, a common mistake on real IXs. Without an import filter, R1 accepts it and installs it.
- R1 announces its prefix to both. R1 originates 198.51.100.0/24 and sends it to the upstream and to the IX route server. Outbound filters make sure nothing else is ever announced.
- The upstream sends the internet. The upstream sends a default route plus its own prefixes. With a full table it would be over a million routes.
- The route server passes on members' routes. The route server relays 203.0.113.64/26 from the member without adding its own AS, and leaves the next hop as the member itself (192.0.2.40). It's a matchmaker, not a router.
- Traffic to the member goes direct. Packets from the host to 203.0.113.64/26 cross the IX LAN straight to the member. The route server never sees traffic: it only exchanges routes.
- Everything else goes via transit. Any destination not learnt at the IX falls through to the upstream's routes or default. If the IX went down, IX destinations would follow the same path.
set policy route-map IX-OUT rule 10 action 'permit'
set policy route-map IX-OUT rule 10 match ip address prefix-list 'OUR-PREFIXES'
set policy route-map IX-OUT rule 100 action 'deny'
set protocols bgp neighbor 192.0.2.1 remote-as '64511'
set protocols bgp neighbor 192.0.2.1 description 'IX route server 1'
set protocols bgp neighbor 192.0.2.1 address-family ipv4-unicast route-map export 'IX-OUT'
set protocols bgp neighbor 192.0.2.1 address-family ipv4-unicast soft-reconfiguration inbound- Lines 1–3: The same export policy as transit, as a separate map so the two can diverge later (for example, prepending or communities for one but not the other).
- Lines 4–5: The route server's address and AS, from the IX's documentation or PeeringDB.
- Lines 6–7: Export and soft-reconfiguration, as for transit.
vyos@R1:~$ show ip bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.1, local AS number 64500 VRF default vrf-id 0
BGP table version 9
RIB entries 5, using 800 bytes of memory
Peers 2, using 60 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.0.2.1 4 64511 5 4 9 0 0 00:00:09 2 1 IX route server 1
203.0.113.0 4 64496 19 11 9 0 0 00:00:43 2 1 UPSTREAM transit
Total number of neighbors 2
vyos@R1:~$ show ip bgp neighbors 192.0.2.1 received-routes
BGP table version is 9, local router ID is 198.51.100.1, vrf id 0
Default local pref 100, local AS 64500
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.99.0.0/16 192.0.2.40 0 0 64502 i
*> 198.51.100.0/24 192.0.2.25 0 0 64500 i
*> 203.0.113.64/26 192.0.2.40 0 0 64502 i
Total number of prefixes 3, total number of paths 0
vyos@R1:~$ show ip bgp
BGP table version is 9, local router ID is 198.51.100.1, vrf id 0
Default local pref 100, local AS 64500
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0/0 203.0.113.0 0 0 64496 i
*> 10.99.0.0/16 192.0.2.40 0 0 64502 i
*> 198.51.100.0/24 0.0.0.0 0 32768 i
*> 203.0.113.64/26 192.0.2.40 0 0 64502 i
*> 203.0.113.128/25 203.0.113.0 0 0 64496 i
Displayed 5 routes and 5 total paths- Line 10: The route server session: 2 prefixes accepted.
- Line 24: A private range announced by another member. Without a filter, it is accepted.
- Line 25: Our own prefix, reflected back by the route server with our AS in the path. BGP loop prevention keeps it out of the table (it's missing from
show ip bgpbelow), and the import policy will reject it as well. - Line 26: The member's real prefix: AS path 64502 (no 64511), next hop 192.0.2.40 (not the route server). Traffic goes straight to the member.
- Line 40: The bogon is now in R1's table, installed for forwarding.
Check your understanding
A route from the IX route server shows AS path 64502 and next hop 192.0.2.40. Where does R1 send traffic for that prefix?
- To the route server at 192.0.2.1, which forwards it
- Directly to 192.0.2.40 across the IX switch
- To the upstream, because IX routes aren't installed
- To AS64511