When you go back to the beginning, really go back to the beginning...

After having success yesterday with a small-scale Transparent ASA lab, I went back the main topology and tried to get it working.

Still no luck. So I changed the ASA image to a later one, still no luck, then changed to an ASAv image, still no luck.

So what is the problem?

Turns out the problem was between the seat and the keyboard.

Because I have spent so long away from this topology, I forgot how it is intended to run. I should have started afresh, and gone through all of my configurations again. Instead I thought I remembered everything and expected stuff to work.

I completely forgot that the three sites; NY, LA and London all hinge around a central MPLS core.

The interfaces I was trying to connect on NY1 were configured under a VRF, and as such, needed the EIGRP configuration to be vrf-aware.

This will not work:

NY1(config)#do sh run | s router e
router eigrp NY-EIGRP
 !
 address-family ipv4 unicast autonomous-system 100
  !
  topology base
  exit-af-topology
  network 0.0.0.0
  network 128.2.2.0 0.0.0.255
  network 128.2.2.2 0.0.0.0
 exit-address-family
NY1(config)#

Neither will this:

NY1(config)#no router eigrp NY-EIGRP
NY1(config)#router eigrp 100
NY1(config-router)#eigrp router-id 2.2.2.2
NY1(config-router)#network 128.2.2.2 0.0.0.0 
NY1(config-router)#
NY1(config-router)#
NY1(config-router)#do sh ip eigrp neigh     
EIGRP-IPv4 Neighbors for AS(100)
NY1(config-router)#

This does though:

NY1(config-router)#no router eigrp 100
NY1(config)#router eigrp NY-EIGRP
NY1(config-router)#address-family ipv4 vrf 802101 auto 100
NY1(config-router-af)#eigrp router-id 2.2.2.2
NY1(config-router-af)#network 128.2.2.2 0.0.0.0
NY1(config-router-af)#
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 128.2.2.1 (GigabitEthernet0/1) is up: new adjacency
NY1(config-router-af)#

It just goes to show that if you are actually starting again, as I am here, then start from the beginning, don't just try and drop in where you were previously, as vital bits can be missed.

So, this all said and my memory refreshed as to what it is I am supposed to be doing, I should stop fucking about and get the MPLS core finished off so that I don't get caught again.

This also gives me a great opportunity to plug my MPLS book, if you havn't read it, go and get it from Amazon!

To get NY1 talking to the MPLS cloud we need to do the following:

NY1(config)#router eigrp NY-EIGRP
NY1(config-router)#address-family ipv4 unicast vrf 802101 autonomous-system 100        
NY1(config-router-af)#topology base 
NY1(config-router-af-topology)#redistribute bgp 1 metric 1000 10 100 1 1500
NY1(config-router-af-topology)#exit
NY1(config-router-af)#exit
NY1(config-router)#router bgp 1
NY1(config-router)#address-family ipv4 vrf 802101
NY1(config-router-af)#redistribute eigrp 100 metric 1
NY1(config-router-af)#

We should give NY2 something to advertise:

NY2(config)#router eigrp 100
NY2(config-router)#network 3.3.3.1 0.0.0.0 
NY2(config-router)#network 3.3.3.2 0.0.0.0
NY2(config-router)#network 3.3.3.3 0.0.0.0
NY2(config-router)#

We can then see these routes on LA1 and LON1:

LA1#sh ip route vrf 802101 | b Gate
Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 3 subnets
B        3.3.3.1 [200/1] via 2.2.2.2, 00:01:50
B        3.3.3.2 [200/1] via 2.2.2.2, 00:01:46
B        3.3.3.3 [200/1] via 2.2.2.2, 00:01:43
      128.2.0.0/24 is subnetted, 1 subnets
B        128.2.2.0 [200/0] via 2.2.2.2, 00:04:29
      128.3.0.0/24 is subnetted, 1 subnets
B        128.3.3.0 [200/1] via 2.2.2.2, 00:04:29
      198.240.5.0/24 is variably subnetted, 2 subnets, 2 masks
C        198.240.5.0/30 is directly connected, GigabitEthernet0/0
L        198.240.5.1/32 is directly connected, GigabitEthernet0/0
LA1#

LON1#sh ip route vrf 802101 | b Gate
Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 3 subnets
B        3.3.3.1 [200/1] via 2.2.2.2, 00:05:49
B        3.3.3.2 [200/1] via 2.2.2.2, 00:05:45
B        3.3.3.3 [200/1] via 2.2.2.2, 00:05:41
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.1.0/24 is directly connected, GigabitEthernet0/1
L        10.1.1.1/32 is directly connected, GigabitEthernet0/1
      128.2.0.0/24 is subnetted, 1 subnets
B        128.2.2.0 [200/0] via 2.2.2.2, 00:08:28
      128.3.0.0/24 is subnetted, 1 subnets
B        128.3.3.0 [200/1] via 2.2.2.2, 00:08:28
LON1#

Let's set up LON1:

LON1(config)#router ospf 100 vrf 802101 
LON1(config-router)#router-id 10.10.10.10
% OSPF: router-id 10.10.10.10 in use by ospf process 1
LON1(config-router)#int lo1
LON1(config-if)#
LON1(config-if)#ip add 10.10.10.100 255.255.255.255
LON1(config-if)#router ospf 100 vrf 802101
LON1(config-router)#router-id 10.10.10.100             
LON1(config-router)#network 10.1.1.0 0.0.0.255 area 0
LON1(config-router)#red bgp 1 subnets
LON1(config-router)#router bgp 1
LON1(config-router)#address-fam ipv4 vrf 802101
LON1(config-router-af)#red ospf 100
LON1(config-router-af)#

From NY2 we can now reach LON1:

NY2#sh ip route eigrp | b Gate
Gateway of last resort is not set

      10.0.0.0/24 is subnetted, 1 subnets
D EX     10.1.1.0 [170/2562816] via 128.2.2.2, 00:00:29, GigabitEthernet0/0
NY2#
NY2#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 = 14/14/16 ms
NY2#

We cant get beyond LON1 (into our LON network) as LON-SW is not running OSPF (yet). Let's set up the LA side:

LA1(config)#router eigrp LA-EIGRP
LA1(config-router)#address-family ipv4 vrf 802101 auto 200
LA1(config-router-af)#eigrp router-id 4.4.4.4
LA1(config-router-af)#network 198.240.5.1 0.0.0.0
LA1(config-router-af)#top base  
LA1(config-router-af-topology)#red bgp 1 metr 1000 10 100 1 1500
LA1(config-router-af-topology)#exi
LA1(config-router-af)#exi
LA1(config-router)#router bgp 1
LA1(config-router)#address-f ipv4 vrf 802101
LA1(config-router-af)#red eigrp 200 metric 1
LA1(config-router-af)#

How does this look?

LON1#sh ip route vrf 802101 | b Gate
Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 3 subnets
B        3.3.3.1 [200/1] via 2.2.2.2, 00:21:10
B        3.3.3.2 [200/1] via 2.2.2.2, 00:21:06
B        3.3.3.3 [200/1] via 2.2.2.2, 00:21:02
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.1.0/24 is directly connected, GigabitEthernet0/1
L        10.1.1.1/32 is directly connected, GigabitEthernet0/1
      128.2.0.0/24 is subnetted, 1 subnets
B        128.2.2.0 [200/0] via 2.2.2.2, 00:23:49
      128.3.0.0/24 is subnetted, 1 subnets
B        128.3.3.0 [200/1] via 2.2.2.2, 00:23:49
      198.240.5.0/30 is subnetted, 1 subnets
B        198.240.5.0 [200/0] via 4.4.4.4, 00:00:17
LON1#

NY2#sh ip route eigrp | b Gate
Gateway of last resort is not set

      10.0.0.0/24 is subnetted, 1 subnets
D EX     10.1.1.0 [170/2562816] via 128.2.2.2, 00:10:18, GigabitEthernet0/0
      198.240.5.0/30 is subnetted, 1 subnets
D EX     198.240.5.0 [170/2562816] via 128.2.2.2, 00:01:24, GigabitEthernet0/0
NY2#ping 198.240.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.240.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/12 ms
NY2#

Pretty good!
Let's get LON-SW into OSPF and then we'll turn our attention to the LA-FW and multiple contexts.

LON-SW(config)#int lo0
LON-SW(config-if)#ip add 10.10.10.110 255.255.255.255
LON-SW(config-if)#router ospf 100
LON-SW(config-router)#router-id 10.10.10.110
LON-SW(config-router)#network 10.1.1.2 0.0.0.0 area 0
LON-SW(config-router)#
%OSPF-5-ADJCHG: Process 100, Nbr 10.10.10.100 on Vlan10 from LOADING to FULL, Loading Done
LON-SW(config-router)#
LON-SW(config-router)#network 21.38.5.1 0.0.0.0 area 0
LON-SW(config-router)#

Should be reachable from the NY and LA offices now:

NY2#sh ip route eigrp | b Gate
Gateway of last resort is not set

      10.0.0.0/24 is subnetted, 1 subnets
D EX     10.1.1.0 [170/2562816] via 128.2.2.2, 00:22:55, GigabitEthernet0/0
      21.0.0.0/24 is subnetted, 1 subnets
D EX     21.38.5.0 [170/2562816] via 128.2.2.2, 00:00:56, GigabitEthernet0/0
      198.240.5.0/30 is subnetted, 1 subnets
D EX     198.240.5.0 [170/2562816] via 128.2.2.2, 00:14:01, GigabitEthernet0/0
NY2#ping 21.38.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.38.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 14/17/22 ms
NY2#

LA1#sh ip route vrf 802101 | b Gate                                        
Gateway of last resort is not set

      3.0.0.0/32 is subnetted, 3 subnets
B        3.3.3.1 [200/1] via 2.2.2.2, 00:36:43
B        3.3.3.2 [200/1] via 2.2.2.2, 00:36:39
B        3.3.3.3 [200/1] via 2.2.2.2, 00:36:36
      10.0.0.0/24 is subnetted, 1 subnets
B        10.1.1.0 [200/0] via 10.10.10.10, 00:24:44
      21.0.0.0/24 is subnetted, 1 subnets
B        21.38.5.0 [200/2] via 10.10.10.10, 00:02:50
      128.2.0.0/24 is subnetted, 1 subnets
B        128.2.2.0 [200/0] via 2.2.2.2, 00:39:22
      128.3.0.0/24 is subnetted, 1 subnets
B        128.3.3.0 [200/1] via 2.2.2.2, 00:39:22
      198.240.5.0/24 is variably subnetted, 2 subnets, 2 masks
C        198.240.5.0/30 is directly connected, GigabitEthernet0/0
L        198.240.5.1/32 is directly connected, GigabitEthernet0/0
LA1#ping vrf 802101 21.38.5.1      
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 21.38.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/11/15 ms
LA1#

Sweet, now let's get going with some multiple context firewalls!

UNetLab topologies now available.

It seems that (and I am very thankful for this) UNetLab is making strong gains in popularity, as it should.

Whilst I do get the occasional email asking for setup help with GNS3 (which I am more than happy to do), I get far more emails asking when the book topologies will be available for UNetLab.

So, now that things have quietened down a bit, I have had time to do this.

On the relevant pages (above, under the Books menu) there are links for the files for the main topologies for all the books.

They are also here, to make it easier.

To import them you just need to create a folder called 802101 (you don't really have to have a folder, but it makes it neater):

Once thats done, go into the folder and then import an external object. Make sure its the whole zip file!

Then you should get a nice bunch of new labs:

The download links are below.

UNetLab Topology download links:

BGP for Cisco Networks
MPLS for Cisco Networks
VPNs and NAT for Cisco Networks

CCIE Security Lab, Part 2 - MPLS Core

Today the fun starts, as I will start by building up the MPLS core, which will serve as the connecting element between the three/four sites in the topology.

R1 will be the provider router, R2, R3, and Prov1 will be the PE routers. So I'll quickly go through the basic IP connectivity, IGP (OSPF), MPLS and BGP configuration, before looking at the best way to secure the individual components.

If you are not familiar with MPLS, then please go and buy my book; MPLS for Cisco Networks. It is a good place to start learning MPLS and covers, in much more depth, the stuff I will whizz through.

Just to re-iterate previous post, I won't be dwelling on MPLS security. It's not explicitly stated on the blueprint, and it does not feature on the INE workbook either. Which means its a pretty good bet that it won't feature in the exam.

Let's start with the basic IP configuration:

R1(config)#int gi 0/0
R1(config-if)#desc Connection to R2
R1(config-if)#ip add 134.20.1.1 255.255.255.252
R1(config-if)#no shu
R1(config-if)#do ping 134.20.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 134.20.1.2
.!!!!
Success rate is 80 percent (4/5)
R1(config-if)#int gi 0/1
R1(config-if)#desc Link to R3
R1(config-if)#ip add 134.20.1.5 255.255.255.252
R1(config-if)#no shu
R1(config-if)#int gi 0/2
R1(config-if)#desc Link to Prov1
R1(config-if)#ip add 134.20.1.9 255.255.255.252
R1(config-if)#no shu
R1(config-if)#int lo0
R1(config-if)#ip add 1.1.1.1 255.255.255.255
R1(config-if)#int lo8
R1(config-if)#ip add 8.8.8.8 255.255.255.255
R1(config-if)#do ping 134.20.1.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 134.20.1.6
.!!!!
Success rate is 80 percent (4/5)
R1(config-if)#do ping 134.20.1.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 134.20.1.10
.!!!!
Success rate is 80 percent (4/5)
R1(config-if)#

R2(config)#int gi 0/0
R2(config-if)#desc Connection to R1
R2(config-if)#ip add 134.20.1.2 255.255.255.252
R2(config-if)#no shut
R2(config-if)#
R2(config-if)#int lo0
R2(config-if)#ip add 2.2.2.2 255.255.255.255
R2(config-if)#

R4(config)#int gi 0/1
R4(config-if)#desc Link to R1
R4(config-if)#ip add 134.20.1.6 255.255.255.252
R4(config-if)#no shu
R4(config-if)#
R4(config-if)#int lo0
R4(config-if)#ip add 4.4.4.4 255.255.255.255
R4(config-if)#

Prov1(config)#int gi 0/0
Prov1(config-if)#desc Link to R1
Prov1(config-if)#ip add 134.20.1.10 255.255.255.252
Prov1(config-if)#no shu
Prov1(config-if)#
Prov1(config-if)#int lo0
Prov1(config-if)#ip add 10.10.10.10 255.255.255.255
Prov1(config-if)#

I am going to use OSPF as my IGP, so let's configure that...

R1(config-if)#exi
R1(config)#router ospf 1
R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 0.0.0.0 0.0.0.0 area 0
R1(config-router)#

R2(config-if)#router ospf 1
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 134.20.1.0 0.0.0.3 area 0
R2(config-router)#net 2.2.2.2 0.0.0.0 area 0
R2(config-router)#

R4(config-if)#router ospf 1
R4(config-router)#router-id 4.4.4.4
R4(config-router)#net 134.20.1.4 0.0.0.3 ar 0
R4(config-router)#net 4.4.4.4 0.0.0.0 a 0
R4(config-router)#

Prov1(config-if)#router ospf 1
Prov1(config-router)#router-id 10.10.10.10
Prov1(config-router)#net 134.20.1.10 0.0.0.0 a 0
Prov1(config-router)#net 10.10.10.10 0.0.0.0 a 0
Prov1(config-router)#

R1(config-router)#do sh ip ospf neigh

Neighbor ID     Pri  State     Dead Time Address     Interface
10.10.10.10       1  FULL/BDR  00:00:34  134.20.1.10 GigabitEthernet0/2
4.4.4.4           1  FULL/BDR  00:00:33  134.20.1.6  GigabitEthernet0/1
2.2.2.2           1  FULL/DR   00:00:37  134.20.1.2  GigabitEthernet0/0
R1(config-router)#

Because we are running OSPF, we can use the command "mpls ldp autoconfig":

R1(config-router)#mpls ldp autoconfig 
R1(config-router)#

R2(config-router)#mpls ldp autoconfig
R2(config-router)#

R4(config-router)#mpls ldp autoconfig
R4(config-router)#

Prov1(config-router)#mpls ldp autoconfig
Prov1(config-router)#

R1(config-router)#
%LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP
%LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (2) is UP
%LDP-5-NBRCHG: LDP Neighbor 10.10.10.10:0 (3) is UP
R1(config-router)#

Following a couple of best practices, we really should hard-code our label switching method, and our LDP router-id. At the moment the R1 will be using 8.8.8.8 as it's router ID, whereas I want to use 1.1.1.1:

R1(config-router)#exi  
R1(config)#mpls label protocol ldp 
R1(config)#mpls ldp router-id lo0 force 
R1(config)#

R2(config-router)#mpls label protocol ldp
R2(config)#mpls ldp router-id lo0 force
R2(config)#

R4(config)#mpls label protocol ldp
R4(config)#mpls ldp router-id lo0 force
R4(config)#

Prov1(config-router)#mpls label protocol ldp
Prov1(config)#mpls ldp router-id lo0 force
Prov1(config)#

Now we can configure MP-BGP:

R2(config)#router bgp 1
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#no bgp def ipv4-unicast 
R2(config-router)#neigh 4.4.4.4 remote 1
R2(config-router)#neigh 10.10.10.10 remote 1
R2(config-router)#neigh 4.4.4.4 update lo0
R2(config-router)#neigh 10.10.10.10 update lo0
R2(config-router)#address-family vpnv4 
R2(config-router-af)#neigh 4.4.4.4 activate
R2(config-router-af)#neigh 10.10.10.10 activ
R2(config-router-af)#neigh 4.4.4.4 send-community extended 
R2(config-router-af)#neigh 10.10.10.10 send-community extended 
R2(config-router-af)#

R4(config)#router bgp 1
R4(config-router)#bgp router-id 4.4.4.4
R4(config-router)#no bgp def ipv4
R4(config-router)#neigh 2.2.2.2 remote 1    
R4(config-router)#neigh 10.10.10.10 remote 1
R4(config-router)#neigh 2.2.2.2 update lo0
R4(config-router)#neigh 10.10.10.10 update lo0
R4(config-router)#add vpnv4
R4(config-router-af)#neigh 2.2.2.2 activ
R4(config-router-af)#neigh 10.10.10.10 activ
R4(config-router-af)#neigh 2.2.2.2 send-community extended 
R4(config-router-af)#neigh 10.10.10.10 send-community extended 
R4(config-router-af)#

Prov1(config)#router bgp 1
Prov1(config-router)#bgp router-id 10.10.10.10
Prov1(config-router)#no bgp def ipv4 
Prov1(config-router)#neigh 2.2.2.2 remote 1
Prov1(config-router)#neigh 4.4.4.4 remote 1
Prov1(config-router)#neigh 2.2.2.2 update lo0
Prov1(config-router)#neigh 4.4.4.4 update lo0
Prov1(config-router)#add vpnv4
Prov1(config-router-af)#neigh 2.2.2.2 activ
Prov1(config-router-af)#neigh 4.4.4.4 activ
Prov1(config-router-af)#neigh 2.2.2.2 send-comm ext
Prov1(config-router-af)#neigh 4.4.4.4 send-comm ext
Prov1(config-router-af)#

R2#sh bgp vpnv4 uni all sum
BGP router identifier 2.2.2.2, local AS number 1
BGP table version is 1, main routing table version 1

Neighbor      V  AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
4.4.4.4       4  1       4       4        1    0    0 00:02:25        0
10.10.10.10   4  1      13      14        1    0    0 00:10:30        0
R2#

Prov1#sh bgp vpnv4 uni all sum
BGP router identifier 10.10.10.10, local AS number 1
BGP table version is 1, main routing table version 1

Neighbor      V  AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2       4  1      14      13        1    0    0 00:10:52        0
4.4.4.4       4  1       7       6        1    0    0 00:04:15        0
Prov1#

So far so good, now we need to set up our VRF. I will only be using one (at least for the moment):

R2(config)#ip vrf 802101
R2(config-vrf)#rd 1:1
R2(config-vrf)#route-target bo 1:1
R2(config-vrf)#

R4(config-router-af)#ip vrf 802101
R4(config-vrf)# rd 1:1
R4(config-vrf)# route-target export 1:1
R4(config-vrf)# route-target import 1:1
R4(config-vrf)#

Prov1(config)#ip vrf 802101
Prov1(config-vrf)# rd 1:1
Prov1(config-vrf)# route-target export 1:1
Prov1(config-vrf)# route-target import 1:1
Prov1(config-vrf)#

Next we need to assign the relevant interfaces to the VRF:

R2(config-vrf)#int gi 0/1
R2(config-if)#ip vrf for 802101
R2(config-if)#ip add 128.2.2.2 255.255.255.252
R2(config-if)#desc Link to R3
R2(config-if)#no shu
R2(config-if)#

R4(config-vrf)#int gi 0/0
R4(config-if)#ip vrf for 802101
R4(config-if)#ip add 198.240.5.1 255.255.255.252
R4(config-if)#desc Link to CUSTFW01
R4(config-if)#no shu               
R4(config-if)#

Prov1(config-vrf)#int gi 0/1
Prov1(config-if)#ip vrf for 802101          
Prov1(config-if)#ip add 10.1.1.1 255.255.255.0
Prov1(config-if)#desc Link to ProvSW
Prov1(config-if)#no shu
Prov1(config-if)#

And finally we add the VRF to BGP:

R2(config-if)#router bgp 1
R2(config-router)#add ipv4 vrf 802101
R2(config-router-af)#

R4(config-if)#router bgp 1
R4(config-router)#add ipv4 vrf 802101
R4(config-router-af)#

Prov1(config)#router bgp 1
Prov1(config-router)#add ipv4 vrf 802101
Prov1(config-router-af)#

When we look at adding the sites together, we'll need to do redistribution between R3 and R2, CUSTFW01 and R4, and our HQ ASAs and the provider (Prov1), but it is not the intention to go that far just yet. Instead we'll now look at how we can secure the MPLS environment.

So, what can we, or should we secure? Our biggest danger, as it currently stands, is that someone could plug a router into the network, and it would not take them long to form an adjacency with us on OSPF or LDP. To gain access to BGP then they would have to perform some kind of man-in-the-middle attack and place themselves on the connecting wire - i.e. between R1 and R2, and then they would have to impersonate R2. This could easily be done through packet sniffing initially.

The simplest way in which we can protect ourselves is to implement some passwords. We will do this first on R2, below, and we can see that adding a password on it's own is good, but clearly not foolproof - if you gain access to the router, or to the configuration backups, then you can see that the password is stored in cleartext, unless you enable "service password-encryption":

R2(config)#router bgp 1
R2(config-router)#neigh 4.4.4.4 password 0 802101-Secrets
R2(config-router)#do sh run | i password
no service password-encryption
 neighbor 4.4.4.4 password 802101-Secrets
R2(config-router)#service password-encryption
R2(config)#do sh run | i password     
service password-encryption
 neighbor 4.4.4.4 password 7 135D47405A5C556718212B21303600
R2(config)#router bgp 1
R2(config-router)#neigh 10.10.10.10 password 0 802101-Secrets
R2(config-router)#do sh run | i password
service password-encryption
 neighbor 4.4.4.4 password 7 135D47405A5C556718212B21303600
 neighbor 10.10.10.10 password 7 154A5B5E557A7A691B363630161305
R2(config-router)#

R4(config)#router bgp 1
R4(config-router)#neigh 2.2.2.2 password 802101-Secrets
R4(config-router)#neigh 10.10.10.10 password 802101-Secrets
R4(config-router)#service password-encryption
R4(config)#

Prov1(config)#router bgp 1
Prov1(config-router)#neigh 2.2.2.2 password 802101-Secrets
Prov1(config-router)#neigh 4.4.4.4 password 802101-Secrets
Prov1(config-router)#service password-encryption
Prov1(config)#

Let's turn our attention to our MPLS configuration. We are not done with BGP security completely, we'll revisit it in a later post, where we'll look at ttl-security, which can only be done through eBGP peers.

We can do a number of things to secure our MPLS configuration from prying eyes. We can set a restriction on the route target values that we will import (and export):

R2(config)#ip extcommunity-list 101 permit RT:1:1
R2(config)#route-map ImportMap perm 10
R2(config-route-map)#match extcommunity 101
R2(config-route-map)#exit
R2(config)#route-map ExportMap perm 10
R2(config-route-map)#match extcommunity 101
R2(config-route-map)#ip vrf 802101
R2(config-vrf)#export map ExportMap
R2(config-vrf)#import map ImportMap
R2(config-vrf)#

R4(config)#ip extcommunity-list 101 permit RT:1:1
R4(config)#route-map ImportMap perm 10
R4(config-route-map)#match extcommunity 101
R4(config-route-map)#route-map ExportMap perm 10
R4(config-route-map)#match extcommunity 101
R4(config-route-map)#ip vrf 802101
R4(config-vrf)#export map ExportMap
R4(config-vrf)#import map ImportMap
R4(config-vrf)#

Prov1(config)#ip extcommunity-list 101 permit RT:1:1
Prov1(config)#route-map ImportMap perm 10
Prov1(config-route-map)#match extcommunity 101
Prov1(config-route-map)#route-map ExportMap perm 10
Prov1(config-route-map)#match extcommunity 101
Prov1(config-route-map)#ip vrf 802101
Prov1(config-vrf)#export map ExportMap
Prov1(config-vrf)#import map ImportMap
Prov1(config-vrf)#

The extended community list will match our route target (1:1), and permit it. The default deny rule will catch anything else, and this is then applied inbound and outbound to our VRF.

We can also set an LDP neighbor password. This is done below, and password encryption is turned on:

R1(config)#mpls ldp neigh 4.4.4.4 password 0 80201-Secret
R1(config)#mpls ldp neigh 2.2.2.2 password 0 80201-Secret
R1(config)#mpls ldp neigh 10.10.10.10 password 0 80201-Secret
R1(config)#do sh run | i password
no service password-encryption
mpls ldp neighbor 4.4.4.4 password 80201-Secret
mpls ldp neighbor 2.2.2.2 password 80201-Secret
mpls ldp neighbor 10.10.10.10 password 80201-Secret
R1(config)#service password-encryption
R1(config)#do sh run | i password     
service password-encryption
mpls ldp neighbor 4.4.4.4 password 7 135D47405B5D49192E273A3621
mpls ldp neighbor 2.2.2.2 password 7 025E54095B574212494D1B1C11
mpls ldp neighbor 10.10.10.10 password 7 04035B545F70017D0C1A171206
R1(config)#

R2(config)#mpls ldp neighbor 1.1.1.1 password 0 802101-Secret 
R2(config)#

R4(config-vrf)#mpls ldp neighbor 1.1.1.1 password 0 802101-Secret
R4(config)#

Prov1(config-vrf)#mpls ldp neighbor 1.1.1.1 password 0 802101-Secret
Prov1(config)#

Another best practice is to "hide" our MPLS network from our CE devices (should they do a trace route), the below command will do this:

R1(config)#no mpls ip propagate-ttl 
R1(config)#

OSPF, similarly, can be password protected using MD5, this will have the immediate effect of the OSPF speakers losing their adjacencies, but I have omitted those messages:

R1(config)#router ospf 1
R1(config-router)#area 0 authentication message-digest 
R1(config-router)#int gi 0/0
R1(config-if)#ip ospf authentication message-digest 
R1(config-if)#ip ospf message-digest-key 1 md5 0 802101-Secret
R1(config-if)#int g0/1
R1(config-if)#ip ospf authentication message-digest 
R1(config-if)#ip ospf message-digest-key 1 md5 0 802101-Secret
R1(config-if)#int gi 0/2
R1(config-if)#ip ospf authentication message-digest    
R1(config-if)#ip ospf message-digest-key 1 md5 0 802101-Secret
R1(config-if)#

R2(config)#router ospf 1
R2(config-router)#area 0 authentication message-digest
R2(config-router)#int gi 0/0
R2(config-if)#ip ospf authentication message-digest
R2(config-if)#ip ospf message-digest-key 1 md5 0 802101-Secret
R2(config-if)#
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0 from LOADING to FULL, Loading Done
R2(config-if)#

R4(config)#router ospf 1
R4(config-router)#area 0 authentication message-digest
R4(config-router)#int gi 0/1
R4(config-if)#ip ospf authentication message-digest
R4(config-if)#ip ospf message-digest-key 1 md5 0 802101-Secret
R4(config-if)#
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/1 from LOADING to FULL, Loading Done
R4(config-if)#

Prov1(config)#router ospf 1
Prov1(config-router)#area 0 authentication message-digest
Prov1(config-router)#int gi 0/0
Prov1(config-if)#ip ospf authentication message-digest
Prov1(config-if)#ip ospf message-digest-key 1 md5 0 802101-Secret
Prov1(config-if)#
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0 from LOADING to FULL, Loading Done
%BGP-5-NBR_RESET: Neighbor 4.4.4.4 active reset (BGP Notification sent)
%BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up 
%BGP-5-NBR_RESET: Neighbor 2.2.2.2 active reset (BGP Notification sent)
%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up 
Prov1(config-if)#

OK, all looks fine so far. But what happened after OSPF got torn down and the neighborships reestablished? LDP wouldn't come up. The passwords were there, but the message (Invalid MD5 digest) indicates that the password is wrong.

R1(config-router)#do sh run | i password     
service password-encryption
mpls ldp neighbor 4.4.4.4 password 7 135D47405B5D49192E273A3621
mpls ldp neighbor 2.2.2.2 password 7 025E54095B574212494D1B1C11
mpls ldp neighbor 10.10.10.10 password 7 04035B545F70017D0C1A171206
R1(config-router)#do sh ip ospf neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.10       1   FULL/DR         00:00:39    134.20.1.10     GigabitEthernet0/2
4.4.4.4           1   FULL/DR         00:00:33    134.20.1.6      GigabitEthernet0/1
2.2.2.2           1   FULL/DR         00:00:38    134.20.1.2      GigabitEthernet0/0
R1(config-router)#exit
R1(config)#logging con
R1(config)#
%TCP-6-BADAUTH: Invalid MD5 digest from 2.2.2.2(13861) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 4.4.4.4(19675) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 10.10.10.10(16183) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 2.2.2.2(13861) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 4.4.4.4(39459) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 10.10.10.10(16183) to 1.1.1.1(646) tableid - 0

So what is happening here?

Well, in one of those "can't see the wood for the trees" moments, I fat-fingered the configuration on R1. It took me running the password through a password cracker to see the difference. Just goes to prove you should pick a password that makes spotting mistakes easy to do. Alternatively, a much better approach is to do it all on one router, and then copy the encrypted password from the "master" to the other routers - using "mpls ldp neigh <neighbor> password 7 <encrypted password>". Below you can see that once thew password was copied from R1 onto R2, the error cleared and LDP came up.

The full compare, replace and contrast sequence is below:

%LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP
%TCP-6-BADAUTH: Invalid MD5 digest from 10.10.10.10(16183) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 4.4.4.4(39459) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 10.10.10.10(49475) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 10.10.10.10(49475) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 4.4.4.4(60395) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 4.4.4.4(60395) to 1.1.1.1(646) tableid - 0
%TCP-6-BADAUTH: Invalid MD5 digest from 10.10.10.10(49475) to 1.1.1.1(646) tableid - 0
R1(config)#no logging con
R1(config)#

R2(config-if)#do sh run | i password
service password-encryption
mpls ldp neighbor 1.1.1.1 password 7 09141E5B4855465F380907382E30
 neighbor 4.4.4.4 password 7 135D47405A5C556718212B21303600
 neighbor 10.10.10.10 password 7 154A5B5E557A7A691B363630161305
R2(config-if)#mpls ldp neighbor 1.1.1.1 password 7 025E54095B574212494D1B1C11
R2(config)#
%LDP-5-PWDCFG: Password configuration changed for 1.1.1.1:0
%LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP

R4(config)#do sh run | i password
service password-encryption
mpls ldp neighbor 1.1.1.1 password 7 1016594B544743463F012939213C
 neighbor 2.2.2.2 password 7 0757711E1F5948482417081E013E38
 neighbor 10.10.10.10 password 7 065E5F731D1E585436121119091039
R4(config)#mpls ldp neighbor 1.1.1.1 password 7 135D47405B5D49192E273A3621
R4(config)#
%LDP-5-PWDCFG: Password configuration changed for 1.1.1.1:0
R4(config)#
%LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP

Prov1(config)#do sh run | i password
service password-encryption
mpls ldp neighbor 1.1.1.1 password 7 135D47405A5C556718212B213036
 neighbor 2.2.2.2 password 7 09141E5B4855465F380907382E303B
 neighbor 4.4.4.4 password 7 1016594B544743463F012939213C20
Prov1(config)#neighbor 1.1.1.1 password 7 04035B545F70017D0C1A171206          
Prov1(config)#
%LDP-5-PWDCFG: Password configuration changed for 1.1.1.1:0
Prov1(config)#
%LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP   
Prov1(config)#

R1#sh mpls ldp neigh | i Ident
    Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0
        Addresses bound to peer LDP Ident:
    Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 1.1.1.1:0
        Addresses bound to peer LDP Ident:
    Peer LDP Ident: 10.10.10.10:0; Local LDP Ident 1.1.1.1:0
        Addresses bound to peer LDP Ident:
R1#

Not a bad start. I learnt something (about properly using password encryption), and I have a basis for the network to start to evolve.

I am currently reading "MPLS VPN Security", which is pretty good, lot's of theory and explanation, but a little light on configuration. Still, definitely a good purchase so far.

There is a good inclusion on access-lists, below is one with would permit BGP, OSPF, and LDP:

access-list 110 permit tcp host x.x.x.x host loopback eq bgp
access-list 110 permit ospf host x.x.x.x host 224.0.0.5
access-list 110 permit ospf host x.x.x.x host 224.0.0.6
access-list 110 permit ospf host x.x.x.x host local_ip
access-list 110 permit tcp address mask any eq 646
access-list 110 permit udp address mask any eq 646

I think I will save this for later on though, when all the tunnels are in place. The next post will either be about transparent firewalls, or Multiple-context firewalls.

IOU file for MPLS for Cisco Networks now available

I had been meaning to finish this off for a while, but what with the studying and all, it kind of got put to the side. Anyway, I got sent an email, from a very friendly guy, asking if I could send the initial configs so that he could create the IOU files himself.

Instead I created the IOU file, including a clickable image map (again this is a real push towards going solely IOU for the next volumes). It looks much cleaner than the GNS3 version, and I can reuse the image that's in the book, so it keeps a much more consistent feel.

Obviously the interface names will be different (no GigabitEthernet in IOU), but you are a bunch of clever people, so I am sure you'll be fine!

So far the majority of people responding to the poll on the right hand side are in favour of IOU, but there is still quite a few days left, so who knows which way it will swing.
The IOU-web file for MPLS for Cisco Networks is available to download from the books section above.

MPLS for Cisco Networks now available!

It's been a long ride. Finally, though, it's finished and being published.

MPLS for Cisco Networks is here!

So what has changed and what's stayed the same?

The format is the same. We have one main topology, it grows and changes as we cover all the topics on both the official CCIE v5 blueprint, and also the INE expanded blueprint. There are smaller, sub-contained, topologies where appropriate. We now have a longer troubleshooting section, with one topology and seven different tickets.

The biggest difference is that we have an editor for this one. Beau emailed me, asking would I like him to edit the second volume (after he read the first one). At first I was a little unsure. The BGP volume was my baby, in a way, and would you let a complete stranger look after your baby? Well, its not like handing over my children, and his credentials looked good (ex-Teacher, Network engineer - so what more could I want!). I do not regret taking the chance and asking him to join me. Together we have created, in my opinion, an excellent book. He's been juggling parenthood, work and being a husband, with hours and hours (and hours) of correcting my grammar, making sentences shorter and more concise. If I gave a penny to my children for every time he's had to add a comma, they'd be rich by now! Seriously, I cannot say enough how he turned the book around. It's far more readable. My sentences do have a tendency to be a little long, it's all to do with how it comes out of my head as I am working through it. So when you are reading it, and you pause for breath in a paragraph, you can thank him! It's not just the grammar though, he's been through the topology with such dedication. It's been excellent to have another pair of eyes on it. He must be a glutton for punishment though, as he's agreed to do number 3 as well!

We have more pictures. This does influence the size (for Kindle), and has meant that printing costs (as well as the fact that its much longer) have increased. It is slightly more expensive than the BGP book, but still very reasonable. I am not out to make a fortune from these, I am doing it because I enjoy it.

We are still using GNS3. It's probably the most familiar to people, but IOU topologies will follow in due course.
In all, I am more pleased with this one than the BGP book. In hind-sight I think I rushed the BGP book. I never expected it to ever be as popular as it has been. When I published on Kindle (not even thinking at that stage it would appear in printed format), I said to my wife that if a couple of people enjoyed it, then it would be worth it. I am still very proud of it, nonetheless. It's a learning process, not just in the material, but in how to write. It will become a more honed process as I write more. I hope I have listened to all of the requests that have come in (apart from one, which, I think, was just asking me to write it exactly like an O'Reilly book - still not sure of that conversation, I was very confused).

I hope you enjoy it.

Sneak peek at volume 2

It is not quite ready yet, it's still being proofed by my technical editor, but I thought I would get a proof copy or two so that I can make sure formatting is right  and that the pictures are coming out properly.

I must say I am pleased so far. So, want a sneak peak?

Here you go!

As you can see it has become a much longer book than the BGP volume! We have many more pictures for a start. 

It's still based around GNS3 and IOU topologies will follow. 

I am very excited by this latest volume. 

Work on volume 3 is already underway. 

BGP book topology updated for GNS3 1.0! MPLS book coming soon!

BGP for Cisco Networks & GNS3 1.0

I had a request hit my inbox last month for the topology for my book "BGP for Cisco Networks" to be updated for GNS3 1.0.

I must confess that with trying to finish off "MPLS for Cisco Networks", which is looking great and should be out soon(ish), I didn't do this very quickly.

But thanks to a great guy called Dan over at GNS3 and his nifty python based converter I have been able to do this in under half an hour.

So thanks Dan!

If you are currently using GNS3 1.0 and want to load up the topology, its available in the Downloads section.

MPLS for Cisco Networks

The MPLS book is taking a lot longer than the first, for a number of reasons.

I had a pretty good grounding in BGP when I started, but not so much with MPLS, and MPLS feels like such a bigger subject, the book is certainly longer if that's anything to go by!

I have learnt some things from the first book, mainly due to the comments made by my readers, so there will be more diagrams, more configurations, and hopefully a sense of being part of the book, rather than just a reader... That last bit should make more sense when you read it.

I am just finishing off a couple of bits; VPLS, OTV, IPv6 for VRF-Lite, and need to do the troubleshooting chapter - which is all planned out, and then its a matter of proofing, sending over to my technical ed, and then publishing!

Again topologies will be available in GNS3 0.8 first, with GNS31.0 and ViRL (whenever that eventually turns up) at a later stage.

MPLS for Cisco Networks - technical editor in, color pages out!

My second book entitled "MPLS for Cisco Networks" is coming along really well. I have had some very good feedback for my first book "BGP for Cisco Networks" so I am really encouraged that people are finding it a worthwhile read.

Self publishing CCIE books and pricing

I have learnt a few things from writing my first book, mainly about pricing. 

Firstly no matter how low you price it there will be people in a certain certification forum who will still ask for copies for free. You would think that with it being priced reasonably people would be more inclined to purchase it, but there are still some people who want everything for free.

Secondly price does matter. Publishing on Kindle is a pretty good way (not saying that it's foolproof) to make sure that it doesn't end up being shared for free across the globe, so my intellectual property is fairly well secured, plus as the kindle app is available on pretty much everything it can reach a very wide audience. Kindle allows me to be flexible on price, and overheads are low. That said the print version does just as well as the mobi version. Reading on a tablet is great, but there is nothing like holding a physical book, but pricing a printed book can be tricky - which I'll explain in a moment.

Anyway, back to the subject in hand, I am not digressing (much) as there is a purpose to all of this. 

A technical editor!

So firstly the good news. I got an email a little while ago from someone who had bought my book and he said (in a nice way) that it had a couple of run on sentences and a few bits of train of thought in it, and would I like him to do some technical editing. Some might have thought this to be a bit cheeky, but in no way was it phrased like a sales pitch, and he has a good history in teaching and in networking. I thought it would make a lot of sense. Hopefully he can polish off my book, and together we can create something a little larger than me just working by myself. His name is Beau, and hopefully we'll do a little introduction for him later.

On to the less good news - it's not bad news, but it's a little gripe more than anything.

MPLS for Cisco Networks in black and white

One of the feedbacks that I received was that it would have been nice to have color pages. I totally agree with this, especially as the next book has different areas referred to by colors of Red, White and Blue, rather than say Company A, Company B etc. This looks great so far, but something will be a little lost in translation to black and white print.

So what are the options? Well, the printed version which is priced at a mere $14.99 does not make much in profit. Once Createspace/Amazon have taken their cut, I get about $5, there is also a holding tax of 30% on top of that because I am a UK resident, so really its not looking like I can retire any time soon, I am doing this because I wanted to write a book and do something creative that people would find beneficial, money is not the primary objective. Nonetheless, if I wanted to create a 250 page book at $14.99 in black and white then we are looking at $5 royalty. If we switch to color print then I would actually owe Createspace over $9. So to make the same royalty of $5 the book would have to cost over $39! This goes against the whole idea of making the books affordable.

I am not Cisco, I can't release a book at ridiculous prices - such as the kindle only CCIE v5 Route and Switch Configuration Practice Labs at $50+, or the official v5 certification guide at $99. Don't get me wrong, I am not knocking these books as they are really good, and well worth the investment, I just don't see why they have to be so expensive. The exam is expensive enough, so there needs to be a break in expenditure somewhere. Which is why I priced my books at what I think is a reasonable level.

So sadly color print will not be an option. There will be color diagrams available on the website under the CCIE books menu when its released, probably in PDF or jpg, or both. If anyone has any recommendations then I am all ears.