04-19-2012 12:57 PM - edited 03-07-2019 06:14 AM
I am working at a client site today on a routing issue. I am currently working on an issue where a 3750 switch running EIGRP will not update its neighbor router when a network statement is added to the eigrp instance.
The neighbor is a 3825 router.
Both the switch and the router have a common network which is 192.168.36.0/24.
Both the switch and the router are in a neighbor adjacency.
Both boxes have "no auto-summ" in the routing configuration instance.
I can run debugs on both routers (debug eigrp packets) and then I can watch queries and updates when I issue "auto-summ" or "no auto-summ". Also I see a "graceful restart" for the peers when this is done.
I had an expectation that when I added the network (this is just an arbitrary network for testing, which is 172.16.69.0/24). I wanted to watch this network being sent in an update to the neighbor router.
When I add the above mentioned network, there are no updates packets sent from the 3750 to the 3845. I have not had success to this point trying to resolve. I have followed the Cisco document "Troubleshooting EIGRP Flow Chart", but have exhausted all it has to offer and now it is at the point where it is telling me to contact TAC.
I wanted to post this first. I am sure this is something simple I am missing. I appreciate any and all help.
Thank You.
Solved! Go to Solution.
04-19-2012 01:56 PM
Hi Robert,
Routing Protocol is "eigrp 13"
Stub, connected
Having stub will not stop you advertising conncted subnets.
Kevin tried to advertise something that did not exist in the routing table.
Dan
05-03-2012 09:06 AM
Hi Kevin,
First of all I have to explain why I do think that you need to filter :
when you create a summary route on the eigrp , even though you are creating it on the interface, the eigrp process will have this route in the topology and it will advertise the summary to any eigrp neighour.
So if you want to make two summaries ( 1 client routes and 1 BP routes ) we have to prevent this routes going to BP ( the BP summary ) and to client ( the Clinet summary ).
Furthermore you will advertise a summary route of the client to BP network, I do not know if the BP network filters the advertisements but there are some chances that this summary will reach your 3750 HQ switch and then goes to the client.
Where you have indicated that I should "filter OUT - on the MPLS interface the CLIENT summary... Do I use a distribute list with a deny statement to accomplish this?
Yes, on 3750 DR, yes and set the distribute list on the client interface ( or SVI ). For example
distribute-list CLIENT-OUT out fa1/0/1
or
distribute-list CLIENT-OUT out Vlan 5
ip access-l stan CLIENT-OUT
deny
permit any
The client's summary should be created on the interface toward the BP.
Where you have indicated that I should "filter OUT - on the BP interface the BP summary.... We do not have access to the BP router, so I would only be able to accomplish this by working with the BP. I know this isnt a quesiton per say, but did want to document that with you.
No, it's the same as for the client summary.
interface
ip summary-address eigrp #
ip access-l stan BP-OUT
deny
permit any
router eigrp #
distribute-list BP-OUT out
Now comes to my mind that you have to filter this BP-summary also on HQ 3750 , coming from MPLS. (!!!)
Where you have indicated that I should "filter IN - on the BP interface the CLIENT summary... Do I use a distribute list with a permit statement to accomplish this?
No. On HQ 3750 you will have 2 filters related to the summary made on DR:
access-list stan BP-IN
deny
permit any
access-list stan CLIENT-IN
deny
permit any
router eigrp #
distribute-list CLIENT-IN in
distribute-list BP-IN in
Because you do not want the BP summary that was created on DR and you do not want the client summary also made by the DR.
The HQ 3750 is currently not configured as a stub.
That's good ! Then on HQ 3750 will only filter the summaries made by the DR 3750
Regards
Dan
04-19-2012 01:11 PM
Hi Kevin ,
Please paste from your 3750 :
show ip route 172.16.69.0
show ip eigrp topology 172.16.69.0 255.255.255.0
show ip eigrp nei
show ip protocols
Dan
04-19-2012 01:31 PM
Dan
Thanks for your quick response.
If i perform a "sho ip route 172.16.69.0" on the WAN switch, it does not show the subnet. This is not a real route. I was only using it for testing. Is this an issue?
If it is, then what I need to publish now is that there are several Real network statements on the WAN switch which do not seem to make it to the 3845 router. On the 3845 router, I should see Feasible successors under the Successor on the EIGRP topology table, but do not.
LOWANSWT#sho ip route 172.16.69.0
% Subnet not in table
LOWANSWT#show ip eigrp topology 172.16.69.0 255.255.255.0
EIGRP-IPv4 Topology Entry for AS(13)/ID(192.168.38.5)
%Entry 172.16.69.0/24 not in topology table
LOWANSWT#sho ip eigrp nei
EIGRP-IPv4 Neighbors for AS(13)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.36.1 Vl36 11 00:48:26 1 300 0 6751
2 172.28.6.130 Gi1/0/4 12 2d00h 1 200 0 981
0 192.168.36.3 Vl36 14 2d00h 6 300 0 625
Routing Protocol is "eigrp 13"
Outgoing update filter list for all interfaces is not set
GigabitEthernet1/0/1 filtered by PJM_ODEC, default is PJM_ODEC
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
Redistributing: eigrp 13
EIGRP-IPv4 Protocol for AS(13)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 192.168.38.5
Stub, connected
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
172.16.69.0/24
172.28.6.136/32
172.28.6.128/28
172.28.0.0
192.168.36.0
192.168.38.0
206.223.104.0/25
206.223.104.128/25
Routing Information Sources:
Gateway Distance Last Update
(this router) 90 02:20:31
172.28.6.130 90 00:51:12
192.168.36.1 90 00:51:11
192.168.36.3 90 00:51:14
Distance: internal 90 external 170
LOWANSWT#sho ip prot
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 13"
Outgoing update filter list for all interfaces is not set
GigabitEthernet1/0/1 filtered by PJM_ODEC, default is PJM_ODEC
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
Redistributing: eigrp 13
EIGRP-IPv4 Protocol for AS(13)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 192.168.38.5
Stub, connected
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
04-19-2012 01:39 PM
Yes this is the issue , it must be 'real' and present in the Rt in order to advertise it.
Regarding the real network statments that you have to publish could you tell me which ones are ? Are they on the routing table ?
Dan
04-19-2012 01:53 PM
Sure thing. Here is the EIGRP off of the WAN switch...
router eigrp 13
distribute-list PJM_ODEC out GigabitEthernet1/0/1
network 172.16.69.0 0.0.0.255
network 172.28.0.0
network 172.28.6.128 0.0.0.15
network 172.28.6.136 0.0.0.0
network 192.168.36.0
network 192.168.38.0
network 206.223.104.0 0.0.0.127
network 206.223.104.128 0.0.0.127
neighbor 172.28.6.130 GigabitEthernet1/0/4
passive-interface Vlan101
eigrp stub connected
the networks i want advertised from the WAN switch to the MPLS router are the 206 networks that you see. The MPLS router (sorry the 3845) already knows of the routes from another Primary BGP path. We need for this to be the backup (Feasible Successor) path.
They are in the routing table:
LOWANSWT#sho ip route 206.223.104.0
Routing entry for 206.223.104.0/24, 2 known subnets
Variably subnetted with 2 masks
D EX 206.223.104.0/26
[170/10258432] via 172.28.6.130, 2d01h, GigabitEthernet1/0/4
D EX 206.223.104.128/25
[170/10258432] via 172.28.6.130, 2d01h, GigabitEthernet1/0/4
but they are in the table because the business Partner is advertising them to us (6.130 address is our BP router). Once again, can I not advertise routes that are not connected to the router? Is this me needing to redistribute the routes from the neighbor rather than including them in network statements?
Thanks again Dan
04-19-2012 01:51 PM
What license level do you have for the 3750? IPbase only permits STUB routing. You'll need the IP services license for full fledged EIGRP.
04-19-2012 01:56 PM
Hi Robert,
Routing Protocol is "eigrp 13"
Stub, connected
Having stub will not stop you advertising conncted subnets.
Kevin tried to advertise something that did not exist in the routing table.
Dan
04-24-2012 09:11 AM
Dan
I wanted to circle back with you on this as I did not get any response from the last individual whom had kinda jumped in the middle.
Am I correct then to assume that a route must be in the routing table of a router to be advertised?
Thanks
Kevin
04-24-2012 11:58 AM
Hi Kevin ,
Yes in order to be advertised, first of all you have to have it on the routing table.
In your particular setup , the EIGRP is configured as STUB , this means the it cannot be a transit router - although we can improvise and make it work, I think, but this depends on your setup.
As you see "eigrp stub connected" : this means that the EIGRP is a stub and cannot advertise only connected routes.
Can you discribe your issue and also your setup ? Where does this equipment stands in your topology.
Regards
Dan
04-25-2012 06:11 AM
Can you discribe your issue and also your setup ? Where does this equipment stands in your topology.
Dan here is the situation.
The client I am working at has a HQ building and a Disaster Recovery building. The client connects to a Business Partner at each location thru a router and a WAN connection. Their onsite router at each of the two respective locations then connects in to us on one of our switches. The switches are 3750 boxes.
The WAN connection at the HQ location is our Primary Path.
The Business Partner advertises their networks to us in an EIGRP process on their router. I see the advertised routes on our switches in each location from the BP.
What we need is each switch to then re-advertise the learned routes to its other neighbors, the main one of which is our MPLS routers which connect the HQ site to the DR site. For whatever reason, the routes from the switches need to be advertised to the MPLS routers, which would in turn tell each other of the alternate route to the BP, subsequently when I look at the EIGRP topology table on each of our MPLS routers or switches, I should see 1 successor route and then the feasable successor route which would work for us assuming we lost the primary circuit.
What is not happening is our switches which connect to the BP get the routes from the BP, but do not advertise the routes to their MPLS neighbor routers, which we need for them to do.
Here is the configuration with respect to EIGRP on the HQ switch:
router eigrp 13
network 172.27.6.128 0.0.0.15
network 192.168.15.0
network 206.223.104.0
network 206.223.105.0
neighbor 172.27.6.130 GigabitEthernet3/0/15
distribute-list EIGRP_OUT out GigabitEthernet3/0/15
distribute-list route-map eigrp-rm out
distribute-list eigrp in
no auto-summary
Here is the configuration with respect to EIGRP on the HQ switch:
router eigrp 13
distribute-list PJM_ODEC out GigabitEthernet1/0/1
network 172.28.0.0
network 172.28.6.128 0.0.0.15
network 172.28.6.136 0.0.0.0
network 192.168.36.0
network 192.168.38.0
network 206.223.104.0 0.0.0.127
network 206.223.104.128 0.0.0.127
network 206.223.105.0
network 206.223.105.0 0.0.0.127
neighbor 172.28.6.130 GigabitEthernet1/0/4
passive-interface Vlan101
eigrp stub connected
Here is a list of the networks being advertised to us from the BP at the HQ switch:
206.223.104.0/24 is variably subnetted, 2 subnets, 2 masks
D EX 206.223.104.0/26
[170/53760] via 172.27.6.130, 1w4d, GigabitEthernet3/0/15
D EX 206.223.104.128/25
[170/53760] via 172.27.6.130, 1w4d, GigabitEthernet3/0/15
the 172.27.6.130 address is the BP router.
Here is a list of the networks being advertised to us from the BP at the DR locaiton:
206.223.104.0/24 is variably subnetted, 2 subnets, 2 masks
D EX 206.223.104.0/26
[170/10258432] via 172.28.6.130, 1w0d, GigabitEthernet1/0/4
D EX 206.223.104.128/25
[170/10258432] via 172.28.6.130, 1w0d, GigabitEthernet1/0/4
That being said, the MPLS routers which are neighbors to each of these do not have these networks in their routing tables.
Thanks again for any help on this that you can provide.
04-25-2012 02:50 PM
Kevin ,
Personaly I will go for the upgrade, meaning full EIGRP.
As a workaround you can use :
1) eigrp leak-map , will permit you forward required prefixes even though you are stub
ip prefix-list EIGRP-LEAK permit 206.223.104.0/26
ip prefix-list EIGRP-LEAK permit 206.223.104.128/25
!
route-map EIGRP-LEAK
match ip address prefix EIGRP-LEAK
!
router eigrp 13
eigrp stub connected leak-map EIGRP-LEAK
2) "eigrp stub connected summary" , and create on the interface toward the MPLS routers ( if i understood well )
for example Gi1/0/1 is the interface toward the MPLS routes
int gi1/0/1
ip summary-address eigrp 13 206.223.104.0 255.255.255.0
more specific prefixes will be learned from the main site , the summary will be learned from the DRC
The minus here is that you have to do manual summarization carfully, for every prefix that is in transit.
By the way you do not have to add "network" commands for those prefixes that are in "transit".
The network command is only for those prefixes that are advertise to the EIGRP domain by the local router.
Regards
Dan
04-26-2012 06:29 AM
I am a little wary of using the
"ip summary-address eigrp " statement on the interface. you had indicated that
"you have to do manual summarization carfully, for every prefix that is in transit."
I wanted to talk more about that specific statement. Are you saying that I would have to summarize more routes than just the 206.223.104.0/26 and the 206.223.104.128/25 networks on that interface. if that is the case, there are lots of networks that traverse that interface including all the production networks at the DR site.
I am not sure if I have musunderstood the statement or not. I dont mind putting the statement on the interface if I only have to do it for the networks in question.
Thanks Dan
04-26-2012 12:11 PM
Hi Kevin ,
I made a quick image with my understanding of your topology. Please correct me .
Dan
04-26-2012 01:30 PM
Here is a diagram for you Dan. Hope this will help. Thanks for all of your hard work on this.
Kevin
04-27-2012 02:55 AM
Hi Kevin ,
If I understood well you have the same issue on both switches (both of them have IP Base) ? Or just the one on the DRC.
I suppose that the client is located in the MPLS cloud. Please correct me if I'm wrong.
Dan
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide