Archive

Archive for August, 2014

A Quick Look at NAT64 and NAT46

August 26, 2014 3 comments

Introduction

In the best of worlds we would all be using native IPv6 now, or at least dual
stack. That is not the case however and IPv4 will be around for a long time yet.
During that time that both protocols exist, there will be a need to translate
between the two, like it or not.

Different Types of NAT

Before we begin, let’s define some different forms of NAT:

NAT44 – NAT from IPv4 to IPv4
NAT66 – NAT from IPv6 to IPv6
NAT46 – NAT from IPv4 to IPv6
NAT64 – NAT from IPv6 to IPv4

The most commonly used type is definitely NAT44 but here we will focus on translating
between IPv4 and IPv6.

NAT64

There are two different forms of NAT64, stateless and statefull. The stateless version
maps the IPv4 address into an IPv6 prefix. As the name implies, it keeps no state.
It does not save any IP addresses since every v4 address maps to one v6 address.
Here is a comparison of stateless and statefull NAT64:

Stateless_vs_statefull

DNS64

When resolving names to numbers in IPv4, A records are used. When doing the same
in IPv6, AAAA records are used. When using NAT64, the device doing the translation
will translate between A and AAAA records. The function of DNS64 will not be
described further in this post.

Documentation

The configuration guides at Cisco.com are pretty poorly written and there is
not much else to find on configuring NAT64 on ASA. That’s always one of my goals
with a blog post, to learn a topic and to help spread knowledge into the networking
community.

The Lab

To demonstrate NAT64, the following topology is used:

NAT64_1

The goal is for IOS9 to source traffic from its loopback 2001:db8:0:9::9 to
IOS7 with the IP address 203.0.113.2. The routers have some basic configuration
with IP addresses on the interfaces and static routing.

IOS7:

interface GigabitEthernet0/0
 ip address 203.0.113.2 255.255.255.248
!
ip route 0.0.0.0 0.0.0.0 203.0.113.1

IOS8:

ipv6 unicast-routing
!
interface GigabitEthernet0/0
 ipv6 address 2001:DB8::2/64
!
interface GigabitEthernet0/1
 ipv6 address 2001:DB8:0:1::2/64
!
ipv6 route 2001:DB8:0:9::9/128 2001:DB8:0:1::1
ipv6 route ::/0 2001:DB8::1

IOS9:

ipv6 unicast-routing
interface Loopback0
 ipv6 address 2001:DB8:0:9::9/64
!
interface GigabitEthernet0/0
 ipv6 address 2001:DB8:0:1::1/64
!
ipv6 route ::/0 2001:DB8:0:1::2

The ASA is the device that will be doing the NAT64. It has one IPv4 interface and
one IPv6 interface. It starts with the following configuration:

ASA1:

interface GigabitEthernet0/0
 nameif inside
 security-level 100
 ip address 203.0.113.1 255.255.255.248 
!
interface GigabitEthernet0/1
 nameif outside
 security-level 0
 no ip address
 ipv6 address 2001:db8::1/64
!
access-list outside extended permit icmp6 any any 
!
ipv6 route outside 2001:db8:0:9::9/128 2001:db8::2

In newer versions of ASA code, unified ACL is supported. That means we can have
both IPv4 and IPv6 in the same ACL. In my ACL I am allowing ICMPv6 to come in
on the “outside” interface.

To translate between IPv6 and IPv4, NAT must be configured. Both object NAT and
twice NAT is supported but I prefer twice NAT, so that is what I will configure.

When pinging from IOS9, we need to define an address that will represent IOS7 (IPv6).
This is the destination of the packet. The source address of IOS9 needs to be translated
to an IPv4 address as well. This picture will show the flow of the traffic:

Traffic_flow

Time to configure the ASA. The traffic flow is coming in on the interface “outside”
and exiting on interface “inside”. We need to define network objects, try to name
them properly because otherwise it can be confusing to understand the traffic flow.

object network REALv6_OUTSIDE
host 2001:db8:0:9::9
object network MAPPED_IPv4_INSIDE
host 192.0.2.1
object network MAPPED_IPv6_OUTSIDE
host 2001:db8:0:a::2
object network REALv4_INSIDE
host 203.0.113.2
nat (outside,inside) source static REALv6_OUTSIDE MAPPED_IPv4_INSIDE destination 
static MAPPED_IPv6_OUTSIDE REALv4_INSIDE net-to-net

The syntax can be a bit confusing so let’s take a closer look:

REALv6_OUTSIDE – This is the source IP(v6) of IOS9
MAPPED_IPv4_INSIDE – This is what IOS9 gets translated to on the inside
MAPPED_IPv6_OUTSIDE – This is the destination IOS9 is sending traffic to
REALv4_INSIDE – This is what the destination gets translated to on the inside

To test our setup, we will ping from IOS9:

IOS9#ping 2001:DB8:0:A::2 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:0:A::2, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:0:9::9
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/11 ms
IOS7#debug ip icmp
ICMP packet debugging is on
IOS7#
*Aug 26 07:28:27.786: ICMP: echo reply sent, src 203.0.113.2, dst 192.0.2.1, topology BASE, dscp 0 topoid 0
*Aug 26 07:28:27.796: ICMP: echo reply sent, src 203.0.113.2, dst 192.0.2.1, topology BASE, dscp 0 topoid 0
*Aug 26 07:28:27.802: ICMP: echo reply sent, src 203.0.113.2, dst 192.0.2.1, topology BASE, dscp 0 topoid 0
*Aug 26 07:28:27.810: ICMP: echo reply sent, src 203.0.113.2, dst 192.0.2.1, topology BASE, dscp 0 topoid 0
*Aug 26 07:28:27.811: ICMP: echo reply sent, src 203.0.113.2, dst 192.0.2.1, topology BASE, dscp 0 topoid 0

That worked! Let’s take a look at the XLATE table:

ASA1#  show xlate
2 in use, 2 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net
NAT from outside:2001:db8:0:9::9/128 to inside:192.0.2.1
    flags sTN idle 0:01:04 timeout 0:00:00
NAT from inside:203.0.113.2 to outside:2001:db8:0:a::2/128
    flags sTN idle 0:01:04 timeout 0:00:00

That was ICMP. How about TCP? We need to allow TCP through the firewall.

ASA1(config)# access-list outside permit tcp any any
IOS7(config)#username nat password nat
IOS7(config)#line vty 0 4
IOS7(config-line)#login local
IOS9#telnet 2001:DB8:0:A::2 /source-interface lo0
Trying 2001:DB8:0:A::2 ... Open

User Access Verification

Username: 

No matter what you think of NAT, that is pretty cool!

ASA1# show conn
1 in use, 4 most used

TCP outside  192.0.2.1(2001:db8:0:9::9):16809 inside  203.0.113.2:23, idle 0:00:43, bytes 2805, flags UIOB

ASA1# show nat det
Manual NAT Policies (Section 1)
1 (outside) to (inside) source static REALv6_OUTSIDE MAPPED_IPv4_INSIDE   destination static MAPPED_IPv6_OUTSIDE REALv4_INSIDE net-to-net
    translate_hits = 6, untranslate_hits = 24
    Source - Origin: 2001:db8:0:9::9/128, Translated: 192.0.2.1/32
    Destination - Origin: 2001:db8:0:a::2/128, Translated: 203.0.113.2/32

This was NAT64 in action. With our NAT we were doing one to one translation
between IPv6 and IPv4. If IPv4 addresses are scarce, we can define a NAT
pool and translate to that.

ASA1(config)# object network IPv4_POOL
ASA1(config-network-object)# range 198.51.100.1 198.51.100.5
ASA1(config-network-object)# exit
ASA1(config)# nat (outside,inside) source dynamic REALv6_OUTSIDE pat-pool IPv4_POOL
destination static MAPPED_IPv6_OUTSIDE REALv4_INSIDE net-to-net
IOS9#telnet 2001:db8:0:a::2 /source-interface lo0
Trying 2001:DB8:0:A::2 ... Open

User Access Verification

Username: 

ASA1# show xlate
2 in use, 3 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net
NAT from inside:203.0.113.2 to outside:2001:db8:0:a::2/128
    flags sTN idle 0:00:42 timeout 0:00:00

TCP PAT from outside:2001:db8:0:9::9/43376 to inside:198.51.100.1/43376 flags ri idle 0:00:42 timeout 0:00:30
ASA1# show nat detail
Manual NAT Policies (Section 1)
1 (outside) to (inside) source dynamic REALv6_OUTSIDE pat-pool IPv4_POOL  destination static MAPPED_IPv6_OUTSIDE REALv4_INSIDE net-to-net
    translate_hits = 9, untranslate_hits = 10
    Source - Origin: 2001:db8:0:9::9/128, Translated (PAT): 198.51.100.1-198.51.100.5
    Destination - Origin: 2001:db8:0:a::2/128, Translated: 203.0.113.2/32

ASA1# show conn
1 in use, 4 most used

TCP outside  198.51.100.1(2001:db8:0:9::9):20135 inside  203.0.113.2:23, idle 0:00:01, bytes 1382, flags UIOB 

The source got translated to 198.51.100.1 through PAT.

Conclusion

IPv6 is here to stay, but so is also IPv4 for a long time to come. Personal
opinions aside, we may need to translate between IPv6 and IPv4 for a time to
come. Knowing how to configure NAT64 is just another tool in our belt.

Categories: IPv6, NAT Tags: , , ,

A Quick Look at MPLS-TE

August 24, 2014 4 comments

Introduction

I’m currently designing and implementing a large network which will run MPLS.
This network will replace an old network that was mainly L2 based and did not
run MPLS, only VRF lite. There are a few customers that need to have diverse
paths in the network and quick convergence when a failure occurs.
This led me to consider MPLS-TE for those customers and to have plain MPLS
through LDP for other customers buying VPNs. What is the usage for MPLS-TE?

Weaknesses of IGP

When using normal IP forwarding a least cost path is calculated through an IGP,
such as OSPF or ISIS. The problem though is that only the least cost path will
be utilized, any links not on the best path will sit idle, which is a waste of
bandwidth. IGP metrics can be manipulated but that only moves the problem to
other links, it does not solve the root cause. Manipulating metrics is cumbersome
and prone to error. It’s difficult to think of all the traffic flows in the network
and get all the metrics correct. IGPs also lack the granularity in metrics to
utilize all the bandwidth in the network.

RSVP-TE

RSVP in the past was a protocol used for quality of service in the Intserv model.
It never got a lot of traction due to scalability issues of keeping state in the
core of the network. RSVP was modified to support MPLS and that protocol is known
as RSVP-TE. RSVP-TE provides support for:

  • Explicit path configuration
  • Path numbering
  • Route recording

RSVP assigns labels to the LSPs. The headend of the tunnel sends PATH messages
towards the tailend and then from the tailend back, RESV messages are sent together
with a label to use for the LSP.

RSVP-TE1

Constrained SPF (CSPF)

To overcome the limitations of IGPs mentioned above in the post, the SPF algorithm has
to be modified. This is called Constrained SPF (CSPF) and besides a simple metric it
can take other factors into account such as:

  • Bandwidth
  • Affinity
  • Administrative weight
  • Explicitly defined path

To support this modified SPF algorithm and to carry the information needed in the
LSU/LSP, the IGPs have been modified to support this. OSPF supports TE by using
an opaque LSA. ISIS which is easily modifiable with TLVs, supports TE through a new
TLV. When using ISIS as the IGP, a wide style metric must be used to support TE.

The CSPF path can either be calculated dynamically by the router or the user can
configure an explicit path. Both methods support the use of constraints to build
the path.

Routing Across an TE Tunnel

Once the tunnel has been built, traffic must be sent through the tunnel.
This can be achieved in a couple of different ways:

  • Static routing
  • Dynamic routing
  • Policy-based routing

The Lab

That was a brief overview of MPLS-TE. To test this out in a lab I have setup a
topology like this:

MPLS-TE1

All routers are running IOS except for one router. This is to show the syntax of
IOS-XR and for me to practice using it. IOS1 and IOS6 advertise their loopbacks to
the PE routers. Normal routing has been setup as well as MPLS and BGP. This is the
configuration so far:

IOS1:

router bgp 1
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 network 11.11.11.11 mask 255.255.255.255
 neighbor 12.12.12.1 remote-as 100

IOS2:

ip vrf CUST_1
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip router isis backbone
!
interface Loopback1
 ip address 22.22.22.22 255.255.255.255
 ip router isis backbone
!
interface GigabitEthernet0/0
 ip vrf forwarding CUST_1
 ip address 12.12.12.1 255.255.255.254
! 
interface GigabitEthernet0/1
 ip address 23.23.23.0 255.255.255.254
 ip router isis backbone
 mpls ip
 isis circuit-type level-2-only
!
interface GigabitEthernet0/2
 ip address 25.25.25.0 255.255.255.254
 ip router isis backbone
 mpls ip
 isis circuit-type level-2-only
!
router isis backbone
 net 49.0001.0002.0002.0002.0002.00
 is-type level-2-only
 metric-style wide
 passive-interface default
 no passive-interface GigabitEthernet0/1
 no passive-interface GigabitEthernet0/2
!
router bgp 100
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 7.7.7.7 remote-as 100
 neighbor 7.7.7.7 update-source Loopback0
 !        
 address-family vpnv4
  neighbor 7.7.7.7 activate
  neighbor 7.7.7.7 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf CUST_1
  neighbor 12.12.12.0 remote-as 1
  neighbor 12.12.12.0 activate
  neighbor 12.12.12.0 as-override
!
mpls ldp router-id Loopback0 force

XR1:

vrf CUST_1
 address-family ipv4 unicast
  import route-target
   1:1
  !
  export route-target
   1:1
  !
 !
!
interface Loopback0
 ipv4 address 7.7.7.7 255.255.255.255
!
interface GigabitEthernet0/0/0/0
 ipv4 address 47.47.47.1 255.255.255.254
!
interface GigabitEthernet0/0/0/1
 ipv4 address 57.57.57.1 255.255.255.254
!
interface GigabitEthernet0/0/0/2
 vrf CUST_1
 ipv4 address 76.76.76.1 255.255.255.254
!
route-policy PASS
  pass
end-policy
!
router isis backbone
 is-type level-2-only
 net 49.0001.0007.0007.0007.0007.00
 address-family ipv4 unicast
  metric-style wide
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/0
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/1
  address-family ipv4 unicast
  !
 !
!
router bgp 100
 bgp router-id 7.7.7.7
 address-family ipv4 unicast
 !
 address-family vpnv4 unicast
 !
 neighbor 2.2.2.2
  remote-as 100
  update-source Loopback0
  address-family vpnv4 unicast
  !
 !
 vrf CUST_1
  rd 1:1
  address-family ipv4 unicast
  !
  neighbor 76.76.76.0
   remote-as 1
   address-family ipv4 unicast
 route-policy PASS in
    route-policy PASS out
    as-override
   !
  !
 !
!
mpls ldp
 router-id 7.7.7.7
 interface GigabitEthernet0/0/0/0
  address-family ipv4
  !
 !
 interface GigabitEthernet0/0/0/1
  address-family ipv4

IOS6:

interface Loopback0
 ip address 6.6.6.6 255.255.255.255
!
interface Loopback1
 ip address 66.66.66.66 255.255.255.255
!
router bgp 1
 bgp log-neighbor-changes
 network 6.6.6.6 mask 255.255.255.255
 network 66.66.66.66 mask 255.255.255.255
 neighbor 76.76.76.1 remote-as 100

The other configuration has been left out, it’s just plain IGP routing and enabling MPLS.
The lab is currently using MPLS VPN and taking the upper path due to the IGP path
being shorter. Let’s confirm this with a traceroute.

IOS1#traceroute 6.6.6.6 numeric source lo0
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
  1 12.12.12.1 1 msec 0 msec 0 msec
  2 25.25.25.1 [MPLS: Labels 24/16012 Exp 0] 8 msec 9 msec 4 msec
  3 57.57.57.1 [MPLS: Label 16012 Exp 0] 23 msec 5 msec 8 msec
  4 76.76.76.0 2 msec *  2 msec

The traceroute confirms this.

MPLS-TE tunnels are always unidirectional. To configure MPLS-TE we need to
go through the following steps:

  • Enable CEF (default)
  • Enable TE support in IGP
  • Enable MPLS-TE tunnels globally
  • Enable MPLS-TE tunnels on interface(s) in path
  • Enable RSVP on interface(s) in path

The following configuration is added to all IOS routers:

IOS2(config)#mpls traffic-eng tunnels 
IOS2(config)#int range gi0/1 - 2
IOS2(config-if-range)#mpls traffic-eng tunnels
IOS2(config-if-range)#ip rsvp bandwidth
IOS2(config-if-range)#router isis backbone
IOS2(config-router)#metric-style wide
IOS2(config-router)#mpls traffic-eng level-2
IOS2(config-router)#mpls traffic-eng router-id lo0

The following configuration is added to the IOS-XR router:

router isis backbone
 address-family ipv4 unicast 
  metric-style wide 
  mpls traffic-eng level-2-only 
  mpls traffic-eng router-id Loopback0 
rsvp 
 interface GigabitEthernet0/0/0/0
 ! 
 interface GigabitEthernet0/0/0/1
 ! 
mpls traffic-eng 
 interface GigabitEthernet0/0/0/0
 ! 
 interface GigabitEthernet0/0/0/1

This is enough to have ISIS support MPLS-TE. From the IOS-XR router we can
see that the IGP is now carrying more information in the LSPs.

RP/0/0/CPU0:ios#show mpls traffic-eng topology 
Sun Aug 24 17:16:57.583 UTC
My_System_id: 0007.0007.0007.00 (IS-IS backbone level-2)
My_BC_Model_Type: RDM 

Signalling error holddown: 10 sec Global Link Generation 19

IGP Id: 0002.0002.0002.00, MPLS TE Id: 2.2.2.2 Router Node  (IS-IS backbone level-2)

  Link[0]:Broadcast, DR:0002.0002.0002.01, Nbr Node Id:12, gen:10
      Frag Id:0, Intf Address:23.23.23.0, Intf Id:0
      Nbr Intf Address:0.0.0.0, Nbr Intf Id:0
      TE Metric:10, IGP Metric:10
      Attribute Flags: 0x0
      Ext Admin Group: 
          Length: 256 bits
          Value : 0x::
      Attribute Names: 
      Switching Capability:None, Encoding:unassigned
      BC Model ID:RDM
      Physical BW:1000000 (kbps), Max Reservable BW Global:750000 (kbps)
      Max Reservable BW Sub:0 (kbps)
                                 Global Pool       Sub Pool
               Total Allocated   Reservable        Reservable
               BW (kbps)         BW (kbps)         BW (kbps)
               ---------------   -----------       ----------
        bw[0]:            0         750000                0
        bw[1]:            0         750000                0
        bw[2]:            0         750000                0
        bw[3]:            0         750000                0
        bw[4]:            0         750000                0
        bw[5]:            0         750000                0
        bw[6]:            0         750000                0
        bw[7]:            0         750000                0

The next step is to create the tunnel. We will build a tunnel from IOS2 to XR1.

interface Tunnel0 
 ip unnumbered Loopback0 
 tunnel mode mpls traffic-eng 
 tunnel destination 7.7.7.7 
 tunnel mpls traffic-eng autoroute announce 
 tunnel mpls traffic-eng path-option 10 dynamic 
interface tunnel-te0 
 ipv4 unnumbered Loopback0 
 autoroute announce 
 destination 2.2.2.2 
 path-option 10 dynamic 

Autoroute announce is used to advertise the tunnel into the IGP. Another option
would be a static route for the tunnel destination across the tunnel interface.

The tunnel is now up and traffic is forwarding across it.

IOS1#traceroute 6.6.6.6 numeric so lo0
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
  1 12.12.12.1 1 msec 0 msec 0 msec
  2 25.25.25.1 [MPLS: Labels 19/16012 Exp 0] 8 msec 1 msec 3 msec
  3 57.57.57.1 [MPLS: Label 16012 Exp 0] 2 msec 3 msec 7 msec
  4 76.76.76.0 9 msec *  3 msec

The label 19 is the label used for the tunnel and label 16012 is the VPN label.
We are still using the upper path though. Let’s configure an explicit path to
use the lower path of the topology.

ip explicit-path name TO_XR1 enable 
 next-address 23.23.23.1 
 next-address 34.34.34.1 
 next-address 47.47.47.1 
! 
interface Tunnel0 
 tunnel mpls traffic-eng path-option 1 explicit name TO_XR1 
explicit-path name TO_IOS2
 index 1 next-address strict ipv4 unicast 47.47.47.0 
 index 2 next-address strict ipv4 unicast 34.34.34.0 
 index 3 next-address strict ipv4 unicast 23.23.23.0 
interface tunnel-te0 
path-option 1 explicit name TO_IOS2

We try a traceroute from IOS1 to see if the traffic is following the lower path.

IOS1#traceroute 6.6.6.6 numeric so lo0
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
  1 12.12.12.1 1 msec 0 msec 0 msec
  2 23.23.23.1 [MPLS: Labels 19/16012 Exp 0] 5 msec 2 msec 2 msec
  3 34.34.34.1 [MPLS: Labels 21/16012 Exp 0] 2 msec 2 msec 4 msec
  4 47.47.47.1 [MPLS: Label 16012 Exp 0] 1 msec 3 msec 1 msec
  5 76.76.76.0 3 msec *  2 msec

This is the power of MPLS-TE. The ability to from the headend, define where
the traffic should go. This is essentially source routing. There are also new
features coming out such as segment routing which does something similar by
extending OSPF and ISIS and generating labels through the IGP.

What happens if the explicit path goes down? We can use a dynamic path as a
fallback by setting it to a higher ID in our tunnel configuration.
This is the current configuration of the tunnel:

interface Tunnel0
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 7.7.7.7
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 explicit name TO_XR1
 tunnel mpls traffic-eng path-option 10 dynamic

We will initiate a ping from IOS1, then I will shutdown IOS4 interface towards IOS3.
Traffic should then go over the upper path again.

IOS1#ping 6.6.6.6 so lo0 re 100000
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (2876/2878), round-trip min/avg/max = 1/3/22 ms
IOS1# 

Only a single packet was lost. We confirm on IOS2 that the secondary path
is being used.

IOS2#show mpls traffic-eng tunnels 

Name: IOS2_t0                             (Tunnel0) Destination: 7.7.7.7
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 10, type dynamic (Basis for Setup, path weight 20)
    path option 1, type explicit TO_XR1

IOS1 is using the upper path again.

IOS1#traceroute 6.6.6.6 numeric so lo0
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
  1 12.12.12.1 2 msec 0 msec 0 msec
  2 25.25.25.1 [MPLS: Labels 19/16012 Exp 0] 8 msec 8 msec 6 msec
  3 57.57.57.1 [MPLS: Label 16012 Exp 0] 2 msec 6 msec 10 msec
  4 76.76.76.0 1 msec *  2 msec

Conclusion

MPLS-TE can help overcome some of the limitations that come bundled with
IGPs, such as not utilizing links and not being able to consider constraints,
solely relying on a metric that says nothing about the bandwidth available.
MPLS-TE can be used to provide fast convergence by defining several path options.
It can also be combined with FRR to provide convergence times around 50ms.

Categories: MPLS Tags: , , , ,

400k Views in 4 Years – A Review of My Last 4 Years

August 16, 2014 14 comments

Very often in our lives we are fully focused on what is going to happen in the
future. We rarely look back at what we have done and how we got to where we
are now. People that know me, know that I’m a very focused person that is always
looking to improve my skillset.

In July of 2010 I decided that I wanted to become a CCIE. I was a CCNP at that
time and I was working in a role where I did 2nd level support. I decided that
I wanted to blog to keep my notes for the CCIE online. I wrote my first blog
post on July 16, 2010. Today on August 16, 2014, almost four years later I passed
400k views on the blog. It’s been an amazing journey and here is a look back at
what has happened since then. This post is meant to be inspirational, to see
what can be accomplished in four years if you put your heart to it, please don’t
take it as boasting 🙂

For my CCIE studies I used INE workbooks, I decided that it would be good practice
to answer questions on their forums to keep all topics current. That led to
several awards as the top contributor, a few goodies and friends that I still
interact with.

In 2011 I changed jobs and became a senior network consultant.

I passed the lab in 2012, almost two years ago now. Passing the lab has been a great
boost for the career. I have noticed an increased respect and I usually get assignments
that are interesting and challenging.

After passing the lab I wanted to give back to the community. That led me to the
Cisco Learning Network. I try to help out in the forums and I have also been the instructor
for member led sessions where I have taught Spanning Tree and OSPF. I have been awarded
the technical excellence award and I am also now a Cisco Learning Network VIP.
This took me to my first Cisco Live, in San Francisco. Through CLN I’ve had the pleasure
of learning to know a lot of great people at Cisco.

I learned that there was a program called the Cisco Champions. This seemed interesting to
me and as I already was active in the networking community, I decided to apply.
I was happy to get accepted into the program and it has been great so far. I’ve met a lot
of interesting people and it took me to the first row of the keynotes of Cisco Live.
Not a bad place to be in 🙂

Today I’m still a senior network consultant, these days I’m working with network
design and as a subject matter expert for different customers. I am about to design and
implement a large network together with two of my colleagues based on ASR9k.

I want to thank all of my readers for sticking around and I hope you have had a
great four years as well.

Categories: Announcement Tags: , , ,