Pages

CCNP ROUTE - EIGRP Frame Relay LAB part 2

go to part 1


4) Take a closer look at Branch1/2 routing tables.
BRANCH-1#sh ip route 10.1.2.0
% Subnet not in table

BRANCH-1#sh ip route eigrp
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D        10.0.0.0/24 [90/2195456] via 193.10.26.1, 00:12:05, Serial1/0.2
                     [90/2195456] via 193.10.25.1, 00:12:05, Serial1/0.1
D        10.1.3.0/24 [90/2809856] via 193.10.26.1, 00:12:05, Serial1/0.2
                     [90/2809856] via 193.10.25.1, 00:12:05, Serial1/0.1
      193.10.24.0/30 is subnetted, 2 subnets
D        193.10.24.0 [90/2681856] via 193.10.25.1, 00:12:05, Serial1/0.1
D        193.10.24.4 [90/2681856] via 193.10.26.1, 00:12:05, Serial1/0.2

BRANCH-1#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(15)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   193.10.25.1             Se1/0.1                 137 00:50:32   31   186  0  123
0   193.10.26.1             Se1/0.2                 131 01:07:37   30   180  0  104 
Why both know routes to Branch3 but not for each other? (it's a normal behavior at this time ...why? ).
Configure interface S1/0.1 on each WAN router so that EIGRP will advertise Branch1 route to Branch 2 .. and Branch2 route to Branch 1. 
Split horizon is enabled by default on Frame Relay multipoint subinterfaces, which prevent routing updates from being retransmitted on the same interface on which they were received.

So EIGRP split horizon need to be disabled on the multipoint subinterface of WAN1 and WAN2 with the no ip split-horizon eigrp 15 command.
WAN1(config-subif)#no ip split-horizon eigrp 15
*Nov  5 14:29:18.117: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.25.10 (Serial1/0.1) is resync: split horizon changed
BRANCH-2#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(15)/ID(10.1.2.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
...
P 10.1.1.0/24, 1 successors, FD is 2809856
        via 193.10.25.1 (2809856/2297856), Serial1/0.1
Network 10.1.1.0/24 is visible only through WAN1.
Disable split-horizon on WAN2 Serial1/0.1 multipoint interface:
WAN2(config-subif)#interface Serial1/0.1 multipoint
WAN2(config-subif)#no ip split-horizon eigrp  15
*Nov  5 16:04:55.429: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.20 (Serial1/0.1) is resync: split horizon changed
*Nov  5 16:04:55.429: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.10 (Serial1/0.1) is resync: split horizon changed
After that:
BRANCH-2#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(15)/ID(10.1.2.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
...
P 10.1.1.0/24, 2 successors, FD is 2809856
        via 193.10.25.1 (2809856/2297856), Serial1/0.1
        via 193.10.26.1 (2809856/2297856), Serial1/0.2
5) At this point all routing tables should be correct and complete. It's time to tune EIGRP Neighborships a bit.
     a) Set Hello timer between Wan1/Wan2/Core1/Core2 routers to 2 sec for EIGRP asn 15
     b) Set Hold timer between Wan1/Wan2/Core1/Core2 routers to 6 sec for EIGRP asn 15
     c) Add EIGRP Authentification between branch routers and WAN routers, they should all use the Key-chain EIGRPLAB which should include Key 1 set as "PassWord" (without the "" ).
     d) Prevents EIGRP from sending messages where it's not needed (Do branches LAN need to receive EIGRP Hellos ?).
     e) Let's reduce overhead on FrameRelay link between Wan1 and Branch1 ... configure static neighborship between those routers
     f) !!! Doh !!! Neighborship between Branch2 and Wan1 went down ! ... Let's correct that and define static neighborship too.
     g) Finally, let's define EIGRP Router ID:
        - Core1: 1.0.0.0, Core2: 2.0.0.0, Wan1: 0.1.0.0, Wan2: 0.2.0.0, Branch1: 0.0.1.0, Branch2: 0.0.2.0 and Branch3: 0.0.3.0

a,b) Default values of the EIGRP hello timer and the EIGRP hold timer are:
- 5/15 sec, on LAN (>T1) and point-to-point physical links,
- 60/180 sec, on WAN (<=T1).
Core1(config)#interface Ethernet0/0
Core1(config-if)#ip hello-interval eigrp 15 2
Core1(config-if)#ip hold-time eigrp 15 6

Core2#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(15)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
2   10.0.0.10               Et0/0                    11 04:41:11    2   100  0  162
1   10.0.0.20               Et0/0                    13 04:58:37    5   100  0  133
0   10.0.0.1                Et0/0                     5 04:59:52    1   100  0  63

Configure on WAN1, WAN2, CORE1, CORE2
interface Ethernet0/0
ip hello-interval eigrp 15 2
ip hold-time eigrp 15 6
c) Add EIGRP Authentification between branch routers and WAN routers, they should all use the Key-chain EIGRPLAB which should include Key 1 set as "PassWord" (without the "" )

WAN1#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(15)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
5   193.10.25.20            Se1/0.1                 130 00:42:56   24   144  0  76
4   193.10.25.10            Se1/0.1                 171 00:44:12   21   126  0  84
3   10.0.0.2                Et0/0                     5 04:46:46    4   100  0  63
2   10.0.0.20               Et0/0                     4 04:46:46    5   100  0  133
1   10.0.0.1                Et0/0                     5 04:46:46    4   100  0  63
0   193.10.24.2             Se1/0.2                  13 04:57:11   18   108  0  78

Configure on WAN1
key chain EIGRPLAB
 key 1
 key-string PassWord
!
interface Serial1/0.1
 ip authentication mode eigrp 15 md5
 ip authentication key-chain eigrp 15 EIGRPLAB
!
interface Serial1/0.2
 ip authentication mode eigrp 15 md5
 ip authentication key-chain eigrp 15 EIGRPLAB
!
*Nov  5 16:34:08.278: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.25.20 (Serial1/0.1) is down: authentication mode changed
*Nov  5 16:34:08.278: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.25.10 (Serial1/0.1) is down: authentication mode changed
*Nov  5 16:34:08.286: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.24.2 (Serial1/0.2) is down: authentication mode changed
All neighbors from interfaces with authentication went down
WAN1#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(15)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
3   10.0.0.2                Et0/0                     4 04:47:15    5   100  0  64
2   10.0.0.20               Et0/0                     4 04:47:15    5   100  0  139
1   10.0.0.1                Et0/0                     4 04:47:15    5   100  0  64

Configure the same on WAN2and BRANCHes

On Branch-1:
BRANCH-1(config)# do sh ip ei nei
EIGRP-IPv4 Neighbors for AS(15)

...after config
*Nov  5 16:40:01.571: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.1 (Serial1/0.2) is up: new adjacency
*Nov  5 16:40:22.477: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.25.1 (Serial1/0.1) is up: new adjacency
BRANCH-1(config-subif)#do sh ip ei nei
EIGRP-IPv4 Neighbors for AS(15)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   193.10.25.1             Se1/0.1                 160 00:00:19   29   174  0  173
0   193.10.26.1             Se1/0.2                 160 00:00:40   21   126  0  145
d) Prevents EIGRP from sending messages where it's not needed (Do branches LAN need to receive EIGRP Hellos ?).
Instead using BRANCH LAN, interface Loopback are used.
So it is asked to make them EIGRP passive. Something like this:
BRANCH-1(config)#router eigrp 15
BRANCH-1(config-router)#passive-interface Loopback0

e,f ) For Multipoint Network WAN1-BR1-BR2 will configure unicast neighbors
BRANCH-1(config)#router eigrp 15
BRANCH-1(config-router)#neighbor 193.10.25.1 Serial1/0.1
BRANCH-2(config)#router eigrp 15
BRANCH-2(config-router)#neighbor 193.10.25.2 Serial1/0.1
WAN1(config)# router eigrp 15
WAN1(config-router)# neighbor 193.10.25.10 Serial1/0.1
WAN1(config-router)#  neighbor 193.10.25.20 Serial1/0.1
BRANCH-1(config)#router eigrp 15
BRANCH-1(config-router)#neighbor 193.10.26.1 Serial1/0.2
*Nov  5 16:50:35.965: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.1 (Serial1/0.2) is down: Static peer replaces multicast
BRANCH-2(config)#router eigrp 15
BRANCH-2(config-router)#neighbor 193.10.26.1 Serial1/0.2
*Nov  5 16:51:03.246: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.1 (Serial1/0.2) is down: Static peer configured
WAN2(config)# router eigrp 15
WAN2(config-router)#  neighbor 193.10.26.10 Serial1/0.1
WAN2(config-router)#  neighbor 193.10.26.20 Serial1/0.1

*Nov  5 16:51:35.209: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.10 (Serial1/0.1) is up: new adjacency
*Nov  5 16:53:23.059: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.20 (Serial1/0.1) is up: new adjacency
WAN2(config-router)#do sh ip ei nei
EIGRP-IPv4 Neighbors for AS(15)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
4   193.10.26.20            Se1/0.1                 177 00:00:02   29   174  0  92
2   193.10.26.10            Se1/0.1                 177 00:01:50   16   100  0  107
3   193.10.24.6             Se1/0.2                  12 00:10:02   17   102  0  101
5   10.0.0.10               Et0/0                     5 05:06:10    5   100  0  189
1   10.0.0.2                Et0/0                     4 05:23:35    1   100  0  72
0   10.0.0.1                Et0/0                     4 05:23:35    6   100  0  72

WAN2#sh ip eigrp neighbors static
EIGRP-IPv4 Neighbors for AS(15)
Static Address          Interface
193.10.26.20            Serial1/0.1
193.10.26.10            Serial1/0.1

or use sh ip eigrp neighbors detail for details
g) Finally, let's define EIGRP Router ID
Core1: 1.0.0.0, Core2: 2.0.0.0, Wan1: 0.1.0.0, Wan2: 0.2.0.0,
Branch1: 0.0.1.0, Branch2: 0.0.2.0 and Branch3: 0.0.3.0

Core1(config)#router eigrp 15
Core1(config-router)# eigrp router-id 1.0.0.0
*Nov  6 12:02:43.937: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.10 (Ethernet0/0) is down: route configuration changed
*Nov  6 12:02:43.938: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.20 (Ethernet0/0) is down: route configuration changed
*Nov  6 12:02:43.939: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.2 (Ethernet0/0) is down: route configuration changed
*Nov  6 12:02:44.328: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.10 (Ethernet0/0) is up: new adjacency
*Nov  6 12:02:44.347: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.2 (Ethernet0/0) is up: new adjacency
*Nov  6 12:02:44.348: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.20 (Ethernet0/0) is up: new adjacency

Core2(config)#router eigrp 15
Core2(config-router)#eigrp router-id 2.0.0.0
WAN1(config)#router eigrp 15
WAN1(config-router)#eigrp router-id 0.1.0.0
WAN2(config)#router eigrp 15
WAN2(config-router)#eigrp router-id 0.2.0.0
BRANCH-1(config)#router eigrp 15
BRANCH-1(config-router)#eigrp router-id 0.0.1.0
BRANCH-2(config)#router eigrp 15
BRANCH-2(config-router)#eigrp router-id 0.0.2.0
BRANCH-3(config)#router eigrp 15
BRANCH-3(config-router)#eigrp router-id 0.0.3.0
6) Let's now work on topology and convergence
a) Wan1/2 have T1 physical connection. So the default bandwidth on s1/0 is correct but each subinterface should still have a bandwith configured.
Each PVC between a Branch and WAN1 has a CIR of 128kbps, and PVCs between Branch and Wan2 have a CIR of 64kbps.
So set the bandwidth on Branch1/2/3 int/subint and WAN subint to match that situation.

b) Now let's reduce the EIGRP bandwidth usage a bit. EIGRP should use 32kbps on each PVC.

c) Branch1/2/3 should not participate in the Query process in case of a neighborship failure and should only advertise connected routes.

d) Because of the different CIR between Branch / Wan ( 128kbps and 64kbp) some "bad" things happened on Wan2. Wan2 has a better route to Branches going through Wan1 than using its own PVC links. So Wan2 doesn't advertise any route to branches through frame-relay anymore. Instead Wan2 advertise routes to Branches passing through Wan1 !!!
So let's correct that... <<< On Wan1 >>>  (Please read the final note about the usage of that feature).
        - Create an Access list 1 matching 10.1.1.0 and 10.1.2.0
        - Add an offset-list to EIGRP 15 for incoming routes updates matching ACL 1 on interface s0/0.1
        - Create an ACL 2 matching 10.1.3.0
        - Add an offset-list to EIGRP 14 for incoming routes updates matching ACL 2 ont interface s0/0.2
          (The value of the offset should be a few units less than the difference between FD to the branch from Wan1 and from Wan2)
 Why threat incoming updates ? Routes to Branch1/2 have the same FD. But not the one to Branch3. One offset-list can be applied per interface so here we can set different offsets for Branch1/2 and Branch3. Working on outgoing interface wouldn't allow that. The aim is to make Wan1 report routes with Metric just a little bit smaller than the one reported by Wan2 so that Core1/2 will put them  all in their topology table ... Preventing them to enter the query process in case of a PVC failure or such.

e) Now we want Core1 and Core2 to have Wan2 as Feasible Successor for all branches. Set the Variance to 2.

a) Bandwidth Command
Wan1/2 have T1 physical connection. So the default bandwidth on s1/0 is correct but each subinterface should still have a bandwith configured.

Each PVC between a Branch and WAN1 has a CIR of 128kbps, and PVCs between Branch and Wan2 have a CIR of 64kbps.
So set the bandwidth on Branch1/2/3 int/subint and WAN subint to match that situation.

Before any changes, lets check routing table on CORE router:
Core1#sh ip route 
Gateway of last resort is not set
      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.0.0.0/24 is directly connected, Ethernet0/0
L        10.0.0.1/32 is directly connected, Ethernet0/0
D        10.1.1.0/24 [90/2323456] via 10.0.0.20, 00:00:01, Ethernet0/0
                     [90/2323456] via 10.0.0.10, 00:00:01, Ethernet0/0
D        10.1.2.0/24 [90/2323456] via 10.0.0.20, 00:00:01, Ethernet0/0
                     [90/2323456] via 10.0.0.10, 00:00:01, Ethernet0/0
D        10.1.3.0/24 [90/2323456] via 10.0.0.20, 5d02h, Ethernet0/0
                     [90/2323456] via 10.0.0.10, 5d02h, Ethernet0/0
      193.10.24.0/30 is subnetted, 2 subnets
D        193.10.24.0 [90/2195456] via 10.0.0.10, 5d03h, Ethernet0/0
D        193.10.24.4 [90/2195456] via 10.0.0.20, 5d03h, Ethernet0/0
D     193.10.25.0/24 [90/2195456] via 10.0.0.10, 00:00:11, Ethernet0/0
D     193.10.26.0/24 [90/2195456] via 10.0.0.20, 5d03h, Ethernet0/0

Routes on Branch loopbacks (10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24) are seen as equal cost.

From Official Guide:
■ Recommendation: Set the bandwidth of point-to-point links to the speed of the Committed Information Rate (CIR) of the single PVC on the subinterface.
■ General recommendation: Set the bandwidth of multipoint subinterfaces to around the total CIR for all VCs assigned to the subinterface.
■ Note that for multipoint subinterfaces, IOS WAN bandwidth control first divides the subinterface bandwidth by the number of configured PVCs and then determines the EIGRP percentage based on that number.
Lets change bandwidth values:
- WAN1 have CIR=128kbps on MultiPoint so Bandwidth will be 256 (2 PVC),
- as required only 32kbps to be used for max EIGRP traffic update and 2 PVC on multipoint, fomula will be: 256 / 2 pvc =128 kbps, 32 kbps is 25% of 128kbps.
- on Point-to-point, as CIR is 64 kbps , and WIGRP will use only half of it, bandwidth command will be skipped.
WAN1(config-subif)#interface Serial1/0.1 multipoint              
WAN1(config-subif)# bandwidth 256
WAN1(config-subif)# ip bandwidth-percent eigrp  15 25
WAN1(config-subif)#interface Serial1/0.2 point-to-point
WAN1(config-subif)# bandwidth 128
WAN1(config-subif)# ip bandwidth-percent eigrp  15 25

WAN2(config)#interface Serial1/0.1 multipoint
WAN2(config-subif)# bandwidth 128
WAN2(config-subif)# ip bandwidth-percent eigrp  15 50
WAN2(config-subif)#interface Serial1/0.2 point-to-point
WAN2(config-subif)# bandwidth 64

BRANCH-1(config)#interface Serial1/0.1 multipoint
BRANCH-1(config-subif)#bandwidth 256
BRANCH-1(config-subif)#interface Serial1/0.2 multipoint
BRANCH-1(config-subif)#bandwidth 128 

BRANCH-2(config)#interface Serial1/0.1 multipoint
BRANCH-2(config-subif)#bandwidth 256
BRANCH-2(config-subif)#interface Serial1/0.2 multipoint
BRANCH-2(config-subif)#bandwidth 128

BRANCH-3(config)#interface Serial1/0.1 point-to-point
BRANCH-3(config-subif)#bandwidth 128
BRANCH-3(config-subif)#interface Serial1/0.2 point-to-point
BRANCH-3(config-subif)#bandwidth 64
After that, routes on Branch loopbacks are available on CORE routers only through WAN1 router.
Core1#sh ip route
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.0.0.0/24 is directly connected, Ethernet0/0
L        10.0.0.1/32 is directly connected, Ethernet0/0
D        10.1.1.0/24 [90/10665472] via 10.0.0.10, 00:02:36, Ethernet0/0
D        10.1.2.0/24 [90/10665472] via 10.0.0.10, 00:02:36, Ethernet0/0
D        10.1.3.0/24 [90/20665600] via 10.0.0.10, 00:02:36, Ethernet0/0
      193.10.24.0/30 is subnetted, 2 subnets
D        193.10.24.0 [90/20537600] via 10.0.0.10, 00:02:36, Ethernet0/0
D        193.10.24.4 [90/15657472] via 10.0.0.10, 00:00:49, Ethernet0/0
D     193.10.25.0/24 [90/10537472] via 10.0.0.10, 00:02:36, Ethernet0/0
D     193.10.26.0/24 [90/11049472] via 10.0.0.10, 00:02:36, Ethernet0/0
Routes are not even in EIGRP topology, because WAN2 will not announce them (WAN2 see these routes best from WAN1)
Core1#sh ip eigrp topology all
EIGRP-IPv4 Topology Table for AS(15)/ID(1.0.0.0)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.1.3.0/24, 1 successors, FD is 20665600, serno 155
        via 10.0.0.10 (20665600/20640000), Ethernet0/0
P 193.10.26.0/24, 1 successors, FD is 20537600, serno 163
        via 10.0.0.20 (20537600/20512000), Ethernet0/0, serno 130
P 10.0.0.0/24, 1 successors, FD is 281600, serno 1
        via Connected, Ethernet0/0
P 10.1.2.0/24, 1 successors, FD is 10665472, serno 147
        via 10.0.0.10 (10665472/10639872), Ethernet0/0
P 193.10.25.0/24, 1 successors, FD is 10537472, serno 143
        via 10.0.0.10 (10537472/10511872), Ethernet0/0, serno 120
P 193.10.24.4/30, 1 successors, FD is 40537600, serno 211
        via 10.0.0.20 (40537600/40512000), Ethernet0/0
P 193.10.24.0/30, 1 successors, FD is 20537600, serno 152
        via 10.0.0.10 (20537600/20512000), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 10665472, serno 149
        via 10.0.0.10 (10665472/10639872), Ethernet0/0
c) Stub Routers
Branch1/2/3 should not participate in the Query process in case of a neighborship failure and should only advertise connected routes.

Route filtering could be used to prevent WAN1 from learning such a route. However, using route filtering would require a lot of configuration on all the branch routers, with specifics for the subnets–and it would have to change over time. A better solution exists,which is to make the branch routers stub routers. EIGRP defines stub routers as follows:
A router that should not forward traffic between two remote EIGRP-learned subnets.

The stub router simply performs less work and reduces the Query Scope because neighbors will not send these routes any Query messages.
Hub-And-Spoke Networking
Only the remote routers are configured as stubs (spokes). The stub feature does not prevent routes from being advertised to the remote route.
A stub router indicates in the hello packet to all neighboring routers its status as a stub router. Any router that receives a packet informing it of its neighbor’s stub status does not query the stub router for any routes. Therefore, a router that has a stub peer does not query that peer.

Branch 1/2/3 will be stub routers.
If  configure eigrp stub command, EIGRP will fullfill with defaults: connected summary.

"connected"  - advertise connected routes but only for interfaces matched with a network command.
"summary" - advertise auto-summarized or statically configured summary routes.
router eigrp 15
 eigrp stub connected
BRANCH-3(config)#  router eigrp 15
BRANCH-3(config-router)#  eigrp stub connected
*Nov 13 16:15:06.977: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.24.5 (Serial1/0.2) is down: peer info changed
*Nov 13 16:15:06.977: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.24.1 (Serial1/0.1) is down: peer info changed
*Nov 13 16:15:07.939: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.24.1 (Serial1/0.1) is up: new adjacency
*Nov 13 16:15:09.258: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.24.5 (Serial1/0.2) is up: new adjacency

On WAN1
WAN1#sh ip eigrp neighbors detail
EIGRP-IPv4 Neighbors for AS(15)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
4   193.10.25.20            Se1/0.1                 148 00:01:28   41  1170  0  319
   Static neighbor
   Version 9.0/2.0, Retrans: 0, Retries: 0, Prefixes: 3
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED ) Routes
   Suppressing queries
0   193.10.24.2             Se1/0.2                  12 00:02:05  826  4956  0  241
   Version 9.0/2.0, Retrans: 0, Retries: 0, Prefixes: 2
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED ) Routes
   Suppressing queries
5   193.10.25.10            Se1/0.1                 139 00:05:14   29  1170  0  285
   Static neighbor
   Version 9.0/2.0, Retrans: 1, Retries: 0, Prefixes: 3
   Topology-ids from peer - 0
   Stub Peer Advertising (CONNECTED ) Routes
   Suppressing queries
3   10.0.0.2                Et0/0                     5 5d01h       2   100  0  117
   Version 9.0/2.0, Retrans: 1, Retries: 0
   Topology-ids from peer - 0
2   10.0.0.20               Et0/0                     4 1w0d        5   100  0  443
   Version 9.0/2.0, Retrans: 0, Retries: 0, Prefixes: 2
   Topology-ids from peer - 0
1   10.0.0.1                Et0/0                     4 1w0d        4   100  0  222
   Version 9.0/2.0, Retrans: 0, Retries: 0
   Topology-ids from peer - 0
d) OFFSET LISTS
Because of the different CIR between Branch / Wan ( 128kbps and 64kbp) some "bad" things happened on Wan2. Wan2 has a better route to Branches going through Wan1 than using its own PVC links. So Wan2 doesn't advertise any route to branches through frame-relay anymore. Instead Wan2 advertise routes to Branches passing through Wan1 !!!
So let's correct that... <<< On Wan1 >>>  (Please read the final note about the usage of that feature).
        - Create an Access list 1 matching 10.1.1.0 and 10.1.2.0
        - Add an offset-list to EIGRP 15 for incoming routes updates matching ACL 1 on interface s1/0.1
        - Create an ACL 2 matching 10.1.3.0
        - Add an offset-list to EIGRP 15 for incoming routes updates matching ACL 2 out interface s1/0.2
The value of the offset should be a few units less than the difference between FD to the branch from Wan1 and from Wan2.

Why threat incoming updates?

Routes to Branch1/2 have the same FD. But not the one to Branch3. One offset-list can be applied per interface so here we can set different offsets for Branch1/2 and Branch3. Working on outgoing interface wouldn't allow that. The aim is to make Wan1 report routes with Metric just a little bit smaller than the one reported by Wan2 so that Core1/2 will put them  all in their topology table ... Preventing them to enter the query process in case of a PVC failure or such.

The value of the offset should be a few units less than the difference between FD to the branch from Wan1 and from Wan2.
EIGRP Offset Lists, allow to simply add a value (an offset), to the calculated integer metric for a given prefix.

Branch Networks are seen better from WAN1 then WAN2

On WAN2:

Prefix            AD-diff   AD-via-FR    AD-via-LAN-and-FR (is FD)
10.1.1.0/24    9974528 = 20640000 - 10665472
10.1.2.0/24    9974528 = 20640000 - 10665472
10.1.3.0/24    19974400 = 40640000 - 20665600
WAN2#sh ip route | inc 10.1.*.0
D        10.1.1.0/24 [90/10665472] via 10.0.0.10, 00:00:08, Ethernet0/0
D        10.1.2.0/24 [90/10665472] via 10.0.0.10, 00:00:08, Ethernet0/0
D        10.1.3.0/24 [90/20665600] via 10.0.0.10, 00:00:04, Ethernet0/0

WAN2#sh ip eigrp top
....
P 10.1.1.0/24, 1 successors, FD is 10665472
        via 10.0.0.10 (10665472/10639872), Ethernet0/0     through WAN1-FR_fast-BR3
        via 193.10.26.10 (20640000/128256), Serial1/0.1    through FR_slow-BR3
So offset will be set only on WAN1 and will be greater than 9974528 for ACL 1, and 20665600 for ACL 2.
WAN1(config)# access-list 1 permit 10.1.1.0
WAN1(config)# access-list 1 permit 10.1.2.0
WAN1(config)# access-list 2 permit 10.1.3.0
WAN1(config)# router eigrp 15
WAN1(config-router)# offset-list 1 in 9980000 Serial1/0.1
WAN1(config-router)# offset-list 2 in 19999750 Serial1/0.2
*Nov 13 17:02:28.082: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.25.20 (Serial1/0.1) is resync: intf route configuration changed
*Nov 13 17:02:28.082: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.25.10 (Serial1/0.1) is resync: intf route configuration changed
*Nov 13 17:02:32.407: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.24.2 (Serial1/0.2) is resync: intf route configuration changed
Note: Find correct value requered fine tuning.
For instance: 19999750 is OK, 2002500 is too much.

Before update
WAN2#sh ip eigrp top 
...
P 10.1.1.0/24, 1 successors, FD is 10665472
        via 10.0.0.10 (10665472/10639872), Ethernet0/0
        via 193.10.26.10 (20640000/128256), Serial1/0.1
P 10.1.2.0/24, 1 successors, FD is 10665472
        via 10.0.0.10 (10665472/10639872), Ethernet0/0
        via 193.10.26.20 (20640000/128256), Serial1/0.1
P 10.1.3.0/24, 1 successors, FD is 20665600
        via 10.0.0.10 (20665600/20640000), Ethernet0/0
        via 193.10.24.6 (40640000/128256), Serial1/0.2
And after update
WAN2#sh ip eigrp top
...
P 10.1.2.0/24, 1 successors, FD is 20640000
        via 193.10.26.20 (20640000/128256), Serial1/0.1
        via 10.0.0.10 (20645376/20619776), Ethernet0/0, serno 383
P 10.1.1.0/24, 1 successors, FD is 20640000
        via 193.10.26.10 (20640000/128256), Serial1/0.1
        via 10.0.0.10 (20645376/20619776), Ethernet0/0
P 10.1.3.0/24, 1 successors, FD is 40640000
        via 193.10.24.6 (40640000/128256), Serial1/0.2
        via 10.0.0.10 (40665344/40639744), Ethernet0/0, serno 430
All routes are known through Frame-relay network, as needed.
WAN1#sh ip route | inc 10.1.*.0
D        10.1.1.0/24 [90/20614872] via 193.10.25.10, 00:16:32, Serial1/0.1
D        10.1.2.0/24 [90/20614872] via 193.10.25.20, 00:16:32, Serial1/0.1
D        10.1.3.0/24 [90/40665000] via 193.10.24.2, 00:01:56, Serial1/0.2

WAN2#sh ip route | inc 10.1.*.0
D        10.1.1.0/24 [90/20640000] via 193.10.26.10, 00:18:25, Serial1/0.1
D        10.1.2.0/24 [90/20640000] via 193.10.26.20, 00:18:25, Serial1/0.1
D        10.1.3.0/24 [90/40640000] via 193.10.24.6, 00:03:17, Serial1/0.2
e) Variance
It is asked, that Core1 and Core2 to have Wan2 as Feasible Successor for all branches.
Set the Variance to 2.

EIGRP can balance traffic across multiple routes that have different metrics—this is called unequal-cost load balancing.


The degree to which EIGRP performs load balancing is controlled by the variance multiplier router configuration command. The multiplier is a variance value, between 1 and 128, used for load balancing. The default is 1, which means equal-cost load balancing. The  multiplier defines the range of metric values that are accepted for load balancing. Setting a  variance value greater than 1 allows EIGRP to install multiple loop-free routes with unequal cost in the routing table. EIGRP will always install successors (the best routes) in the routing table. The variance allows feasible successors to also be installed in the routing table.

Only paths that are feasible can be used for load balancing, and the routing table only includes feasible paths. The two feasibility conditions are as follows:
 - Feasible condition (Loop free paths),
 - The metric of the entire path (the FD of the alternative route) must be lower than the variance multiplied by the local best metric (the current FD).

Or lets say VFG is a value of FD multiplied by Variance, so any alternate route (that meet Feasible Condition) that have AD smaller then VFD are added to route table (and are load balanced with previous only FD).

First, let's check routes on CORE (must be 2 ways: through every WAN).
Core1#sh ip eigrp top
P 10.1.3.0/24, 1 successors, FD is 40665344
        via 10.0.0.10 (40665344/40639744), Ethernet0/0, serno 307
        via 10.0.0.20 (40665600/40640000), Ethernet0/0
P 10.1.2.0/24, 1 successors, FD is 20645376
        via 10.0.0.10 (20645376/20619776), Ethernet0/0, serno 284
        via 10.0.0.20 (20665600/20640000), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 20645376
        via 10.0.0.10 (20645376/20619776), Ethernet0/0
        via 10.0.0.20 (20665600/20640000), Ethernet0/0

Core2#sh ip eigrp top
P 10.1.3.0/24, 1 successors, FD is 40665344
        via 10.0.0.10 (40665344/40639744), Ethernet0/0, serno 40
        via 10.0.0.20 (40665600/40640000), Ethernet0/0
P 10.1.2.0/24, 1 successors, FD is 20645376
        via 10.0.0.10 (20645376/20619776), Ethernet0/0, serno 14
        via 10.0.0.20 (20665600/20640000), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 20645376
        via 10.0.0.10 (20645376/20619776), Ethernet0/0
        via 10.0.0.20 (20665600/20640000), Ethernet0/0

As it can be seen on both CORE, FS  for all branches is WAN1
Core1#sh ip route | inc 10.1.*
D        10.1.1.0/24 [90/20645376] via 10.0.0.10, 00:21:45, Ethernet0/0
D        10.1.2.0/24 [90/20645376] via 10.0.0.10, 00:21:45, Ethernet0/0
D        10.1.3.0/24 [90/40665344] via 10.0.0.10, 00:06:37, Ethernet0/0

Core2#sh ip route | inc 10.1.*
D        10.1.1.0/24 [90/20645376] via 10.0.0.10, 00:21:36, Ethernet0/0
D        10.1.2.0/24 [90/20645376] via 10.0.0.10, 00:21:36, Ethernet0/0
D        10.1.3.0/24 [90/40665344] via 10.0.0.10, 00:06:28, Ethernet0/0
Now it's time to modify path with variance.
Core1(config)#router eigrp 15
Core1(config-router)#variance 2

Core2(config)#router eigrp 15
Core2(config-router)#variance 2
Result:
Core1#sh ip route
D        10.1.1.0/24 [90/20665600] via 10.0.0.20, 00:01:05, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:01:05, Ethernet0/0
D        10.1.2.0/24 [90/20665600] via 10.0.0.20, 00:01:05, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:01:05, Ethernet0/0
D        10.1.3.0/24 [90/40665600] via 10.0.0.20, 00:01:05, Ethernet0/0
                     [90/40665344] via 10.0.0.10, 00:01:05, Ethernet0/0

Core2#sh ip route
D        10.1.1.0/24 [90/20665600] via 10.0.0.20, 00:00:45, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:00:45, Ethernet0/0
D        10.1.2.0/24 [90/20665600] via 10.0.0.20, 00:00:45, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:00:45, Ethernet0/0
D        10.1.3.0/24 [90/40665600] via 10.0.0.20, 00:00:45, Ethernet0/0
                     [90/40665344] via 10.0.0.10, 00:00:45, Ethernet0/
HOW   TO  TEST   LOAD-BALANCING
When a packet is process-switched (CPU), load balancing over equal-cost paths occurs on a per-packet basis. 
When packets are fast-switched (CEF), load balancing over equal-cost paths is on a per-destination basis.

If you are testing load balancing, do not ping to or from the routers with the fast-switching interfaces, because these locally router-generated packets are process-switched rather than fast-switched and might produce confusing results.

Load balancing is performed only on traffic that passes through the router, not traffic generated by the router.

Traffic originated by router or destined to router is not CEF switched (Traceroute, Ping), but process switched and process switching does per-packet load-sharing.
Core1#traceroute       
Protocol [ip]:
Target IP address: 10.1.1.1
Source address:
Numeric display [n]: y
Timeout in seconds [3]:
Probe count [3]: 6
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.0.10 1 msec
    10.0.0.20 0 msec
    10.0.0.10 1 msec
    10.0.0.20 0 msec
    10.0.0.10 0 msec
    10.0.0.20 0 msec
  2 193.10.25.10 17 msec
    193.10.26.10 17 msec *  17 msec
    193.10.25.10 13 msec *
Core1#

7) Propagate "default route", manual-summarization and filters
a) Create a loopback 0 interface on Core1 with ip address 199.10.20.30/24 (take care of auto-summary).
b) Define a default-network matching the interface Lo0 address.
c) Activate EIGRP on that interface.
(All routers should now a route to 199.10.20.0 flagged as default route  D* in sh ip route).
d) Assuming subnet 10.1.0.0/24 isn't in use anywhere we can summarize all branches subnets at once using 10.1.0.0/22. So let's apply that summary to Wan1/Wan2 Fa0/0 Interface.
e) As there is no reason to send traffic to PVC subnets (193.10....), let's filter those routes so that they are not advertised to Core1/2.
f) Create a prefix-list pfx_route_filter that match PCS subnets and apply through a distribute-list using a route-map rm_route_filter.

Info:
EIGRP have two main options to advertise default routes: to define a static default route and advertise it with EIGRP and to flag an existing route to be used also as a default route.
1) Advertising Static Default Routes with EIGRP
! static route to exit interface
ip route 0.0.0.0 0.0.0.0 Serial1/0
 network 0.0.0.0
!   network 0.0.0.0    or    redistribute static
2) Configuring a Default Network
The second option for creating a default route is to flag a route for a classful network–for a prefix that will be advertised into the EIGRP domain–as a route that can be used as a default route. Then each  router can use the forwarding details in that route–the outgoing interface and next-hop router–as its  default route.

  Step 1. On the router to which all traffic should be directed, identify a classful network that can be advertised into the EIGRP domain, and ensure that network is being advertised into EIGRP (typically using the EIGRP network command).

  Step 2. Configure that network as a default network using the global command
ip default-network <network-number>

Most often, that route is either created off a loopback interface for the purpose of making this process work, or an existing route on the Internet side of the router is used.
Router originating default-network, itself does not use that route as its default (“Gateway of last resort not set.”), because router is actually the original advertiser of the default.

a, b, c)  default-network
Create a loopback 0 interface on Core1 with ip address 199.10.20.30/24 (take care of auto-summary)
Define a default-network matching the interface Lo0 address, activate EIGRP on that interface.

interface Loopback0
 ip address 199.10.20.30 255.255.255.0
!
Core1(config)#ip default-network 199.10.20.0
Core1(config)#router eigrp 15
Core1(config-router)#network 199.10.20.0

WAN1#sh ip route
Gateway of last resort is not set
D*    199.10.20.0/24 [90/409600] via 10.0.0.1, 00:00:42, Ethernet0/0
... output ommited
Note: If network command from router eigrp is used before declaring ip default-network, default candidate will not propagate. (clear ip route *, clean eigrp...  not helping)

Bonus: Test propagate default route with EIGRP
1) using redistribute static
Core1
ip route 0.0.0.0 0.0.0.0 Loopback0
router eigrp 15
 redistribute static

WAN1#sh ip route
Gateway of last resort is 10.0.0.1 to network 0.0.0.0
D*EX  0.0.0.0/0 [170/409600] via 10.0.0.1, 01:20:16, Ethernet0/0
... output ommited
2) using network 0.0.0.0
Core1
ip route 0.0.0.0 0.0.0.0 Loopback0
router eigrp 15
 network 0.0.0.0

WAN1#sh ip route
Gateway of last resort is 10.0.0.1 to network 0.0.0.0
D*    0.0.0.0/0 [90/409600] via 10.0.0.1, 00:00:03, Ethernet0/0
D     199.10.20.0/24 [90/409600] via 10.0.0.1, 00:00:03, Ethernet0/0
... output ommited
3) automatic redistribution and propagate default route
EIGRP automaticaly (redistribute) propagate default route only if ip route is set to exit interface


d) Manual summarization
Assuming subnet 10.1.0.0/24 isn't in use anywhere we can summarize all branches subnets at once using 10.1.0.0/22. So let's apply that summary to Wan1/Wan2 Fa0/0 Interface.


EIGRP Summarization command (configured on an interface): ip summary-address eigrp <asn> <prefix> <subnet-mask>
Before summarization:
Core1(config-router)#do sh ip route
....
D        10.1.1.0/24 [90/20665600] via 10.0.0.20, 00:02:56, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:02:56, Ethernet0/0
D        10.1.2.0/24 [90/20665600] via 10.0.0.20, 00:02:56, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:02:56, Ethernet0/0
D        10.1.3.0/24 [90/40665600] via 10.0.0.20, 00:02:56, Ethernet0/0
                     [90/40665344] via 10.0.0.10, 00:02:56, Ethernet0/0
...
WAN1(config)#int Ethernet0/0
WAN1(config-if)#ip summary-address eigrp 15 10.1.0.0/22
*Nov 19 14:22:02.943: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.1 (Ethernet0/0) is resync: summary configured
*Nov 19 14:22:02.943: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.20 (Ethernet0/0) is resync: summary configured
*Nov 19 14:22:02.943: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.2 (Ethernet0/0) is resync: summary configured


WAN2(config)#int Ethernet0/0
WAN2(config-if)#ip summary-address eigrp 15 10.1.0.0/22
*Nov 19 14:23:13.318: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.1 (Ethernet0/0) is resync: summary configured
*Nov 19 14:23:13.318: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.10 (Ethernet0/0) is resync: summary configured
*Nov 19 14:23:13.318: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.2 (Ethernet0/0) is resync: summary configured
After config
Core1#sh ip route  10.1.0.0 255.255.252.0 lo
Gateway of last resort is not set
      10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
D        10.1.0.0/22 [90/20665600] via 10.0.0.20, 00:02:04, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:02:04, Ethernet0/0
e) Prefix filtering with Route-map and ACL
As there is no reason to send traffic to PVC subnets (193.10....), let's filter those routes so that they are not advertised to Core1/2.


EIGRP enables route filtering using the distribute-list router subcommand.
The distribute list refers to either an access control list (ACL), prefix list, or route map.
These three tools classify whether a route should be permitted to be sent/received in an EIGRP Update or be denied (filtered). The distribute-list command also specifies the direction–outbound updates or inbound updates–and optionally, the specific interface on which to filter updates.

FILTERING With ACL
Before filtering, let's check these routes on COREs
Core1#sh ip route | inc 193.*.*.*
      193.10.24.0/30 is subnetted, 2 subnets
D        193.10.24.0 [90/20537600] via 10.0.0.10, 17:09:19, Ethernet0/0
D        193.10.24.4 [90/40537600] via 10.0.0.20, 17:09:19, Ethernet0/0
D     193.10.25.0/24 [90/10537472] via 10.0.0.10, 17:09:19, Ethernet0/0
D     193.10.26.0/24 [90/20537600] via 10.0.0.20, 17:09:19, Ethernet0/0

Core2#sh ip route | inc 193.*.*.*
      193.10.24.0/30 is subnetted, 2 subnets
D        193.10.24.0 [90/20537600] via 10.0.0.10, 17:39:56, Ethernet0/0
D        193.10.24.4 [90/40537600] via 10.0.0.20, 1d14h, Ethernet0/0
D     193.10.25.0/24 [90/10537472] via 10.0.0.10, 17:39:56, Ethernet0/0
D     193.10.26.0/24 [90/20537600] via 10.0.0.20, 1d14h, Ethernet0/0

On WAN1 and WAN2 router will be applied distibution lists to out (facing CORE LAN)
access-list 2 deny 193.10.0.0 0.0.255.255
access-list 2 permit any
router eigrp 15
 distribute-list 2 out

*Nov 20 07:23:50.749: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.1 (Ethernet0/0) is resync: route configuration changed
*Nov 20 07:23:50.749: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.10 (Ethernet0/0) is resync: route configuration changed
*Nov 20 07:23:50.749: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.10 (Serial1/0.1) is resync: route configuration changed
*Nov 20 07:23:50.749: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.2 (Ethernet0/0) is resync: route configuration changed
*Nov 20 07:23:50.749: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.26.20 (Serial1/0.1) is resync: route configuration changed
WAN2(config-router)#
*Nov 20 07:23:50.749: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 193.10.24.6 (Serial1/0.2) is resync: route configuration changed
After filtering
*Nov 20 07:23:50.787: %DUAL-5-NBRCHANGE: EIGRP-IPv4 15: Neighbor 10.0.0.20 (Ethernet0/0) is resync: peer graceful-restart
Core1#sh ip route | inc 193.*.*.*
Core1#
To check that routing is OK, ping one of the Branch loopback interface.
Core1#ping  10.1.2.1    
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 23/24/25 ms
Core1#

FILTERING 
With ROUTE-MAP


Before filtering
Core2(config)#do sh ip route
Gateway of last resort is not set
      10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
C        10.0.0.0/24 is directly connected, Ethernet0/0
L        10.0.0.2/32 is directly connected, Ethernet0/0
D        10.1.0.0/22 [90/20665600] via 10.0.0.20, 00:00:44, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:00:44, Ethernet0/0
      193.10.24.0/30 is subnetted, 2 subnets
D        193.10.24.0 [90/20537600] via 10.0.0.10, 00:00:47, Ethernet0/0
D        193.10.24.4 [90/40537600] via 10.0.0.20, 00:00:47, Ethernet0/0
D     193.10.25.0/24 [90/10537472] via 10.0.0.10, 00:00:47, Ethernet0/0
D     193.10.26.0/24 [90/20537600] via 10.0.0.20, 00:00:47, Ethernet0/0
D*    199.10.20.0/24 [90/409600] via 10.0.0.1, 00:05:53, Ethernet0/0
Core2(config)#
It is asked to filter 193.10.*.0 prefixes, but to permit 10.1.*.0

Lets apply route-map filtering on both WAN routers:
ip prefix-list DENY193 permit 193.10.0.0/16 ge 24 le 30
! this permit will only MATCH prefixes
! if set deny here, and deny in route-map, prefixes will be permited :)
!
route-map EIGRP-FR_FILTER-OUT deny 193
!! this deny will filter matched prefixes
 match ip address prefix-list DENY193
route-map EIGRP-FR_FILTER-OUT permit 7777
 description PERMIT-ANY
!
router eigrp 15
  distribute-list route-map EIGRP-FR_FILTER-OUT out
!
Filtering result
Core2(config)#do sh ip route
Gateway of last resort is not set
      10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
C        10.0.0.0/24 is directly connected, Ethernet0/0
L        10.0.0.2/32 is directly connected, Ethernet0/0
D        10.1.0.0/22 [90/20665600] via 10.0.0.20, 00:03:49, Ethernet0/0
                     [90/20645376] via 10.0.0.10, 00:03:49, Ethernet0/0
D*    199.10.20.0/24 [90/409600] via 10.0.0.1, 00:08:58, Ethernet0/0

Final check if Branch Loopback are reachable
Core2#ping
*Nov 22 16:49:39.996: %SYS-5-CONFIG_I: Configured from console by console
Core2#ping 10.1.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 25/25/26 ms
Core2#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 31/33/35 ms
Core2#ping 10.1.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 31/33/34 ms
Core2#
 That all.