Saturday 19 November 2011

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]