Had a strange routing problem tonight between a L3 switch that acts as the internal router for a branch office, and the ASA that is the Internet gateway as well as the tunnel endpoint for the VPN to our main site. The L3 switch runs EIGRP on all of it's SVI's as well as the routed link to the ASA (there's actually another L3 switch that is the backup router for the branch utilizing HSRP with the 1st L3 switch, that also has a routed link to the ASA, but in this case it was off.) When the ASA came up and began participating in the EIGRP AS, it only inserted two of the four routes being advertised by the L3 switch (its four SVI int's.) Unfortunately, one of the missing routes was the main network there Then about 10 min's later, the 3rd route popped in (the aforementioned main network) and then a few more min's later, the fourth and final network.
Why would this happen, and how can I troubleshoot this post-facto? I am just now climbing the CCNP ladder, and am still pretty much a newb to EIGRP and dyn routing in general... I can post configs etc if helpful, just let me know what is needed.
Sent from Cisco Technical Support iPhone App
Solved! Go to Solution.
Well, as soon as you enable EIGRP, it should start sending hellos out each and
every interface that is active and is participating in EIGRP.
router eigrp 100
If you ran the following command, that would enable EIGRP As 100 on all interfaces
that are active and belong to the 10.10.10./24 network. So if you created another
interface and gave it an IP of 10.10.10.5, EIGRP should start sending hellos out
that interface. As to why it took a while for EIGRP to pop those routes in, I couldn't tell ya
it really doesn't make any sense. EIGRP sends its full routing table as soon
as it discovers a neighbor. AFter that, the only thing that is sent are updates,
and partial updates. So if you added network 184.108.40.206, a partial update would
be sent just for 220.127.116.11 not all updates.
But if you can post your interface and eigrp configs for the two switches and asa. Please sanitize the config so
you don't get out sensitive information.
Here is the ASA's EIGRP config:
router eigrp 2
network 192.168.254.0 255.255.255.240
The int on the ASA connected to the L3 switch has IP addr 192.168.254.1
And the L3 switch:
router eigrp 2
network 10.1.240.0 0.0.15.255
network 192.168.254.2 0.0.0.0
The switch's 'sh ip int brief' relevant output:
Interface IP-Address OK? Method Status Protocol
Vlan1 unassigned YES NVRAM administratively down down
Vlan78 172.25.78.241 YES NVRAM up up
Vlan79 172.25.79.241 YES NVRAM up up
Vlan80 172.25.80.241 YES NVRAM up up
Vlan254 10.1.254.241 YES NVRAM up up
GigabitEthernet1/0/1 192.168.254.2 YES NVRAM up up
Output of 'sh ip eigrp int' on the switch:
EIGRP-IPv4 Interfaces for AS(2)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Vl254 1 0/0 8 0/1 50 0
Vl78 1 0/0 1276 0/1 7984 0
Vl79 1 0/0 1 0/1 50 0
Vl80 1 0/0 1 0/1 50 0
Gi1/0/1 1 0/0 1 0/1 50 0
This is a capture on the ASA of what I saw when I connected to it last night:
asa# sh route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
- candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is xx.xx.xx.1 to network 0.0.0.0
C xx.xx.xx.0 255.255.254.0 is directly connected, internet
C 192.168.254.0 255.255.255.248 is directly connected, To-RSW1
C 192.168.100.0 255.255.255.0 is directly connected, wireless
Notice that the 172.25.79.0 net was added 10 min's after the other two EIGRP routes, and that is doesn't have the 4th network (10.1.254.0)...
D 172.25.80.0 255.255.255.0 [90/3072] via 192.168.254.2, 0:27:54, To-RSW1
D 172.25.79.0 255.255.255.0 [90/3072] via 192.168.254.2, 0:17:21, To-RSW1
D 172.25.78.0 255.255.255.0 [90/3072] via 192.168.254.2, 0:27:54, To-RSW1
I see what you mean about the 172.25.79.0/24 network. Can you do a 'show logging' on the switch and see if
maybe the interface for that network was shutdown by any chance? If all interfaces were up and networks
added properly on the switch, under the eigrp configuration, then they all should have been included during
the initial routing table exchange. That would tend to make be believe that it was not availale during the initial
routing table exchange? Were all these networks added at the same time?
The 4 int's that have the networks that I need the ASA to have routing entries for are all SVI's (VlanXX int's) and so are started when the switch boots; as you can see, they are up/up in the switch output, started via NVRAM (i.e. at startup.) So it wasn't because the switch int's weren't up at ASA init time...
The only thing that I can add is that the L3 switch has one L2 phys int in VLANs 78, 79 and 80; the VLAN 254 int is new, and there are no L2 phys int's in that VLAN as of yet. I believe that the connected device on the L3 switch off the VLAN 79 int was not up as was the VLAN 78 and 80 int's when the ASA booted; however, I'm not sure why that matters, because the SVI int's were up, and those int's are what are participating in EIGRP. And in any case, there are no phys int's assigned to VLAN 254 yet, and that route did eventually show up on the ASA anyways. So, I am just confused as towhy all four routes weren't populated in the ASA as soon as it began participating in EIGRP...
So, mystery solved...
Here is the L3 switch log entries having to do with the SVI line proto changes:
*Mar 1 00:01:36.678: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar 1 00:01:41.661: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan78, changed state to down
*Mar 1 00:01:41.913: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan79, changed state to down
*Mar 1 00:01:41.913: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan80, changed state to down
*Mar 1 00:01:41.913: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan254, changed state to down
*Mar 1 00:01:45.595: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan78, changed state to up
*Mar 1 00:01:49.655: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan80, changed state to up
*Mar 1 00:12:24.505: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan79, changed state to up
*Mar 1 00:43:31.532: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan254, changed state to up
Not really sure, but it looks like the problem SVIs were in an up/down state until a physical int that was in those VLANs came up (didn't know that was the way SVIs worked until now...) So, when the line proto came up, the network on those int's was then advertised to the ASA, which dutifully inserted them in it's routing table.
So, all is basically fine, and now I know someting else I didn't know
Thanks, John, for trying to help me... It was because of you that I checked the logs to see if they held any clues, and they did (as they usually do...)
Yeah, I kinda figured it was something like that. An SVI will not become active unless a physical port has been assigned
to that vlan and up. I'm glad you were able to found out what happend. I hate wondering why something happend, and then not being able to figure it out, it kills me!
Have a good one Dennis!