MP-BGP for IPv6

I recently passed the CCNP SWITCH exam, so now Spanning-tree is out the window, and I am firmly concentrated on all things layer 3 in preparation for the CCNP ROUTE exam.

One of the areas I have not really had much exposure too is IPv6.  So I have spent the last few days going over the theory behind it, and trying to put it into practice.
Read more of this post

IP SLA and Object Tracking

I’ve recently been doing some work with our HSRP setup around our network. Like most people, we use HSRP as a first hop redundancy mechanism to provide clients attached to the network with a virtual default gateway. HSRP will, be default, fail from Active to Standby, should the routers lose the ability to talk to one another on the subnet the HSRP for.

But what if something “down the line” fails…

Read more of this post

DMVPN – The Config

So following on from my last post, I have come up with a topology to test a DMVPN Solution;

My Plan is to use setup DMVPN with R1 & R2 forming the “Hub” site, and R3 forming the “Spoke” site, R5 is just there to add an additional layer to the IGP I will be using (probably EIGRP, as I believe OSPF can have problems running over a DMVPN due to its link-state nature)

If you’re wondering where R4 is, its forming my “Internet” cloud.

I haven’t really included IP addressing on this diagram, but if you see 172.24.0.0/16 address in the config, I have used this range to simulate the public address space. with 10.0.0.0/8 representing the private address space.

This setup is what is technically called a dual cloud DMVPN setup, as there are two DMVPN tunnels going to each spoke, this provides redundancy should there be a failure of one of the routers at the hub.

There are two ways to direct traffic flows with this dual cloud setup, you could use your IGP to load balance across both tunnels, or you could set the metric of one of the tunnels so that one is prefered and one is secondary, I don’t really see much problem with either option, I guess its down to personal preference unless someone can suggest otherwise.

Read more of this post

EIGRP Authentication Part II

So after thinking about how to implement key-chains around my network, I decided the best way would be to have a setup that has a new key every month, with a little overlap from when one key ends to the next key starts, to account for differences in NTP – realistically a few second difference would be too much, but I’ll allow for an hour just in case.

I’ve made a spreadsheet which generates random strings for use as keys, and using the times/dates entered, generates some config (EIGRP Key Chains Spreadsheet) I can then push this out to all my routers with Solarwinds NCM to make sure the same key-chain is everywhere. In theory you can use a different key chain for every router pair, but I felt the admin overhead on this was way too much, even on a relatively small network.

Read on for the config…. Read more of this post

EIGRP Authentication

I imagine most networks use EIGRP Authentication on the interfaces that are enabled for EIGRP;

R01(config)#int fa0/1
R01(config-if)# ip authentication mode eigrp 1 md5
R01(config-if)# ip authentication key-chain eigrp 1 MYKEYS

Usually i only see people using the one key with the send/accept lifetimes set to infinite.

I am reviewing the security on our network, and am debating whether or not to implement keys with a set lifetime?

I have always been put off doing this in the past due to the issues with making sure the key lifetimes overlap, below is a sample I’ve been working on in my lab using 1 minute keys with 30 second overlap at either side of the key lifetime;

key chain MYKEYS
key 1
key-string 1111
accept-lifetime local 16:39:30 Mar 27 2011 duration 120
send-lifetime local 16:40:00 Mar 27 2011 duration 60
key 2
key-string 2222
accept-lifetime local 16:40:30 Mar 27 2011 duration 120
send-lifetime local 16:41:00 Mar 27 2011 duration 60
key 3
key-string 3333
accept-lifetime local 16:41:30 Mar 27 2011 duration 120
send-lifetime local 16:42:00 Mar 27 2011 duration 60
key 4
key-string 4444
accept-lifetime local 16:42:30 Mar 27 2011 duration 120
send-lifetime local 16:43:00 Mar 27 2011 duration 60

Obviously in a production environment, you wouldn’t use such short durations, i think maybe a month per key would be about right. With the last key send/accept lifetime set to infinite to prevent the key-chain from expiring if new ones are not added in time and causing an outage.

the “show key chain” is alway quite useful if this is something you are new too;

R02#show key chain
Key-chain MYKEYS:
key 1 -- text "1111"
accept lifetime (16:39:30 BST Mar 27 2011) - (120 seconds) [valid now]
send lifetime (16:40:00 BST Mar 27 2011) - (60 seconds)
key 2 -- text "2222"
accept lifetime (16:40:30 BST Mar 27 2011) - (120 seconds) [valid now]
send lifetime (16:41:00 BST Mar 27 2011) - (60 seconds) [valid now]
key 3 -- text "3333"
accept lifetime (16:41:30 BST Mar 27 2011) - (120 seconds)
send lifetime (16:42:00 BST Mar 27 2011) - (60 seconds)
key 4 -- text "4444"
accept lifetime (16:42:30 BST Mar 27 2011) - (120 seconds)
send lifetime (16:43:00 BST Mar 27 2011) - (60 seconds)

All in all I think this is something that would be quite acceptable and not to much of an admin overhead with a proper planning.

The final question – do we use the same key chain on all routers/interfaces, or use multiple key chains, but then I can see the administration getting excessive!