Recently had a chance to play around with my very first T1, interfacing two routers in a place we’ll call Branch1, across a T1 link between buildings on the site. Fun times! I’ve only ever interfaced with a T1 initially configured by the provider, or by way of a frame-relay switch, but have never had to go from serial interface directly into CSU/DSU, oddly enough. Spent the better part of a week wondering what cable I should use, though I needn’t have worried…a router that’s already connected to a CSU/DSU will give you the right answer if you know what question to ask:
R3#sho controllers serial 0/0
Interface Serial0/0
Hardware is PowerQUICC MPC860
DTE V.35 TX and RX clocks detected.
idb at 0×81122904, driver data structure at 0×8112A398
…
The truly fun part came in figuring out how to do the routing. My newly acquired remote sites are all set up as EIGRP stub routers, since I don’t need them transiting traffic for other sites. Sites that are NOT set up as stub routers (i.e. the default when bringing up EIGRP), when brought into a dual-hub-and-spoke topology such as ours (where all the remote sites have at least two VPN tunnels: one to each “hub” site), will advertise routes learned from Hub1 back to Hub2 and vice versa. That makes for a messy and complicated EIGRP topology table, and makes routes from Hub1 appear (from Hub2’s perspective) to be available via Branch1 (and vice versa), meaning if the links between Hub1 and Hub2, Branch1 could be used as a transit site for Hub1-Hub2 traffic. EIGRP stubs stop this behaviour; they will accept routes from their peers, but EIGRP stub routers by default will only advertise connected and summary routes back to their peers.
This is fine when the site has just one router; it’s more complicated when there are routers downstream from your stub router, as is the case with Branch1. A router downstream of the EIGRP Stub router carries traffic for the 172.29.18.0/24 LAN in a different building at the facility. Setting up EIGRP between this router and the Stub router will cause 172.29.18.0/24 to be advertised to the Stub router, but the Stub router will not advertise the 172.29.18.0/24 route to Hub1 or Hub2, making the network unreachable from our hub sites. You could just point default on the downstream router, and redistribute a static route on the Stub router, but where’s the fun in that…
In my case, the Branch1 office LAN and the adjacent building’s LAN are bitwise-adjacent: 172.29.19.0/24 and 172.29.18.0/24, respectively. This neatly summarizes to 172.29.18.0/23, so all I had to do was configure the summary route to be advertised on the tunnel interfaces of R2, and point default on R3 – since stub routers will by default advertise summaries, no more work had to be done. There are other options to do this, for the curious (mostly covered here: http://www.nil.com/ipcorner/EigrpStub/).
Config on the stub is as follows (for simplicity, the link to only one hub site is shown). No need to configure a static route to 172.29.18.0/24 on R2, because it will learn the route from its neighbour R3 — but since R2 is a stub, it won’t advertise the 172.29.18.0/24 upstream to R1. I had a static route in anyway from earlier testing, and I’ll get to that in a second.
interface Tunnel1011105
description “To R1 Hub Site”
bandwidth 3072
ip summary-address eigrp 102 172.29.18.0 255.255.254.0 5
!
i
!
router eigrp 102
eigrp stub connected summary
As mentioned a second ago, for a while I was using a static route on the Stub router, pointing to the downstream router in the other building, and redistributing static into EIGRP. When I actually brought up EIGRP between the two, got a chance to see something neat. Picture attached for ease of reference.
Doing a “show ip route” showed the proper next hop as per the configured static route:
R2#sho ip route 172.29.18.0
Routing entry for 172.29.18.0/24
Known via “static”, distance 1, metric 0
Routing Descriptor Blocks:
- 172.29.254.62
Route metric is 0, traffic share count is 1
Admin distance of 1 beats everything but a better-match (i.e. longer prefix) or a directly connected route.
But with EIGRP now running between the two, it also showed up in the EIGRP topology table, but with a max metric (note that the composite metric is actually correct; it’s a function of min bandwidth and total delay along with path, and the configured K values i.e. “eigrp metric …” and we use weird K-values in our environment, so YMMV):
R2#sho ip eigrp topology 172.29.18.0 255.255.255.0
IP-EIGRP (AS 102): Topology entry for 172.29.18.0/24
State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
Routing Descriptor Blocks:
172.29.254.62 (Serial0/0/1), from 172.29.254.62, Send flag is 0×0
Composite metric is (4230656/38400), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
I then removed the static route, and ran the same commands. EIGRP took over, and nary a packet was lost. The metric given by FD also correctly matches that given by the “composite metric”:
R2#sho ip route 172.29.18.0
Routing entry for 172.29.18.0/24
Known via “eigrp 102”, distance 90, metric 4230656, type internal
Redistributing via eigrp 102
Last update from 172.29.254.62 on Serial0/0/1, 00:00:51 ago
Routing Descriptor Blocks:
- 172.29.254.62, from 172.29.254.62, 00:00:51 ago, via Serial0/0/1
Route metric is 4230656, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R2#sho ip eigrp topology 172.29.18.0 255.255.255.0
IP-EIGRP (AS 102): Topology entry for 172.29.18.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 4230656
Routing Descriptor Blocks:
172.29.254.62 (Serial0/0/1), from 172.29.254.62, Send flag is 0×0
Composite metric is (4230656/38400), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Of course, the rest of the network doesn’t see any of this complexity at all. It just sees the summary route. From R1:
R1#sho ip route 172.29.18.0
Routing entry for 172.29.18.0/23
Known via “eigrp 102”, distance 90, metric 7246080, type internal
Redistributing via eigrp 102
Last update from 10.1.1.106 on Tunnel1011105, 01:29:47 ago
Routing Descriptor Blocks:
- 10.1.1.106, from 10.1.1.106, 01:29:47 ago, via Tunnel1011105
Route metric is 7246080, traffic share count is 1
Total delay is 50100 microseconds, minimum bandwidth is 3072 Kbit
Reliability 255/255, minimum MTU 1440 bytes
Loading 1/255, Hops 1
Also note the change in minimum bandwidth; locally in Branch1, the minimum bandwidth to 172.29.18.0/24 is that of the T1 interconnecting the two EIGRP peers: 1544 kbps. When this route gets hidden behind the summary, it inherits the minimum bandwidth as seen on the path between remote sites and the originator of the summary route. Since the bandwidth of the tunnel between R1 and the summary originator (a tunnel on vpn-01.mtj with configured bandwidth of 3072), that explains the change in min bandwidth.
The delay value comes from the sum of delays along the path: the delay of the lowest-delay component route on the summary-originating router (which is the fa0/1 interface – 172.29.19.0/24 — on vpn-01.mtj, with a delay of 100 usec) + the delay of the next-hop tunnel interface (default 50,000 usec, seen with “sho int tunnel…” command) == 50,100 usec.
So if you ever see something like that max metric in the EIGRP topology table, that’s where it came from: there was already a route with a better administrative distance on the router, but EIGRP keeps its route installed in its topology table “just in case.” Contrast with RIP, which only keeps a route in its database if it’s the best route; all others will not show up in the output of “show ip rip database.”
