What happens when you have classful routing enabled and are only advertising downstream default route as a summary?
We can get some odd behavior with classless disabled. Everything may appear fine on first glance. But can remain in a broken state.
Let’s set up the test. We can start by disabling classless routing on R02
R02(config)# no ip classless
There’s a static route that R01 points to R02. And R02 points to R01.
ip route 0.0.0.0 0.0.0.0 10.1.12.X
R02 and R03 are allowed to dynamically exchange routes.
Troubleshooting –
Let’s test connectivity to the loopback on R02.
R01#ping 10.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R01#ping 10.2.2.2 source loop0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Now to test connectivity to R03.
R01#ping 10.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R01#ping 10.3.3.3 source loop0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Great we now have full reachability! Everyone can go home. Mission Accomplished!
But the next day come into work and you can no longer reach your router! Oh no it’s a bug, it’s a dead router, it’s a TAC call!
You can successfully telnet into the router behind R02.
R01#telnet 10.3.3.3 /source-interface loop0
Trying 10.3.3.3 ... Open
User Access Verification
Username: cisco
Password:
R03#exit
But try as you might you can’t get into R02.
R01#telnet 10.2.2.2 /source-interface loop0
Trying 10.2.2.2 ... % Connection timed out; remote host not responding
You even go as far as to create an access-group on the inbound interface.
R02(config)#do sh access-list
Extended IP access list TELNET_TEST
10 permit tcp any host 10.2.2.2 eq telnet (4 matches)
20 permit tcp any host 10.3.3.3 eq telnet (42 matches)
30 permit ip any any (590 matches)
The Why –
But of course we already know the answer. It’s classful routing.
The router will accept the Telnet packets and punt them to the CPU. You can see this using packet-trace debugging on the newer XE.
R02#show platform packet-trace packet 0
Packet: 0 CBUG ID: 49
Summary
Input : GigabitEthernet1.12
Output : internal0/0/rp:0
State : PUNT 11 (For-us data)
Timestamp
Start : 41385897469217 ns (08/12/2019 02:31:45.258831 UTC)
Stop : 41385897506086 ns (08/12/2019 02:31:45.258868 UTC)
Path Trace
Feature: IPV4(Input)
Input : GigabitEthernet1.12
Output : Source : 10.1.1.1 Destination : 10.2.2.2 Protocol : 6 (TCP) SrcPort : 44461 DstPort : 23
But Since you can’t disable CEF on the newer platforms, you can’t see the full logic. Also keep in mind that ping still works and so does transit traffic. I believe it’s because of CEF for the transit traffic. Since it never has to go to general CPU. Not 100% sure yet why ping seems to work fine.
And with a full ip packet debug running –
FIBipv4-packet-proc: packet routing failed
I highly recommend a read through.
Now you may be asking yourself why do I need to know something like this? I’ll just never enable it. Problem solved. But there’s a small chance that someone might. And recognizing that behavior will go a long way in less hair pulling.