17 - IPv4 Redistribution - Implementing Simple Redistribution

I have already setup the lab (done this the other night, basic IP connectivity as per above)

Lets break down step 1 and configure EIGRP and OSPF on the respective routers;


R1(config)#router eigrp 100
R1(config-router)#network 10.0.0.0
R1(config-router)#no auto-summary


R2(config)#router eigrp 100
R2(config-router)#network 10.1.12.0 0.0.0.255
R2(config-router)#no auto-summary

00:06:27: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 10.1.12.1 (Serial0/0) is up: new adjacency


R2(config)#router ospf 1
R2(config-router)#network 10.1.23.0 0.0.0.255 area 0


R3(config)#router ospf 1
R3(config-router)#networ 10.0.0.0 0.255.255.255 area 0

*Mar  1 00:11:30.395: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.23.2 on Serial1/0 from LOADING to FULL, Loading Done


So router2 should now show both EIGRP and OSPF routes;

R2#show ip route

     10.0.0.0/8 is variably subnetted, 16 subnets, 2 masks
O       10.1.10.1/32 [110/65] via 10.1.23.3, 00:00:06, Serial0/1
O       10.1.11.1/32 [110/65] via 10.1.23.3, 00:00:06, Serial0/1
O       10.1.8.1/32 [110/65] via 10.1.23.3, 00:00:06, Serial0/1
O       10.1.9.1/32 [110/65] via 10.1.23.3, 00:00:06, Serial0/1
O       10.1.11.5/32 [110/65] via 10.1.23.3, 00:00:06, Serial0/1
C       10.1.12.1/32 is directly connected, Serial0/0
C       10.1.12.0/24 is directly connected, Serial0/0
D       10.1.3.0/24 [90/20640000] via 10.1.12.1, 00:11:53, Serial0/0
D       10.1.2.0/24 [90/20537600] via 10.1.12.1, 00:11:53, Serial0/0
D       10.1.1.0/24 [90/20640000] via 10.1.12.1, 00:11:53, Serial0/0
D       10.1.0.0/24 [90/20640000] via 10.1.12.1, 00:11:53, Serial0/0
O       10.1.7.1/32 [110/65] via 10.1.23.3, 00:00:06, Serial0/1
D       10.1.6.0/24 [90/20640000] via 10.1.12.1, 00:11:53, Serial0/0
D       10.1.5.0/24 [90/20640000] via 10.1.12.1, 00:11:53, Serial0/0
D       10.1.4.0/24 [90/20640000] via 10.1.12.1, 00:11:53, Serial0/0
C       10.1.23.0/24 is directly connected, Serial0/1

Lets just tweak the serial point-to-point links

R3(config-if)#int loopback7
R3(config-if)#ip ospf network point-to-point
R3(config-if)#int loopback8
R3(config-if)#ip ospf network point-to-point
R3(config-if)#int loopback9
R3(config-if)#ip ospf network point-to-point
R3(config-if)#int loopback10
R3(config-if)#ip ospf network point-to-point
R3(config-if)#int loopback11
R3(config-if)#ip ospf network point-to-point
R3(config-if)#int loopback12
R3(config-if)#ip ospf network point-to-point
R3(config-if)#int loopback13
R3(config-if)#ip ospf network point-to-point

Thats better now the loopbacks look like real point-to-point links instead of that /32 host mask

R2#show ip route

     10.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
O       10.1.11.0/30 [110/65] via 10.1.23.3, 00:01:41, Serial0/1
O       10.1.10.0/24 [110/65] via 10.1.23.3, 00:01:41, Serial0/1
O       10.1.9.0/24 [110/65] via 10.1.23.3, 00:01:41, Serial0/1
O       10.1.8.0/24 [110/65] via 10.1.23.3, 00:01:41, Serial0/1
O       10.1.11.4/30 [110/65] via 10.1.23.3, 00:01:41, Serial0/1
C       10.1.12.1/32 is directly connected, Serial0/0
C       10.1.12.0/24 is directly connected, Serial0/0
O       10.1.11.8/30 [110/65] via 10.1.23.3, 00:01:41, Serial0/1
D       10.1.3.0/24 [90/20640000] via 10.1.12.1, 00:16:37, Serial0/0
D       10.1.2.0/24 [90/20537600] via 10.1.12.1, 00:16:37, Serial0/0
D       10.1.1.0/24 [90/20640000] via 10.1.12.1, 00:16:37, Serial0/0
D       10.1.0.0/24 [90/20640000] via 10.1.12.1, 00:16:37, Serial0/0
O       10.1.7.0/24 [110/65] via 10.1.23.3, 00:01:41, Serial0/1
D       10.1.6.0/24 [90/20640000] via 10.1.12.1, 00:16:37, Serial0/0
D       10.1.5.0/24 [90/20640000] via 10.1.12.1, 00:16:37, Serial0/0
D       10.1.4.0/24 [90/20640000] via 10.1.12.1, 00:16:37, Serial0/0
C       10.1.23.0/24 is directly connected, Serial0/1

The problem we have with this is loosing the metric, both EIGRP and OSPF have totally different metrics:
OSPF = cost
EIGRP = composite of bandwidth and delay

As shown above RIP and EIGRP networks when distributed have an infinite metric by default
So OSPF will never see this routes as they are "unreachable" (ill prove this in abit)

OSPF networks have a default metric of 20 when distributed, BGP is whatever it was when you redistributed from the internal network (stays the same)


NOW, lets start with getting them EIGRP routes into OSPF, for this we have to go under the OSPF process;

R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 100 ?
  metric       Metric for redistributed routes
  metric-type  OSPF/IS-IS exterior metric type for redistributed routes
  route-map    Route map reference
  subnets      Consider subnets for redistribution into OSPF
  tag          Set tag for routes redistributed into OSPF
  <cr>

Now by default, when we do redistribution it will try and  summarise the networks (which if you recall from our instructions we are not allowed to do)

SO we can use the "subnets" commands to keep their subnet class, rather than be summarised back to their orginal classful networks


If i miss off the subnet command (you are prompted this fact)

R2(config-router)#redistribute eigrp 100
% Only classful networks will be redistributed


R2(config-router)#redistribute eigrp 100 subnets


R3#show ip route


     10.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
C       10.1.11.0/30 is directly connected, Loopback11
C       10.1.10.0/24 is directly connected, Loopback10
C       10.1.9.0/24 is directly connected, Loopback9
C       10.1.8.0/24 is directly connected, Loopback8
C       10.1.11.4/30 is directly connected, Loopback12
O E2    10.1.12.1/32 [110/20] via 10.1.23.2, 00:00:18, Serial1/0
O E2    10.1.12.0/24 [110/20] via 10.1.23.2, 00:00:18, Serial1/0
O E2    10.1.3.0/24 [110/20] via 10.1.23.2, 00:00:18, Serial1/0
C       10.1.11.8/30 is directly connected, Loopback13
C       10.1.2.0/24 is directly connected, FastEthernet0/0
O E2    10.1.1.0/24 [110/20] via 10.1.23.2, 00:00:18, Serial1/0
O E2    10.1.0.0/24 [110/20] via 10.1.23.2, 00:00:18, Serial1/0
C       10.1.7.0/24 is directly connected, Loopback7
O E2    10.1.6.0/24 [110/20] via 10.1.23.2, 00:00:18, Serial1/0
O E2    10.1.5.0/24 [110/20] via 10.1.23.2, 00:00:18, Serial1/0
O E2    10.1.4.0/24 [110/20] via 10.1.23.2, 00:00:18, Serial1/0
C       10.1.23.0/24 is directly connected, Serial1/0


NOTICE by default the routes come thru as E2 routes "E2 - OSPF external type 2"
E1 = These incriment their metric
E2 = these dont

NOTE:
If we want to change this can do via:
R2(config-router)#redistribute eigrp 100 subnets metric-type ?
  1  Set OSPF External Type 1 metrics
  2  Set OSPF External Type 2 metrics  <- - DEFAULT (wont show under OSPF, its default)


SO if this works, great, if not we can change the metric by this command;

R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 100 subnets metric 100

This now sets any redistributed routes via EIGRP to a new default metric of 100 NOT 20 (as they are E2 routes)


R3#show ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
C       10.1.11.0/30 is directly connected, Loopback11
C       10.1.10.0/24 is directly connected, Loopback10
C       10.1.9.0/24 is directly connected, Loopback9
C       10.1.8.0/24 is directly connected, Loopback8
C       10.1.11.4/30 is directly connected, Loopback12
O E2    10.1.12.1/32 [110/100] via 10.1.23.2, 00:00:10, Serial1/0
O E2    10.1.12.0/24 [110/100] via 10.1.23.2, 00:00:10, Serial1/0
O E2    10.1.3.0/24 [110/100] via 10.1.23.2, 00:00:10, Serial1/0
C       10.1.11.8/30 is directly connected, Loopback13
C       10.1.2.0/24 is directly connected, FastEthernet0/0
O E2    10.1.1.0/24 [110/100] via 10.1.23.2, 00:00:10, Serial1/0
O E2    10.1.0.0/24 [110/100] via 10.1.23.2, 00:00:10, Serial1/0
C       10.1.7.0/24 is directly connected, Loopback7
O E2    10.1.6.0/24 [110/100] via 10.1.23.2, 00:00:10, Serial1/0
O E2    10.1.5.0/24 [110/100] via 10.1.23.2, 00:00:10, Serial1/0
O E2    10.1.4.0/24 [110/100] via 10.1.23.2, 00:00:10, Serial1/0
C       10.1.23.0/24 is directly connected, Serial1/0

The cost has changed!

RIGHT, lets get OSPF redistributed into EIGRP, so lets go under the EIGRP process as that is what we want to redistribute into;

R2(config)#router eigrp 100
R2(config-router)#redistribute ospf 1 ?
  match      Redistribution of OSPF routes
  metric     Metric for redistributed routes
  route-map  Route map reference
  vrf        VPN Routing/Forwarding Instance

Not as many options here, but they are pretty self explanatory, lets run with what we have;

R2(config-router)#redistribute ospf 1


lets jump over to R1 and check whats happening;

R1#show ip route


     10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
C       10.1.12.2/32 is directly connected, Serial0/0
C       10.1.12.0/24 is directly connected, Serial0/0
C       10.1.3.0/24 is directly connected, Loopback3
C       10.1.2.0/24 is directly connected, Ethernet0/0
C       10.1.1.0/24 is directly connected, Loopback1
C       10.1.0.0/24 is directly connected, Loopback0
C       10.1.6.0/24 is directly connected, Loopback6
C       10.1.5.0/24 is directly connected, Loopback5
C       10.1.4.0/24 is directly connected, Loopback4

They are not there.......WHY?!!??
Recall what i said earlier, these routes are being redistributed with an infinite metric ... so the routes are not valid, hence they are not in the routing table

We need to set a metric;

R2(config-router)#redistribute ospf 1  metric ?
  <1-4294967295>  Bandwidth metric in Kbits per second

The question in this lab, does not state what metric we have to use, so lets just go with 100 for each metric (K Value of EIGRP);


R2(config-router)#redistribute ospf 1  metric 100 100 100 100 100


Lets go and check it out on router 1:

R1#show ip route


     10.0.0.0/8 is variably subnetted, 17 subnets, 3 masks
D EX    10.1.11.0/30 [170/26137600] via 10.1.12.2, 00:00:20, Serial0/0
D EX    10.1.10.0/24 [170/26137600] via 10.1.12.2, 00:00:20, Serial0/0
D EX    10.1.9.0/24 [170/26137600] via 10.1.12.2, 00:00:20, Serial0/0
D EX    10.1.8.0/24 [170/26137600] via 10.1.12.2, 00:00:20, Serial0/0
D EX    10.1.11.4/30 [170/26137600] via 10.1.12.2, 00:00:20, Serial0/0
C       10.1.12.2/32 is directly connected, Serial0/0
C       10.1.12.0/24 is directly connected, Serial0/0
D EX    10.1.11.8/30 [170/26137600] via 10.1.12.2, 00:00:20, Serial0/0
C       10.1.3.0/24 is directly connected, Loopback3
C       10.1.2.0/24 is directly connected, Ethernet0/0
C       10.1.1.0/24 is directly connected, Loopback1
C       10.1.0.0/24 is directly connected, Loopback0
D EX    10.1.7.0/24 [170/26137600] via 10.1.12.2, 00:00:20, Serial0/0
C       10.1.6.0/24 is directly connected, Loopback6
C       10.1.5.0/24 is directly connected, Loopback5
C       10.1.4.0/24 is directly connected, Loopback4
D EX    10.1.23.0/24 [170/26137600] via 10.1.12.2, 00:00:20, Serial0/0

AWESOME!!! lets ping one of the loopbacks on R3 (becuase we all love a good ping!)


R1#ping 10.1.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms


Yeah boi! Steps 1 & 2 are now complete :0)

FINISHED EIGRP!

Started IPV4  Redistribution, starting off with the theory and the 1st nugget in the series, which was; IPv4 Redistribution - Controlling Routing Updates

One thing to say is, WOW!
It can get bloody complicated, I knew it was kool but wondered why everyone was soo weary of it, now i see, 1-way redistibution is not toooo bad, but 2-way over a mutlipoint network .... DD-AAAaaaaam!

Cant wait to get started on the next nugget "17 - IPv4 Redistribution - Implementing Simple Redistribution" which will involve labbing this sh1t :0)

OBJECTIVE 6
Configure the BB-Routers EIGRP interfaces to utilise up to 30% more of the allocated interface bandwidth than EIGRPs default configuration

NOTES
By default EIGRP will use 50% of the interface bandwidth, so if the interface bandwidth is 100k

100k            = 50k for EIGRP
  2

NOW, if this a NBMA/Multipoint network it would divide the interfaces bandwidth by the amount of neighbours .... ouch!

This is done under the interface and in percentages;

BB-Router(config)#int Serial0/0
BB-Router(config-if)#ip bandwidth-percent eigrp 90 ?
  <1-999999>  Maximum bandwidth percentage that EIGRP may use
BB-Router(config-if)#ip bandwidth-percent eigrp 90 80

Notice we can go to 999999%! dont think that is a recommeded option lol, but for this task we need to add 30% more than the 50% default , hence the config above


OBJECTIVE 7
Enable authentication between all EIGRP routers.  You should use two authentication keys:


 key 1
  Passphrase ccnp
  accepted from midnight00:00:00 Jan 1 2010 20:45:00 Nov 19 2011
  send from midnight Jan 1 2010 20:40:00 Nov 19 2011
 key 2
  Passphrase ccnpinthebag
  accepted from 20:43:00 Nov 19 2011 till infinitity
  send from 20:38:00 Nov 19 2011 till infinitity


EIGRP uses keychains which scale alot better than the usual cleartext password under the interface as used with other routing protocols.
The keychain comprises of keys that range from dates and times they will run from and too, so routers can change authentication keys on a regular rotation without downtime and without getting us network admin involved ..... pretty dam sweet!!! yes?

SO here is the config i am using;

key chain EIGRP_KEYS
 key 1
  key-string ccnp
  accept-lifetime 00:00:00 Jan 1 2010 20:45:00 Nov 19 2011
  send-lifetime 00:00:00 Jan 1 2010 20:40:00 Nov 19 2011
 key 2
  key-string ccnpinthebag
  accept-lifetime 20:43:00 Nov 19 2011 infinite
  send-lifetime 20:38:00 Nov 19 2011 infinite

Although I have two keys, if key 1 is still valid it will continue to use that key (think of an ACL, if it finds a match then it goes no further)

Now we have the keys configured, we have to apply the keys to the interface(s):
int Serial0/0
ip auth mode eigrp 90 md5
ip auth key-cha eigrp 90 EIGRP_KEYS

int Serial0/1
ip auth mode eigrp 90 md5
ip auth key-cha eigrp 90 EIGRP_KEYS

Now I have applied the config, if the other neighbours do not have the keys, the relationship will go down;

01:01:08: %DUAL-5-NBRCHANGE: IP-EIGRP 90: Neighbor 10.1.24.1 (Serial0/0) is down: authentication mode changed
01:01:20: %DUAL-5-NBRCHANGE: IP-EIGRP 90: Neighbor 10.1.2.3 (Ethernet0/0) is down: authentication mode changed

IMPORTANT NOTE: MIGHT WANT TO HAVE NTP RUNNING OVER NETWORK!

01:05:56: %DUAL-5-NBRCHANGE: IP-EIGRP 90: Neighbor 10.1.2.3 (Ethernet0/0) is down: Auth failure

Since i cut this quite close to the switch over time of the keys, the routers went straight to using key 2 after some down time :0);

BB-Router#deb eigrp packets
EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
BB-Router#
01:00:51: EIGRP: received packet with MD5 authentication, key id = 2
01:00:51: EIGRP: Received HELLO on Serial0/1 nbr 10.1.34.2
01:00:51:   AS 90, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:00:52: EIGRP: Sending HELLO on Serial0/1
01:00:52:   AS 90, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
01:00:52: EIGRP: received packet with MD5 authentication, key id = 2
01:00:52: EIGRP: Received HELLO on Serial0/0 nbr 10.1.24.2




Lets jump over on R2 and double check;

R2#deb eigrp packets
01:16:14: EIGRP: received packet with MD5 authentication, key id = 2
01:16:14: EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.2.3
01:16:14:   AS 90, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:16:14: EIGRP: received packet with MD5 authentication, key id = 2
01:16:14: EIGRP: Received HELLO on Serial0/0 nbr 10.1.24.1

Happy days, the EIGRP network is now alot more secure;

R2#show key chain
Key-chain EIGRP_KEYS:
    key 1 -- text "ccnp"
        accept lifetime (00:00:00 UTC Jan 1 2010) - (20:45:00 UTC Nov 19 2011)
        send lifetime (00:00:00 UTC Jan 1 2010) - (20:40:00 UTC Nov 19 2011)
    key 2 -- text "ccnpinthebag"
        accept lifetime (20:43:00 UTC Nov 19 2011) - (infinite) [valid now]
        send lifetime (20:38:00 UTC Nov 19 2011) - (infinite) [valid now]

Been doing alot of reading and concentrating on work atm, however have been playing with nbar and netflow for a work project, got some pretty graphs below;

Objective 5

Here we are going to perform unequal cost load balancing accross the 256kbps and 128kbps link via EIGRP.  This is done via the variance command which is set to 1 by default, which means it will only load balance with equal links (bandwidth speed).

To load balance we will use the variance 2 command, which means "I will load balance accross links that are twice as bad as my primary"

If we check the topology table we shall see the metric for each route;

BB-Router# show ip eigrp topology
IP-EIGRP Topology Table for AS(90)/ID(172.30.8.1)

P 10.1.2.0/24, 1 successors, FD is 10514432
         via 10.1.34.2 (10514432/28160), Serial0/1
         via 10.1.24.2 (20537600/281600), Serial0/0

The primary route has a metric of 10514432 (256kbps) and the fessiable sucessor has a metric of 20537600 (128kbps) which is rougly twice as bad;

10514432 x 2 = 21028864

So by using the variance command using a multiplier of 2 (as this will would encompass the 128kbps links metric) we can load balance


BB-Router(config)#router eigrp 90
BB-Router(config-router)#variance ?
  <1-128>  Metric variance multiplier
BB-Router(config-router)#variance 2

Lets check the routing table now;

BB-Router#show ip route

     172.30.0.0/16 is variably subnetted, 10 subnets, 2 masks
C       172.30.2.0/24 is directly connected, Loopback2
C       172.30.3.0/24 is directly connected, Loopback3
D       172.30.0.0/21 is a summary, 00:00:20, Null0
C       172.30.0.0/24 is directly connected, Loopback0
C       172.30.1.0/24 is directly connected, Loopback1
C       172.30.6.0/24 is directly connected, Loopback6
C       172.30.7.0/24 is directly connected, Loopback7
C       172.30.4.0/24 is directly connected, Loopback4
C       172.30.5.0/24 is directly connected, Loopback5
C       172.30.8.0/24 is directly connected, Loopback8
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
D       10.1.2.0/24 [90/10514432] via 10.1.34.2, 00:00:20, Serial0/1 
                    [90/20537600] via 10.1.24.2, 00:00:20, Serial0/0
C       10.1.24.2/32 is directly connected, Serial0/0
D       10.1.25.0/24 [90/10642432] via 10.1.34.2, 00:00:20, Serial0/1 <--- load balancing
                     [90/20640000] via 10.1.24.2, 00:00:20, Serial0/0           <--- load balancing


Now we can see we are load balancing over both links, EIGRP will intelligent load balance over the links, for every 2 packets send over the 256kbps link it will send 1 packet of the 128kbps .... AWESOME!

Objective 4

For this objective we need to summarise 172.30.0.0 172.30.7.255 into a single network, we cant include 172.30.8.0/24 as the summarisation will not be as efficient

 1     1    1  1  1                            5 bits needed
128 64 32 16 8 4 2 1   

   8                  8            5                        = bits
11111111.11111111.11111000.0-------   = 248

mask = 255.255.248.0 /21 in CIDR notation


Routing table BEFORE

R2>show ip route


Gateway of last resort is 10.1.2.3 to network 192.168.1.0

     172.30.0.0/24 is subnetted, 9 subnets
D       172.30.2.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
D       172.30.3.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
D       172.30.0.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
D       172.30.1.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
D       172.30.6.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
D       172.30.7.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
D       172.30.4.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
D       172.30.5.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
D       172.30.8.0 [90/10665472] via 10.1.2.3, 01:08:09, Ethernet0/0
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
C       10.1.2.0/24 is directly connected, Ethernet0/0
C       10.1.24.1/32 is directly connected, Serial0/0
C       10.1.25.0/24 is directly connected, Loopback2
C       10.1.24.0/30 is directly connected, Serial0/0
D       10.1.34.0/30 [90/10537472] via 10.1.2.3, 01:08:12, Ethernet0/0
D*   192.168.1.0/24 [90/10537472] via 10.1.2.3, 01:08:09, Ethernet0/0


BB-Router(config)#int ser0/0
BB-Router(config-if)#ip summary-address eigrp 90 172.30.0.0 255.255.248.0


R2>show ip route

Gateway of last resort is 10.1.2.3 to network 192.168.1.0

     172.30.0.0/16 is variably subnetted, 10 subnets, 2 masks
D       172.30.2.0/24 [90/10665472] via 10.1.2.3, 01:10:11, Ethernet0/0
D       172.30.3.0/24 [90/10665472] via 10.1.2.3, 01:10:11, Ethernet0/0
D       172.30.0.0/21 [90/20640000] via 10.1.24.1, 00:00:15, Serial0/0  <---- there it is
D       172.30.0.0/24 [90/10665472] via 10.1.2.3, 01:10:11, Ethernet0/0
D       172.30.1.0/24 [90/10665472] via 10.1.2.3, 01:10:11, Ethernet0/0
D       172.30.6.0/24 [90/10665472] via 10.1.2.3, 01:10:11, Ethernet0/0
D       172.30.7.0/24 [90/10665472] via 10.1.2.3, 01:10:11, Ethernet0/0
D       172.30.4.0/24 [90/10665472] via 10.1.2.3, 01:10:11, Ethernet0/0
D       172.30.5.0/24 [90/10665472] via 10.1.2.3, 01:10:11, Ethernet0/0
D       172.30.8.0/24 [90/10665472] via 10.1.2.3, 00:00:15, Ethernet0/0
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
C       10.1.2.0/24 is directly connected, Ethernet0/0
C       10.1.24.1/32 is directly connected, Serial0/0
C       10.1.25.0/24 is directly connected, Loopback2
C       10.1.24.0/30 is directly connected, Serial0/0
D       10.1.34.0/30 [90/10537472] via 10.1.2.3, 00:00:15, Ethernet0/0
D*   192.168.1.0/24 [90/10537472] via 10.1.2.3, 00:00:15, Ethernet0/0

We can see the new summary route taking affect, but R2 is still learning about this network from 10.1.2.3 (R3) REMEMBER regardless of Admin distance or speed of link, if a router has a more SPECIFIC mask for a network, it will use that route!!!

lets fix that;

BB-Router(config)#int serial0/1
BB-Router(config-if)#ip summary-address eigrp 90 172.30.0.0 255.255.248.0

R2>show ip route

     172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks
D       172.30.0.0/21 [90/10665472] via 10.1.2.3, 00:14:38, Ethernet0/0 <-- summary
D       172.30.8.0/24 [90/10665472] via 10.1.2.3, 00:14:38, Ethernet0/0 <--
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
C       10.1.2.0/24 is directly connected, Ethernet0/0
C       10.1.24.1/32 is directly connected, Serial0/0
C       10.1.25.0/24 is directly connected, Loopback2
C       10.1.24.0/30 is directly connected, Serial0/0
D       10.1.34.0/30 [90/10537472] via 10.1.2.3, 00:16:07, Ethernet0/0
D*   192.168.1.0/24 [90/10537472] via 10.1.2.3, 00:14:38, Ethernet0/0


Excellent! notice we have the 172.30.8.0/24 route too, this is becuase the summary is only advertising; 172.30.0.0 --> 172.30.7.255 and the network statement on EIGRP catches the rest of the 172 network;


router eigrp 90
 passive-interface default
 no passive-interface Serial0/0
 no passive-interface Serial0/1
 network 10.1.0.0 0.0.255.255
 network 172.30.0.0
 network 192.168.1.0
 no auto-summary

Job done

3rd Objective;


PASSIVE INTERFACES

If we look at R2, this router has an interface in 10.1.25.0/24, there is no other router on this segment yet R2 is sending hello's out this interface trying to actively form a relationship with an EIGRP neighbour.  This is a HUGE security hole as someone could plug in there own router and get EIGRP up and running and start injecting routes into the network, or better yet he could pull off a man in the middle attack and be packet sniffing all the traffic and forwarding it on.

One approach would be to remove the network from EIGRP, BUT this now means you are not advertising this network.....

This is where passive interfaces come in, as they disable the hello messages on that interface meaning no neighbour can form BUT it will still advertise the network to the rest of your EIGRP topology :0)


R2(config)#router eigrp 90
R2(config-router)#passive-interface loopback 2

(Im doing loopback2 as i didnt have another fastethernet port like on the CBT/network diagram)

So now, no hello messages will be sent out to 10.1.25.0/24 and no neighbourships will form and no routes learnt *dusts hands*

This is very different to what RIP's passive interface does;
It wont send updates out the interface (RIP doesn't form neighbours like EIGRP,just sends updates via broadcast or multicast depending on version) BUT it will still accept updates from other RIP routers and add them updates to the routing table.

----------------------------------------------------------------------------------
RIP's passive interface NOT as secure as EIGRP's passive interface
--------------------------------------------------------------------------------

Now lets secure the BackBone router, we have aload of interfaces (loopbacks in this example, but hey!) It would be alot more secure and easier for us to set all interfaces by default as passive

BB-Router(config)#router eigrp 90
BB-Router(config-router)#passive-interface default
BB-Router(config-router)#
00:36:33: %DUAL-5-NBRCHANGE: IP-EIGRP 90: Neighbor 10.1.24.2 (Serial0/0) is down: interface passive
00:36:33: %DUAL-5-NBRCHANGE: IP-EIGRP 90: Neighbor 10.1.34.2 (Serial0/1) is down: interface passive


Obviously this downs the neighbours straightaway as we have disabled the hello messages from talking to the neighbour, to get it up and running again we use the no command;

BB-Router(config-router)#no passive-interface serial0/0
BB-Router(config-router)#no passive-interface serial0/1
00:37:31: %DUAL-5-NBRCHANGE: IP-EIGRP 90: Neighbor 10.1.24.2 (Serial0/0) is up: new adjacency
00:37:31: %SYS-5-CONFIG_I: Configured from console by vty1 (10.1.34.2)
00:37:34: %DUAL-5-NBRCHANGE: IP-EIGRP 90: Neighbor 10.1.34.2 (Serial0/1) is up: new adjacency

heres it all together in the running config;

BB-Router#show run | s eigrp
router eigrp 90
 passive-interface default
 no passive-interface Serial0/0
 no passive-interface Serial0/1
 network 10.1.0.0 0.0.255.255
 network 172.30.0.0
 network 192.168.1.0
 no auto-summary