# Leveraging AT&T’s Public Route Monitor AT&T’s Route Monitor at _route-server.ip.att.net_ provides a live, read-only view of the global BGP table directly from a Junos core router, giving engineers an outside-in vantage point when troubleshooting reachability, policy, or route security. While most looking-glasses hide behind web forms, this node offers interactive CLI access. You can open a plain Telnet session to TCP 23 or an SSH session to TCP 22; in both cases log in with the public credentials `rviews / rviews`, and a restricted Juniper shell appears. Telnet is handy for ad-hoc checks, but SSH’s encrypted transport survives middle-box idle-timeout resets and guards against credential snooping on shared networks. Telnet quick test: ```bash telnet route-server.ip.att.net 23 # login: rviews # password: rviews ``` SSH with host-key check disabled (the server rotates keys periodically): ```bash ssh -o StrictHostKeyChecking=no [email protected] ``` Once connected, a banner enumerates several IPv4 and IPv6 peers in cities such as Atlanta, Dallas, and Los Angeles, underlining that every command is executed against AT&T’s live eBGP edge rather than a canned snapshot. The platform transitioned from Cisco IOS to Junos more than a decade ago, so IOS commands like `show ip bgp` will not parse; instead use Junos syntax such as `show route` or `show bgp summary`. A quick sanity check is to display the full table with: ```bash show route terse protocol bgp ``` Expect roughly 900 k IPv4 prefixes today; Junos will report each prefix’s next-hop, preference, and age. For prefix-specific analysis run, for example, `show route 8.8.8.0/24 detail`. The detailed view reveals the received AS-path, MED, local-preference, and any BGP communities, allowing instant confirmation that a new prepend or black-hole community is propagating as intended. The identical command works for IPv6, so you can inspect `2001:4860:4860::8888/128` without switching contexts. ```bash [email protected]> show route 8.8.8.0/24 detail inet.0: 984264 destinations, 15746317 routes (984263 active, 0 holddown, 1 hidden) 8.8.8.0/24 (16 entries, 1 announced) *BGP Preference: 170/-101 Next hop type: Indirect, Next hop index: 0 Address: 0x9628c9c Next-hop reference count: 984138 Kernel Table Id: 0 Source: 12.122.83.238 Protocol next hop: 12.122.83.238 Indirect next hop: 0x2 no-forward INH Session ID: 0 State: <Active Ext> Local AS: 65000 Peer AS: 7018 Age: 5w6d 16:02:29 Metric2: 0 Validation State: valid Task: BGP_7018.12.122.83.238 Announcement bits (1): 3-Resolve tree 1 AS path: 7018 15169 I Communities: 7018:2500 7018:36244 Accepted Localpref: 100 Router ID: 12.122.83.238 Thread: junos-main BGP Preference: 170/-101 Next hop type: Indirect, Next hop index: 0 Address: 0x28c713dc Next-hop reference count: 984138 Kernel Table Id: 0 Source: 12.122.120.7 Protocol next hop: 12.122.120.7 Indirect next hop: 0x2 no-forward INH Session ID: 0 State: <NotBest Ext> Inactive reason: Not Best in its group - Router ID Local AS: 65000 Peer AS: 7018 Age: 11w4d 6:24:27 Metric2: 0 Validation State: valid Task: BGP_7018.12.122.120.7 AS path: 7018 15169 I Communities: 7018:2500 7018:39220 Accepted Localpref: 100 Router ID: 12.122.120.7 Thread: junos-main BGP Preference: 170/-101 Next hop type: Indirect, Next hop index: 0 Address: 0x2bf6cc9c Next-hop reference count: 984138 Kernel Table Id: 0 Source: 12.122.124.12 Protocol next hop: 12.122.124.12 Indirect next hop: 0x2 no-forward INH Session ID: 0 State: <NotBest Ext> Inactive reason: Not Best in its group - Router ID Local AS: 65000 Peer AS: 7018 Age: 11w4d 6:24:24 Metric2: 0 Validation State: valid Task: BGP_7018.12.122.124.12 AS path: 7018 15169 I Communities: 7018:2500 7018:39343 Accepted Localpref: 100 Router ID: 12.122.124.12 Thread: junos-main ---(more)--- ``` Several high-leverage workflows emerge once the basic navigation is familiar. When launching a DDoS black-hole, querying the affected prefix immediately verifies that AT&T rewrote the next-hop to discard traffic and that the correct black-hole community (for example `65535:666`) is visible in the attributes. After tweaking prepends aimed at AS 7018, you can watch the AS-path shrink from the intentionally lengthy “65000 65000 65000 3356” back to a single hop, confirming propagation before pushing the change to other upstreams. If return traffic appears asymmetric, inspect `show route <your-prefix> multipath` and compare local-pref values to see whether AT&T’s decision process diverges from your expectations. During suspected backbone instability, repeatedly issuing `show bgp summary` highlights peers whose prefix count drops, evidence of flap dampening or maintenance, without ever risking a configuration change. Finally, after publishing a new ROA, `show route validation-database origin-as <your-asn>` confirms that AT&T’s RTR cache now marks your routes _valid_, closing the loop on RPKI deployment. Because the monitor is read-only, feel free to pipe or filter output (`| match`, `| count`) or script interactions with `expect` for batch checks. Sessions time out after roughly five minutes of inactivity, so capture output promptly; logging out with `exit` frees the VTY line for others. Always corroborate findings with at least one additional looking-glass before making production decisions.