Sunday 11 July 2010

MPLS the Superior WAN

Just when you thought fast switching was the best layer 3 could be.....a new player made a new layer, all the hardware layer 2 addressing mixed with routable layer 3 addressing and just to make it even better throw in the ports to be used, welcome to layer 2.5. I know its not new now but its still awesome. The challenge was given to me to add MPLS VPN technology to an existing network in order to provide secure links between four different sites. The initial network des ign is as below
The objectives are:
1: Provide two separate VPN links between Finance - Payroll and Research - Labs
2: Further secure the Finance - Payroll link with IPSEC
3: Users are currently using the network so equipment cannot be removed (equipment may be added).

I love MPLS its such a dream to work with and simple to understand, to make this work there are a few changes i implemented.

1: With PE1 where it is at the moment is not suitable for me as two separate links are needed which means two VRF's on two interfaces so they would have to be setup on HQ and then tunnelled to PE1 to be put into MP-BGP.This may be done by using sub interfaces and multi-VRF which seems more work than needed i think.I have pushed the MPLS cloud up to the HQ router to allow the VRF's to be kept in their separate instances from there.

2: IPSEC problem, with the Finance segment hanging directly off the HQ router means that the IPSEC tunnel would use the outbound interface towards the P router but since its routing is moved from the VRF to MP-BGP the outbound interface has no idea about the networks behind it so cannot bring up the tunnel. My solution was simply to put another router in for Finance so that its outbound interface would learn about the other side through MP-BGP and the fun may commence.


My new design can be seen in Fig 2 above.

Protocols: In the cloud all mpls interface use OSPF and are in area 0, this link state protocol has been used here for its low administrative overhead and fast convergence on topology changes, only updates are sent every 30 minutes if nothing happens to make sure that everything is still there.

MP-BGP is used to allow the VRF's to communicate.

RIP has been used for all departments except research, don't worry its version 2 to allow for my subnetting scheme. This has been used since they are stub networks they don't need an advanced protocol. The RIP routes are redistributed into BGP and a default route is sent to the departments as its their only way out anyway.

Research is hanging directly off the HQ interface so the route needs to be redistributed into BGP.

BASIC SECURITY:
Security measures should be implemented on the routers to secure them from being accessed illegally.

MOTD - This is important as it can be used to display a warning to anyone wanting to gain access to the equipment saying who owns the network and only authorized users may use it. This may be a deterrent and if you are able to trace and prosecute someone who accessed your network illegally it shows you done all you can to say they shouldn't have been there.

Enable secret - This is a password that is needed to get from user EXEC level to privileged EXEC. By using the command enable secret instead of enable password it hashes that password so that it cannot be seen by a show run or someone peering over your shoulder.

Console password - There needs to be a password on the console port so that anybody who gains physical access to the equipment can't get in without a password.

VTY login - The vty lines 0 - 4 used for remote access need a password to login. They should only allow SSH connections version 2 as telnet is susceptible to sniffing due to sending everything in plain text. As extra protection a access list was put on the vty lines to only allow certain ip addresses establish a connection.

CDP - This protocol is very useful for troubleshooting a network as it gives information about connected neighbours. when enabled it sends this information out of all ports, with a packet sniffer this would be picked up telling them ip addresses, names and ports. It should be disabled on LAN interfaces with the no cdp enable command on the interface.

stay dramatic,

marty

No comments: