help with an eigrp "stub" statement

Answered Question
Dec 8th, 2011

Forum

This morning a client has asked me to assist them in attempting to redesign the way a redundant path to a Business Partner is working. 


The client has a HQ site in location A, and a DR site in Location B.  There is a server in Location A (Primary Server) and a server in Location B (Secondary).   These sites are connected together via a MPLS link.

There is a WAN connection to the Business Partner in Location A, as well as a WAN connection to the Business Partner in Location B. 

The current configuration works so that both the Primary server in A as well as the Secondary server in B use the WAN connection in A to connect to the Partner.  Unfortunantly in the current config, it seems that the Secondary server in B cannot connect to the Business partner over the WAN connection to the Partner in Location B.

I am seeing on the WAN routers at the client that they are getting EIGRP updates from the client in both locaitons.  I think that both WAN connections are T1's even though they are from AT&T (Location A) and Verizon (Location B). 

The client has asked me to make recommendations for how to configure so that the Primary server in Location A will have a preference for the WAN connection to the BP in Location A, but would also be able to use the connection in Locaton B if the WAN in Loc. A went down.

Likewise, they want the Secondary in Location B to have a preference and be able to communicate to the BP via the WAN in Locaiton B, but in the event that it fails, that the Secondary server in Loc. B could use the WAN in Loc.A to communicate back to the BP.

I would think that if the BP is advertising his networks to us, that EIGRP would know which one to use.  Here are the EIGRP statements from Loc.A and Loc. B:

Loc.A

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

Loc. B

router eigrp 13

network 172.28.6.128 0.0.0.15

network 192.168.36.0

network 192.168.38.0

network 206.223.104.0

network 206.223.105.0

neighbor 172.28.6.130 GigabitEthernet1/0/4

passive-interface Vlan101

eigrp stub connected summary

The 172.27 and 172.28 networks respectively are the networks that connect my client to the BP.  The destination networks at the client site are the

206.223. networks.

I am curious about the "eigrp stub connected summary" statement in Location B, and if this may be why EIGRP does not think that it should send data to the 206.223. networks via its own G1/0/4 interface to the BP.

Thanks for any help on this issue.

Kevin

I have this problem too.
0 votes
Correct Answer by Jon Marshall about 2 years 4 months ago

Kevin

Here are the change recommendations that I am currently considering publishing to the client.  Please confirm Jon:

1.   We do not need to have the 206.223 networks in our Router eigrp 13 statements.  This is because "the  BP" advertises these to us.

2.    We may not want the EIGRP "stub" statement on the EIGRP config on the DR side.

3.    We may want to add the "no auto-summ" statement on the DR side so that we ensure that 'classless" BP networks are correctly advertised.

let me know if you see anything else I should explicitly recommend to the client.

1) Yes, i can't see why these are needed and if there are no interfaces on the HQ/DR routers using these IPs then they are not being used by EIGRP either.

2) If you want to have HQ A use DR B if HQ lose their connection to the BP site A then you will need to remove the eigrp stub config because otherwise DR B will not advertise the 206.223.x.x networks to HQ A.

A word of warning here - it's always best to assume that the config is there for a reason. Removing eigrp stub may mean that other subnets are then advertised to HQ and you may find that routing for other subnets then takes different paths. I suspect this may be there because they don't want DR advertising any HQ learned routes out of any WAN links it has. Now you obviously need to advertise the HQ server subnet out of DR for failover but be careful of any other networks that may also be advertised. It's tricky to say without knowing the full setup but you may find that all of sudden traffic starts using DR and not HQ even if HQ is up. So this does need a bit of investigation.

3)  Yes you need to enable no auto-summary but again as above you need to be careful.

What you may have to do is use a route-map/distribute-list at DR under the eigrp config to only advertise out those networks you want to such as the server subnet in HQ. Sorry to be vague but you do need to be aware of the rest of the routing.

As for the BP. It looks like they are not advertising their 206.223.x.x networks as /24s but are advertising smaller subnets. So you need to see exactly what they are advertising and just as importantly how they are interconnected because in effect you are trying to emulate at their site what you want at yours ie.

HQ A = BP A  and DR B --> BP B under normal circumstances but then each can use the other as failover.

Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 3.8 (8 ratings)
JohnTylerPearce Thu, 12/08/2011 - 09:24

We'll I noticed that Loc B under the router eigrp 13 configuration, I don't see 'no auto-summary', so I'm not sure if that's on purpose or not. If it goes over discontigous networks it's going to advertise the classful summary address. If it has the

'eigrp stub connected summary' cmd configured it's only going to advertise the connected and summary routes to all eigrp neighbors. What networks is the server on in Lock B and is it that network a connectd or summary route?

k-melton Thu, 12/08/2011 - 09:47


Thanks for your response, JTP.

The Secondary server in Loc. B is not on a directly connected network.  He resides on the 172.28 network, which is behind the clients FW (actually the real network ID behind the FW is 192.168.103.0/24, which is then NAT'd to 172.28).

I see where you are going with this, and appreciate your input!  Good catch!

Jon Marshall Thu, 12/08/2011 - 09:53

Kevin

In addition to John's post -

the configs you posted, are they from HQ and DR routers. If so why do they multiple 206.223.x.x entries. I would have expected each router to only have one entry ie. the subnet of the P2P link unless the BP is not advertising their networks to you ?

Is the BP running EIGRP on their routers or not ?

As John says, we need to know the IPs of server A and server B.  We also need to know -

1) the routing table entries on both HQ and DR routes for the BP networks

2) the routing table entries on the BP routers at the BP site A and B for the server addresses

Jon

JohnTylerPearce Thu, 12/08/2011 - 09:56

Jon, good catch as well with the 206.223.x.x entries. Unless they are not advertising these to each other, then I don't see why they would need to be there.

k-melton Thu, 12/08/2011 - 10:56

Jon

Thanks for your input as well on this.  Always welcome.

The BP to the best of my knowledge IS advertising their networks to us.  As for the multiple entries, I would have to ask the client if this is just an oversight.  Do we need these entries at all on our AS eigrp config if I find out definitively that the BP is advertising them to us. 

I am wondering if at least 1 network statement needs to be there, since the EIGRP AS talks to other "client" networks, not just the BP network.  Perhaps this is done so that Primary and Secondary both have a backup route to the BP in the event of a failure of etiher WAN?

Location A config is the HQ config; Loc.B is the DR config. 

The Primary server in Loc. A is at 172.27.6.133

The Secondary server in Loc.B is at 172.28.6.133

Routing table entries for the client are as follows:

Router @ loc. A:

GADMZSWT01#sho ip route 206.223.104.0
Routing entry for 206.223.104.0/24, 2 known subnets
  Variably subnetted with 2 masks
  Redistributing via eigrp 13

D EX    206.223.104.0/26
           [170/53760] via 172.27.6.130, 7w0d, GigabitEthernet3/0/15
D EX    206.223.104.128/25
           [170/53760] via 172.27.6.130, 7w0d, GigabitEthernet3/0/15


GADMZSWT01#sho ip route 206.223.105.0
Routing entry for 206.223.105.0/24, 1 known subnets
  Redistributing via eigrp 13

D EX    206.223.105.0
           [170/53760] via 172.27.6.130, 7w0d, GigabitEthernet3/0/15

*********the 172.27.6.130 is actually the BP router, which I do not have access to*******************

Router @ loc. B:

LOWANSWT#sho ip route 206.223.104.0
Routing entry for 206.223.104.0/24, 2 known subnets
  Variably subnetted with 2 masks
  Redistributing via eigrp 13

D EX    206.223.104.0/26 [170/858624] via 192.168.36.3, 3w2d, Vlan36
D EX    206.223.104.128/25
           [170/10511872] via 172.28.6.130, 3w2d, GigabitEthernet1/0/4
LOWANSWT#sho ip route 206.223.105.0
Routing entry for 206.223.105.0/24
  Known via "eigrp 13", distance 170, metric 858624
  Tag 7018, type external
  Redistributing via eigrp 13
  Last update from 192.168.36.3 on Vlan36, 3w2d ago
  Routing Descriptor Blocks:
  * 192.168.36.3, from 192.168.36.3, 3w2d ago, via Vlan36
      Route metric is 858624, traffic share count is 1
      Total delay is 210 microseconds, minimum bandwidth is 3000 Kbit
      Reliability 100/255, minimum MTU 1500 bytes
      Loading 255/255, Hops 1
      Route tag 7018

***This one is more interesting, as you can see that at least for the 206.223.104 net, he knows about a D EX    206.223.104.0/26 [170/858624] via 192.168.36.3(this 36.3 is from the MPLS link, and would take it back to the HQ site to connect.  he also knows about

D EX    206.223.104.128/25

           [170/10511872] via 172.28.6.130, 3w2d, GigabitEthernet1/0/4  which is the advertisement from the BP..

JohnTylerPearce Thu, 12/08/2011 - 11:12

The BP to the best of my knowledge IS advertising their networks to us

As for the multiple entries, I would have to ask the client if this

is just an oversight.  Do we need these entries at all on our AS.

You don't need to advertise these yourself, since they are routes from the

BP. They will be automatically advertised as D EX (External EIGRP) routes

through normal EIGRP advertising within the same EIGRP AS. You obviously

need these to have a route back, other wise bidrectional communication will

not happen. Of course this is done via route redistribution from the BP.

    

Jon Marshall Thu, 12/08/2011 - 11:14

Kevin

D EX    206.223.104.0/26 [170/858624] via 192.168.36.3, 3w2d, Vlan36

D EX    206.223.104.128/25

           [170/10511872] via 172.28.6.130, 3w2d, GigabitEthernet1/0/4

So i'm assuming 172.28.6.130 from the above is the other end of the P2P link to BP site B ?

If so, in theory if the BP connected from a 206.223.104.128 -> 254 client it should be returned via the P2P link. But if it is from a 206.223.104.1 -> 62 client it will be sent via the MPLS link.

But which link the BP uses we can't say without seeing the BP routing tables.

The general question about whether you need these networks is it depends. If the BP is using EIGRP as well then you only need the P2P link subnet in your router config (and they need it on theirs). Then they should advertise their networks from their router and you should advertise your networks from your routers.

Do you have interfaces on either HQ A or DR B routers that have a 206.223.x.x address. If so can you post what they are and what subnet mask they have.

Also, although this may be the same infomation as above, what is the addressing used on the T1 P2P link on both HQ and DR. From the looks of the routing output it is 172.27.6.x at HQ and 172.28.6.x at DR but if you could just confirm.

Jon

k-melton Thu, 12/08/2011 - 11:48

So i'm assuming 172.28.6.130 from the above is the other end of the P2P link to BP site B ?  

Yes Jon that is a correct assumption.

Do you have interfaces on either HQ A or DR B routers that have a 206.223.x.x address. If so can you post what they are and what subnet mask they have.

No sir. The shared Network address space on A is the 172.27 and on B is the 172.28.  The 206.223. addresses are all on their side.

Also, although this may be the same infomation as above, what is the addressing used on the T1 P2P link on both HQ and DR. From the looks of the routing output it is 172.27.6.x at HQ and 172.28.6.x at DR but if you could just confirm.

Confirmed

Jon Marshall Thu, 12/08/2011 - 12:11

If you don't have any interfaces on your routers with those addresses then they are not really needed and i'm not sure why they are there. As always you need to understand why they are there before removing.

Back to the case in point.

HQ - 172.27.6.128/28 is advertised to the remote BP site A. This also covers the server 172.27.6.133. Is the P2P link addressing used out of this subnet as well ?

DR - 172.28.6.128/28 is advertised to the remote BP site B. This also covers the server 172.28.6.133. Is the P2P link addressing used of this subnet as well ?

So HQ WAN connection is used to get to the BP but are you sure the BP when replying to DR server goes down the HQ WAN connection ? I ask because the BP should get a much better advertisement for the DR server via the DR to site B P2P link.

What is not clear is what is happening at the BP end. How are their site A and B connected. How are their routers configured, not only to their respective HQ and DR routers but also between each other.

Without a full understanding of the topology it's not really possible to say why things are routing as they are.

Jon

k-melton Thu, 12/08/2011 - 12:58

Jon

HQ - 172.27.6.128/28 is advertised to the remote BP site A. This also covers the server 172.27.6.133. Is the P2P link addressing used out of this subnet as well ?

Yes they are.  Client GW adx is 172.27.6.136 and the BP GW is 172.27..6.130.

DR - 172.28.6.128/28 is advertised to the remote BP site B. This also covers the server 172.28.6.133. Is the P2P link addressing used of this subnet as well ?

Yes.  Client GW adx 172.28.6.130 and the BP GW is 172.28.6.130

So HQ WAN connection is used to get to the BP but are you sure the BP when replying to DR server goes down the HQ WAN connection ? I ask because the BP should get a much better advertisement for the DR server via the DR to site B P2P link.

Currently it is my understanding from the client that they communicate to the BP thru the AT&T link on HQ side, but return traffic from the BP comes back to us via the DR side.  this is one of the items that I have to make change recommendations for.

Here are the change recommendations that I am currently considering publishing to the client.  Please confirm Jon:

1.   We do not need to have the 206.223 networks in our Router eigrp 13 statements.  This is because "the  BP" advertises these to us.

2.    We may not want the EIGRP "stub" statement on the EIGRP config on the DR side.

3.    We may want to add the "no auto-summ" statement on the DR side so that we ensure that 'classless" BP networks are correctly advertised.

let me know if you see anything else I should explicitly recommend to the client.

Scotch on the way Jon!

Correct Answer
Jon Marshall Thu, 12/08/2011 - 16:06

Kevin

Here are the change recommendations that I am currently considering publishing to the client.  Please confirm Jon:

1.   We do not need to have the 206.223 networks in our Router eigrp 13 statements.  This is because "the  BP" advertises these to us.

2.    We may not want the EIGRP "stub" statement on the EIGRP config on the DR side.

3.    We may want to add the "no auto-summ" statement on the DR side so that we ensure that 'classless" BP networks are correctly advertised.

let me know if you see anything else I should explicitly recommend to the client.

1) Yes, i can't see why these are needed and if there are no interfaces on the HQ/DR routers using these IPs then they are not being used by EIGRP either.

2) If you want to have HQ A use DR B if HQ lose their connection to the BP site A then you will need to remove the eigrp stub config because otherwise DR B will not advertise the 206.223.x.x networks to HQ A.

A word of warning here - it's always best to assume that the config is there for a reason. Removing eigrp stub may mean that other subnets are then advertised to HQ and you may find that routing for other subnets then takes different paths. I suspect this may be there because they don't want DR advertising any HQ learned routes out of any WAN links it has. Now you obviously need to advertise the HQ server subnet out of DR for failover but be careful of any other networks that may also be advertised. It's tricky to say without knowing the full setup but you may find that all of sudden traffic starts using DR and not HQ even if HQ is up. So this does need a bit of investigation.

3)  Yes you need to enable no auto-summary but again as above you need to be careful.

What you may have to do is use a route-map/distribute-list at DR under the eigrp config to only advertise out those networks you want to such as the server subnet in HQ. Sorry to be vague but you do need to be aware of the rest of the routing.

As for the BP. It looks like they are not advertising their 206.223.x.x networks as /24s but are advertising smaller subnets. So you need to see exactly what they are advertising and just as importantly how they are interconnected because in effect you are trying to emulate at their site what you want at yours ie.

HQ A = BP A  and DR B --> BP B under normal circumstances but then each can use the other as failover.

Jon

k-melton Tue, 12/13/2011 - 11:39

I have received information from the BP at this point.  Following are eigrp topologies from the BP routers connected to  Locations A & B:

Router To Location A (HQ)

BP_router_to_HQ>sh ip eigrp topology
IP-EIGRP Topology Table for AS(13)/ID(10.134.128.53)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 172.27.6.128/28, 1 successors, FD is 28160
        via Connected, FastEthernet0/0
P 172.28.6.128/28, 0 successors, FD is Inaccessible
        via 172.27.6.136 (5266688/5264128), FastEthernet0/0
P 206.223.105.0/24, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)
P 206.223.104.0/26, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)
P 206.223.104.128/25, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)

Router To Location B (DR)

BP_router_to_DR>sh ip eigrp topology
IP-EIGRP Topology Table for AS(13)/ID(10.134.128.53)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 172.27.6.128/28, 1 successors, FD is 28160
        via Connected, FastEthernet0/0
P 172.28.6.128/28, 0 successors, FD is Inaccessible
        via 172.27.6.136 (5266688/5264128), FastEthernet0/0
P 206.223.105.0/24, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)
P 206.223.104.0/26, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)
P 206.223.104.128/25, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)

It is interesing to me that the Eigrp topology on the BP router to HQ has no feasable successors to the DR network.  Is this because of the "stub" statement we discussed on the DR client router?

Also there is a static route on each of the BP routers that is telling each respective router how to get to the other networks. These static routes are being advertised into BGP and redistributed via the WAN on each side.

Here is the static data for HQ to see the DR side:

BP_router_to_HQ>sh ip route 172.28.6.133

Routing entry for 172.28.6.128/28

  Known via "static", distance 1, metric 0

  Redistributing via bgp 64589

  Advertised by bgp 64589

  Routing Descriptor Blocks:

  * 172.27.6.136

      Route metric is 0, traffic share count is 1

The static route on the BP HQ router is:

ip route 172.28.6.128 255.255.255.240 172.127.6.136

Here is the static data for DR to see the HQ side:

BP_router_to_DR>sh ip route 172.27.6.133

Routing entry for 172.27.6.128/28

  Known via "static", distance 1, metric 0

  Redistributing via bgp 5081

  Advertised by bgp 5081

  Routing Descriptor Blocks:

  * 172.28.6.136

      Route metric is 0, traffic share count is 1

The static route on the BP DR router is:

ip route 172.27.6.128 255.255.255.240 172.28.6.136

We will be working with the BP and will be able to make recommendations to them as well.  I am a little surprised by the static statments. Dont those take a priority in a routing table, and do they even need to be there?

Thanks Jon

k-melton Tue, 12/13/2011 - 11:39

I have received information from the BP at this point.  Following are eigrp topologies from the BP routers connected to  Locations A & B:

Router To Location A (HQ)

BP_router_to_HQ>sh ip eigrp topology
IP-EIGRP Topology Table for AS(13)/ID(10.134.128.53)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 172.27.6.128/28, 1 successors, FD is 28160
        via Connected, FastEthernet0/0
P 172.28.6.128/28, 0 successors, FD is Inaccessible
        via 172.27.6.136 (5266688/5264128), FastEthernet0/0
P 206.223.105.0/24, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)
P 206.223.104.0/26, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)
P 206.223.104.128/25, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)

Router To Location B (DR)

BP_router_to_DR>sh ip eigrp topology
IP-EIGRP Topology Table for AS(13)/ID(10.134.128.53)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 172.27.6.128/28, 1 successors, FD is 28160
        via Connected, FastEthernet0/0
P 172.28.6.128/28, 0 successors, FD is Inaccessible
        via 172.27.6.136 (5266688/5264128), FastEthernet0/0
P 206.223.105.0/24, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)
P 206.223.104.0/26, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)
P 206.223.104.128/25, 1 successors, FD is 51200, tag is 13979
        via Redistributed (51200/0)

It is interesing to me that the Eigrp topology on the BP router to HQ has no feasable successors to the DR network.  Is this because of the "stub" statement we discussed on the DR client router?

Also there is a static route on each of the BP routers that is telling each respective router how to get to the other networks. These static routes are being advertised into BGP and redistributed via the WAN on each side.

Here is the static data for HQ to see the DR side:

BP_router_to_HQ>sh ip route 172.28.6.133

Routing entry for 172.28.6.128/28

  Known via "static", distance 1, metric 0

  Redistributing via bgp 64589

  Advertised by bgp 64589

  Routing Descriptor Blocks:

  * 172.27.6.136

      Route metric is 0, traffic share count is 1

The static route on the BP HQ router is:

ip route 172.28.6.128 255.255.255.240 172.127.6.136

Here is the static data for DR to see the HQ side:

BP_router_to_DR>sh ip route 172.27.6.133

Routing entry for 172.27.6.128/28

  Known via "static", distance 1, metric 0

  Redistributing via bgp 5081

  Advertised by bgp 5081

  Routing Descriptor Blocks:

  * 172.28.6.136

      Route metric is 0, traffic share count is 1

The static route on the BP DR router is:

ip route 172.27.6.128 255.255.255.240 172.28.6.136

We will be working with the BP and will be able to make recommendations to them as well.  I am a little surprised by the static statments. Dont those take a priority in a routing table, and do they even need to be there?

Thanks Jon

k-melton Thu, 12/08/2011 - 13:05

I sent some questions to the BP rep earlier today, but thus far have not gotten a response. 

k-melton Tue, 04/24/2012 - 09:55

JTP

I did not want to leave this as un- answered.  We never heard back from the BP.  We are moving forward on this now without imput from the BP.

I appreciate the answers and interest that yourself and Jon put into this.

I hope you are well.

Actions

Login or Register to take actions

This Discussion

Posted December 8, 2011 at 8:49 AM
Stats:
Replies:17 Avg. Rating:3.75
Views:729 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard