Category Archives: CCDE - Page 2

Upcoming webinar with Daniel Dib

Just wanted to let you know that Daniel from lostintransit.se is doing a webinar on network design. I will be attending and helping out any way i can.

Go here to learn more: https://learningnetwork.cisco.com/blogs/community_cafe/2015/01/21/network-design-fundamentals-webinar-with-ciscovip-daniel-dib

Unified/Seamless MPLS

In this post I would like to highlight a relative new (to me) application of MPLS called Unified MPLS.
The goal of Unified MPLS is to separate your network into individual segments of IGP’s in order to keep your core network as simple as possible while still maintaining an end-to-end LSP for regular MPLS applications such as L3 VPN’s.

What we are doing is simply to put Route Reflectors into the forwarding path and changing the next-hop’s along the way, essentially stiching together the final LSP.
Along with that we are using BGP to signal a label value to maintain the LSP from one end of the network to the other without the use of LDP between IGP’s.

Take a look at the topology that we will be using to demonstrate this feature:

Unified-MPLS-Topology

In this topology we have a simplified layout of a service provider. We have a core network consisting of R3, R4 and R5 along with distribution networks on the right and left of the core. R2 and R3 is in the left distribution and R5 and R6 is in the right hand side one.

We have an MPLS L3VPN customer connected consisting of R1 in one site and R7 in another.

As is visisible in the topology, we are running 3 separate IGP’s to make a point about this feature. EIGRP AS 1, OSPF 100 and EIGRP AS 2. However we are only running one autonomous system as seen from BGP, so its a pure iBGP network.

Now in order to make the L3VPN to work, we need to have an end-to-end LSP going from R2 all the way to R6.
Whats is key here is that in order to have end-to-end reachability, we have contained IGP areas, each of which is running LDP for labels. However between the areas, all we are doing is leaking a couple of loopback adresses into the distribution sections from the core. These are used exclusively for the iBGP session.

On top of that, we need to have R3 and R5 being route-reflectors, have them being in the data path as well as having them allocating labels. This is done through the “send-label” command along with modifying the next-hop (“next-hop-self all” command).

This is illustrated in the following:

Unified-MPLS-iBGP-Topology

Enough theory, lets take a look at the configuration nessecary to pull this of. Lets start out with R2’s IGP and LDP configuration:

R2#sh run | sec router eigrp
router eigrp 1
 network 2.0.0.0
 network 10.0.0.0
 passive-interface default
 no passive-interface GigabitEthernet3

R2#sh run int g3
interface GigabitEthernet3
 ip address 10.2.3.2 255.255.255.0
 negotiation auto
 mpls ip
end

Pretty vanilla configuration of IGP + LDP.

The same for R3:

R3#sh run | sec router eigrp 1
router eigrp 1
 network 10.0.0.0
 redistribute ospf 100 metric 1 1 1 1 1 route-map REDIST-LOOPBACK-MAP
 passive-interface default
 no passive-interface GigabitEthernet2

R3#sh run int g2
interface GigabitEthernet2
 ip address 10.2.3.3 255.255.255.0
 negotiation auto
 mpls ip
end

R3#sh route-map REDIST-LOOPBACK-MAP
route-map REDIST-LOOPBACK-MAP, permit, sequence 10
  Match clauses:
    ip address prefix-lists: REDIST-LOOPBACK-PREFIX-LIST
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes

R3#sh ip prefix-list
ip prefix-list REDIST-LOOPBACK-PREFIX-LIST: 1 entries
   seq 5 permit 3.3.3.3/32

Apart from the redistribution part, its simply establishing an EIGRP adjacency with R2. On top of that we are redistributing R3’s loopback0 interface, which is in the Core area, into EIGRP. Again, this step is nessecary for the iBGP session establishment.

An almost identical setup is present in the other distribution site, consisting of R5 and R6. Again we redistribute R5’s loopback0 address into the IGP (EIGRP AS 2), so we can have iBGP connectivity, which is our next step.

So lets take a look at the BGP configuration on R2 all the way to R6. Im leaving out the VPNv4 configuration for now, in order to make it more visible what we are trying to accomplish first:

R2:
---
router bgp 1000
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 1000
 neighbor 3.3.3.3 update-source Loopback0
 !
 address-family ipv4
  network 2.2.2.2 mask 255.255.255.255
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-label

R3:
---
router bgp 1000
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 1000
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 route-reflector-client
 neighbor 2.2.2.2 next-hop-self all
 neighbor 2.2.2.2 send-label
 neighbor 5.5.5.5 remote-as 1000
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 5.5.5.5 route-reflector-client
 neighbor 5.5.5.5 next-hop-self all
 neighbor 5.5.5.5 send-label

R5:
---
router bgp 1000
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 1000
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 route-reflector-client
 neighbor 3.3.3.3 next-hop-self all
 neighbor 3.3.3.3 send-label
 neighbor 6.6.6.6 remote-as 1000
 neighbor 6.6.6.6 update-source Loopback0
 neighbor 6.6.6.6 route-reflector-client
 neighbor 6.6.6.6 next-hop-self all
 neighbor 6.6.6.6 send-label

R6:
---
router bgp 1000
 bgp router-id 6.6.6.6
 bgp log-neighbor-changes
 neighbor 5.5.5.5 remote-as 1000
 neighbor 5.5.5.5 update-source Loopback0
 !
 address-family ipv4
  network 6.6.6.6 mask 255.255.255.255
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-label

As visible from the configuration. We have 2 IPv4 route-reflectors (R3 and R5), both of which put themselves into the datapath by using the next-hop-self command. On top of that we are allocating labels for all prefixes via BGP as well. Lets verify this on the set:

R2#sh bgp ipv4 uni la
   Network          Next Hop      In label/Out label
   2.2.2.2/32       0.0.0.0         imp-null/nolabel
   6.6.6.6/32       3.3.3.3         nolabel/305

R3#sh bgp ipv4 uni la
   Network          Next Hop      In label/Out label
   2.2.2.2/32       2.2.2.2         300/imp-null
   6.6.6.6/32       5.5.5.5         305/500

R5#sh bgp ipv4 uni la
   Network          Next Hop      In label/Out label
   2.2.2.2/32       3.3.3.3         505/300
   6.6.6.6/32       6.6.6.6         500/imp-null

 R6#sh bgp ipv4 uni la
    Network          Next Hop      In label/Out label
    2.2.2.2/32       5.5.5.5         nolabel/505
    6.6.6.6/32       0.0.0.0         imp-null/nolabel

Since we are only injecting 2 prefixes (loopbacks of R2 and R6) into BGP, thats all we have allocated labels for.

Doing a traceroute from R2 to R6 (between loopbacks), will reveal if we truly have an LSP between them:

R2#traceroute 6.6.6.6 so loo0
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
  1 10.2.3.3 [MPLS: Label 305 Exp 0] 26 msec 15 msec 18 msec
  2 10.3.4.4 [MPLS: Labels 401/500 Exp 0] 10 msec 24 msec 34 msec
  3 10.4.5.5 [MPLS: Label 500 Exp 0] 7 msec 23 msec 24 msec
  4 10.5.6.6 20 msec *  16 msec

This looks exactly like we wanted it to. (note that the 401 label is on a pure P router in the core).
This also means we can setup our VPNv4 configuration on R2 and R6:

R2#sh run | sec router bgp
router bgp 1000
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 1000
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 6.6.6.6 remote-as 1000
 neighbor 6.6.6.6 update-source Loopback0
 !
 address-family ipv4
  network 2.2.2.2 mask 255.255.255.255
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-label
  no neighbor 6.6.6.6 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 6.6.6.6 activate
  neighbor 6.6.6.6 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf CUSTOMER-A
  redistribute connected
  redistribute static
 exit-address-family
R2#

R6#sh run | sec router bgp
router bgp 1000
 bgp router-id 6.6.6.6
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 1000
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 5.5.5.5 remote-as 1000
 neighbor 5.5.5.5 update-source Loopback0
 !
 address-family ipv4
  network 6.6.6.6 mask 255.255.255.255
  no neighbor 2.2.2.2 activate
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-label
 exit-address-family
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf CUSTOMER-A
  redistribute connected
  redistribute static
 exit-address-family

Lets verify that the iBGP VPNv4 peering is up and running:

R2#sh bgp vpnv4 uni all sum
..
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
6.6.6.6         4         1000      16      16       11    0    0 00:09:31        2

R6#sh bgp vpnv4 uni all sum
..
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4         1000      17      17       11    0    0 00:10:26        2

We do have the prefixes and we should also have reachability from R1 to R7 (by way of their individual static default routes):

R1#ping 7.7.7.7 so loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 17/27/54 ms

Looks good, lets check the label path:

R1#traceroute 7.7.7.7 so loo0
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.2.2 19 msec 13 msec 12 msec
  2 10.2.3.3 [MPLS: Labels 305/600 Exp 0] 18 msec 19 msec 15 msec
  3 10.3.4.4 [MPLS: Labels 401/500/600 Exp 0] 12 msec 32 msec 34 msec
  4 10.4.5.5 [MPLS: Labels 500/600 Exp 0] 20 msec 27 msec 27 msec
  5 10.6.7.6 [MPLS: Label 600 Exp 0] 23 msec 15 msec 13 msec
  6 10.6.7.7 25 msec *  16 msec

What we are seeing here is basically the same path, but with the “VPN” label first (label 600).

So what have we really accomplished here? – Well, lets take a look at the RIB on R2 and look for the IGP (EIGRP AS 1) routes:

R2#sh ip route eigrp
..
      3.0.0.0/32 is subnetted, 1 subnets
D EX     3.3.3.3 [170/2560000512] via 10.2.3.3, 00:16:02, GigabitEthernet3
      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D        10.3.4.0/24 [90/3072] via 10.2.3.3, 00:16:02, GigabitEthernet3

A very small table indeed. And if we include whats being learned by BGP:

R2#sh ip route bgp
..
      6.0.0.0/32 is subnetted, 1 subnets
B        6.6.6.6 [200/0] via 3.3.3.3, 00:17:02

R2#sh ip route 6.6.6.6
Routing entry for 6.6.6.6/32
  Known via "bgp 1000", distance 200, metric 0, type internal
  Last update from 3.3.3.3 00:17:43 ago
  Routing Descriptor Blocks:
  * 3.3.3.3, from 3.3.3.3, 00:17:43 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: 305

Only 1 prefix to communicate with the remote distribution site’s PE router (which we need the label for).

This means you can scale your distribution sites to very large sizes, keep your core as effecient as possible and eliminate using areas and whatnot in your IGP’s.

I hope its been useful with this quick walkthrough of unified/seamless MPLS.

Using LISP for IPv6 tunnelling.

In this post I would like to show how its possible to use a fairly new protocol, LISP, to interconnect IPv6 islands over an IPv4 backbone/core network.

LISP stands for Locator ID Seperation Protocol. As the name suggest, its actually meant to decouple location from identity. This means it can be used for such cool things as mobility, being VM’s or a mobile data connection.

However another aspect of using LISP involves its tunneling mechanism. This is what I will be using in my example to provide the IPv6 islands the ability to communicate over the IPv4-only backbone.

There is alot of terminology involved with LISP, but i will only use some of them here for clarity. If you want to know more about LISP, a good place to start is http://lisp.cisco.com.

The topology i will be using is a modified version of one presented in a Cisco Live presentation called “BRKRST-3046 – Advanced LISP – Whats in it for me?”. I encourage you to view this as well for more information.

Here is the topology:

LISP-IPv6-Topology

Some background information about the setup. Both Site 1 and Site 2 are using EIGRP as the IGP. Both IPv4 and IPv6 is being routed internally. A default route is created by R2, R3 and R6 in their respective sites.

The RIB on R1 for both IPv4 and IPv6:

R1#sh ip route eigrp | beg Gateway
Gateway of last resort is 172.16.10.3 to network 0.0.0.0

D*EX  0.0.0.0/0 [170/2560000512] via 172.16.10.3, 1d00h, GigabitEthernet1.100
                [170/2560000512] via 172.16.10.2, 1d00h, GigabitEthernet1.100
R1#sh ipv6 route eigrp
<snip>
EX  ::/0 [170/2816]
     via FE80::250:56FF:FEBE:675D, GigabitEthernet1.100
     via FE80::250:56FF:FEBE:9215, GigabitEthernet1.100

And R7:

R7#sh ip ro eigrp | beg Gateway
Gateway of last resort is 172.16.20.6 to network 0.0.0.0

D*EX  0.0.0.0/0 [170/2560000512] via 172.16.20.6, 1d00h, GigabitEthernet1.67

R7#sh ipv6 route eigrp
<snip>
EX  ::/0 [170/2816]
     via FE80::250:56FF:FEBE:D054, GigabitEthernet1.67

Now in order to get anywhere, we need to setup our LISP infrastructure. This means configuring R2, R3 and R6 as whats known as RLOC’s as well as configuring R5 as a mapping-server and map-resolver. A mapping server/resolver is where RLOC’s register what internal IP scopes they have in their sites. Its also where each RLOC asks for information on how to reach other sites. So obviously they are a very important part of our LISP setup. Here is the relevant configuration on R5:

router lisp
 site SITE1
  authentication-key blah
  eid-prefix 153.16.1.1/32
  eid-prefix 153.16.1.2/32
  eid-prefix 172.16.10.0/24 accept-more-specifics
  eid-prefix 2001::1/128
  eid-prefix 2001::2/128
  eid-prefix 2001:100::/32 accept-more-specifics
  exit
 !
 site SITE2
  authentication-key blah
  eid-prefix 153.16.2.1/32
  eid-prefix 172.16.20.0/24
  eid-prefix 2001::7/128
  eid-prefix 2001:67::/32 accept-more-specifics
  exit
 !
 ipv4 map-server
 ipv4 map-resolver
 ipv6 map-server
 ipv6 map-resolver

On IOS-XE which is what im using to build this lab, all configuration is being done under the router LISP mode.

As can be seen from the configuration, two sites have been defined, SITE1 and SITE2.
An authentication key has been configured for each site. Furthermore, the prefixes that we want to accept from each site has also been configured. If our addressing scheme had been somewhat more thought out we could use the “accept-more-specifics” to accept more specific subnets, but this configuration serves our purpose.

Pay attention to the fact that we do this for each address-family. For our IPv6 example this is really not nessecary, but i wanted to provide both IPv4 and IPv6 connectivity, so i configured both.

Finally I’ve configured R5 as both a map-server and map-resolver for each address-family.

Next up is the configuration for R2:

R2#sh run | sec router lisp
router lisp
 locator-set SITE1
  10.1.1.1 priority 10 weight 50
  10.1.2.1 priority 10 weight 50
  exit
 !
 database-mapping 153.16.1.1/32 locator-set SITE1
 database-mapping 153.16.1.2/32 locator-set SITE1
 database-mapping 172.16.10.0/24 locator-set SITE1
 database-mapping 2001::1/128 locator-set SITE1
 database-mapping 2001::2/128 locator-set SITE1
 database-mapping 2001:100::/32 locator-set SITE1
 ipv4 itr map-resolver 10.1.3.1
 ipv4 itr
 ipv4 etr map-server 10.1.3.1 key blah
 ipv4 etr
 ipv6 itr map-resolver 10.1.3.1
 ipv6 itr
 ipv6 etr map-server 10.1.3.1 key blah
 ipv6 etr

The first part of this configuration lists a “Locator-Set”. This is where you want to list each RLOC for the site in question. For our SITE1 we have 2 RLOC’s with IPv4 addresses in the IPv4 transport cloud being 10.1.1.1 and 10.1.2.1 respectively for R2 and R3.

One of the very cool things about LISP is how you can achieve redundancy and/or load-balancing signaled by the local RLOC’s. By modifying the priority of R3 (10.1.2.1) to 20, we have effectively told the other site(s) that we want to prefer R2 as the egress tunnel router (ETR), so all traffic would be sent to R2. However if we instead leave the priority to the same and modify the weight, we can load-balance traffic. Again this is signaled by the local site and replicated to the remote site(s).

Next up is our mappings. This is where we define which prefixes we want to use in this site. Here we have the loopbacks of R1 and the network used for connectivity in SITE 1. Both for IPv4 and IPv6. Again IPv4 is not nessecary for our example.

Finally, we define a map-resolver and map-server for both ITR (Ingress Tunnel Router) and ETR (Egress Tunnel Router). This is so we can define where we want to send our mapping data as well as where to ask for other ETR’s. We also define ourselves as ITR and ETR for both address-families.

The exact same configuration has been applied on R3:

R3#sh run | sec router lisp
router lisp
 locator-set SITE1
  10.1.1.1 priority 10 weight 50
  10.1.2.1 priority 10 weight 50
  exit
 !
 database-mapping 153.16.1.1/32 locator-set SITE1
 database-mapping 153.16.1.2/32 locator-set SITE1
 database-mapping 172.16.10.0/24 locator-set SITE1
 database-mapping 2001::1/128 locator-set SITE1
 database-mapping 2001::2/128 locator-set SITE1
 database-mapping 2001:100::/32 locator-set SITE1
 ipv4 itr map-resolver 10.1.3.1
 ipv4 itr
 ipv4 etr map-server 10.1.3.1 key blah
 ipv4 etr
 ipv6 itr map-resolver 10.1.3.1
 ipv6 itr
 ipv6 etr map-server 10.1.3.1 key blah
 ipv6 etr

Now for some verification commands on R2:

R2#sh ip lisp
  Instance ID:                      0
  Router-lisp ID:                   0
  Locator table:                    default
  EID table:                        default
  Ingress Tunnel Router (ITR):      enabled
  Egress Tunnel Router (ETR):       enabled
  Proxy-ITR Router (PITR):          disabled
  Proxy-ETR Router (PETR):          disabled
  NAT-traversal Router (NAT-RTR):   disabled
  Mobility First-Hop Router:        disabled
  Map Server (MS):                  disabled
  Map Resolver (MR):                disabled
  Delegated Database Tree (DDT):    disabled
  Map-Request source:               10.1.1.1
  ITR Map-Resolver(s):              10.1.3.1
  ETR Map-Server(s):                10.1.3.1 (00:00:50)
  xTR-ID:                           0xA7F25A1D-0x982B7E10-0xDD2D66CC-0x436D28A5
  site-ID:                          unspecified
  ITR Solicit Map Request (SMR):    accept and process
    Max SMRs per map-cache entry:   8 more specifics
    Multiple SMR suppression time:  20 secs
  ETR accept mapping data:          disabled, verify disabled
  ETR map-cache TTL:                1d00h
  Locator Status Algorithms:
    RLOC-probe algorithm:           disabled
    LSB reports:                    process
    IPv4 RLOC minimum mask length:  /0
    IPv6 RLOC minimum mask length:  /0
  Static mappings configured:       0
  Map-cache size/limit:             1/1000
  Imported route count/limit:       0/1000
  Map-cache activity check period:  60 secs
  Map-cache FIB updates:            established
  Total database mapping size:      3
    static database size/limit:     3/5000
    dynamic database size/limit:    0/1000
    route-import database size:     0
  Persistent map-cache:             interval 01:00:00
    Earliest next store:            now
    Location:                       bootflash:LISP-MapCache-IPv4-00000000-00100

Lots of output. But pay attention to the fact that both ITR and ETR has been enabled and ITR Map-Resolver(s) and ETR Map-Server(s) has been defined to 10.1.3.1 (R5).

We also want to verify our current map-cache which is the cache maintained by the RLOC’s for what it already “knows” about:

R2#sh ipv6 lisp map-cache
LISP IPv6 Mapping Cache for EID-table default (IID 0), 1 entries

::/0, uptime: 00:00:01, expires: never, via static send map-request
  Negative cache entry, action: send-map-request

Basically this output tells you that we dont know about any specific networks from other sites just yet.

R6 is very similar to R2 and R3:

R6#sh run | sec router lisp
router lisp
 locator-set SITE2
  10.1.4.1 priority 10 weight 50
  exit
 !
 database-mapping 153.16.2.1/32 locator-set SITE2
 database-mapping 172.16.20.0/24 locator-set SITE2
 database-mapping 2001::7/128 locator-set SITE2
 ipv4 itr map-resolver 10.1.3.1
 ipv4 itr
 ipv4 etr map-server 10.1.3.1 key blah
 ipv4 etr
 ipv6 itr map-resolver 10.1.3.1
 ipv6 itr
 ipv6 etr map-server 10.1.3.1 key blah
 ipv6 etr

And verification:

R6#sh ip lisp
  Instance ID:                      0
  Router-lisp ID:                   0
  Locator table:                    default
  EID table:                        default
  Ingress Tunnel Router (ITR):      enabled
  Egress Tunnel Router (ETR):       enabled
  Proxy-ITR Router (PITR):          disabled
  Proxy-ETR Router (PETR):          disabled
  NAT-traversal Router (NAT-RTR):   disabled
  Mobility First-Hop Router:        disabled
  Map Server (MS):                  disabled
  Map Resolver (MR):                disabled
  Delegated Database Tree (DDT):    disabled
  Map-Request source:               10.1.4.1
  ITR Map-Resolver(s):              10.1.3.1
  ETR Map-Server(s):                10.1.3.1 (00:00:38)
  xTR-ID:                           0xFABA5140-0x6AA2BA6A-0x5F347223-0xF7E0CED0
  site-ID:                          unspecified
  ITR Solicit Map Request (SMR):    accept and process
    Max SMRs per map-cache entry:   8 more specifics
    Multiple SMR suppression time:  20 secs
  ETR accept mapping data:          disabled, verify disabled
  ETR map-cache TTL:                1d00h
  Locator Status Algorithms:
    RLOC-probe algorithm:           disabled
    LSB reports:                    process
    IPv4 RLOC minimum mask length:  /0
    IPv6 RLOC minimum mask length:  /0
  Static mappings configured:       0
  Map-cache size/limit:             1/1000
  Imported route count/limit:       0/1000
  Map-cache activity check period:  60 secs
  Map-cache FIB updates:            established
  Total database mapping size:      2
    static database size/limit:     2/5000
    dynamic database size/limit:    0/1000
    route-import database size:     0
  Persistent map-cache:             interval 01:00:00
    Earliest next store:            now
    Location:                       bootflash:LISP-MapCache-IPv4-00000000-00100

Along with the mapping-cache:

R6#sh ipv6 lisp map-cache
LISP IPv6 Mapping Cache for EID-table default (IID 0), 1 entries

::/0, uptime: 00:00:04, expires: never, via static send map-request
  Negative cache entry, action: send-map-request

If we now try a ping from R1’s loopback0 to R7’s loopback0 we see the following:

R1#ping 2001::7 so loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::7, timeout is 2 seconds:
Packet sent with a source address of 2001::1
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 1/1/1 ms

What this tells us is that we have connectivity, but beyond that it also means that for the 2 first ICMP echo’s, location data is being retrieved. Lets now check the mapping-cache on R2:

R2#sh ipv6 lisp map-cache
LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries

::/0, uptime: 00:01:08, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
2001::7/128, uptime: 00:00:07, expires: 23:59:52, via map-reply, complete
  Locator   Uptime    State      Pri/Wgt
  10.1.4.1  00:00:07  up          10/50

Here we see that 2001::7/128 is currently in the cache and in order to get there we need to tunnel our traffic to the RLOC at 10.1.4.1 (R6).

On the remote side we see something similar:

R6#sh ipv6 lisp map-cache
LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries

::/0, uptime: 00:01:53, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
2001::1/128, uptime: 00:01:34, expires: 23:58:25, via map-reply, complete
  Locator   Uptime    State      Pri/Wgt
  10.1.1.1  00:01:34  up          10/50
  10.1.2.1  00:01:34  up          10/50

This is the mapping that tells R6 that it can use both RLOC’s to send traffic to (They are both in the up state).

If we try a ping from R1 again:

R1#ping 2001::7 so loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::7, timeout is 2 seconds:
Packet sent with a source address of 2001::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/25 ms

We get full connectivity because the cache has already been populated.

Finally lets see what the packet capture looks like on R4:

R4#show monitor capture LISP buffer brief
 -------------------------------------------------------------
 #   size   timestamp     source	     destination   protocol
 -------------------------------------------------------------
   0  154    0.000000   10.1.1.1         ->  10.1.4.1         UDP
   1  154    0.000000   10.1.4.1         ->  10.1.1.1         UDP
   2  154    0.001007   10.1.1.1         ->  10.1.4.1         UDP
   3  154    0.001007   10.1.4.1         ->  10.1.1.1         UDP
   4  154    0.001007   10.1.1.1         ->  10.1.4.1         UDP
   5  154    0.001999   10.1.4.1         ->  10.1.1.1         UDP
   6  154    0.003006   10.1.1.1         ->  10.1.4.1         UDP
   7  154    0.016006   10.1.4.1         ->  10.1.1.1         UDP
   8  154    0.025008   10.1.1.1         ->  10.1.4.1         UDP
   9  154    0.038008   10.1.4.1         ->  10.1.1.1         UDP
  10  162    2.282035   10.1.4.1         ->  10.1.3.1         UDP
  11  162    2.282035   10.1.3.1         ->  10.1.4.1         UDP

(I used an EPC (Embedded Packet Capture) on R4 to get the data).

We clearly see that UDP traffic is flowing between R2 and R6.

So this tunneling characteristic is one way we can utilize LISP, but there are many other use cases as I mentioned before.

I hope this has been useful to you.

Until next time, take care!

EIGRP Query bounding.

In the process of restudying EIGRP as a protocol, and more specifically as to how it converges, you can’t avoid running into the saying “Remember to bound your queries!”.

From a conceptual point of view its fairly easy to understand that the further out you ask for a prefix the longer the convergence process will take. But what really takes place when you have different tools in place to bound the query from taking place?

There are 3 different types of “Query Bounding” techniques that can be utilized:

1) Filters (fx. distribute lists).
2) Summarization
3) Stub routers.

How do they actually work to limit the query scope?

Well, the basic premise for EIGRP queries is the fact that you are asking your fellow EIGRP neighbour for an exact prefix, fx. 172.16.1.0/25. If for any reason you EIGRP neighbour does not have this in his topology table, it will simply respond right away that it doesn’t have a path to this prefix. Query stopped right there.

By using filters such as distribute lists you are removing the prefix from ever getting advertised to the neighbour and as such he will never receive it in his topology table.

Summarization is a little bit different. You are still sending a prefix, however instead of it being a specific prefix, it has now been summarized. In our example, instead of 172.16.1.0/25, it might have been summarized to 172.16.1.0/24. This means that when a query comes in for a lost route to 172.16.1.0/25, the router will again respond that its never had this route in its topology table. Again, the query has been stopped.

Last one is by using stub routers. When the EIGRP adjacency is coming up between two routers, the one thats been configured as a stub router will include this fact in its hello packets and as such the upstream router will know this fact about the adjacency. When the route to 172.16.1.0/25 is lost, the upstream router will already know not to ask the downstream router at all, because by definition its a stub.

But pay close attention, you will see a notable difference between the first two methods of bounding the query scope and the last one. With the first two, the query will still reach one router further downstream before getting replied to. With the last one, it never even propagates that far.

That means from a convergence point of view, that if possible, you are better off by using the “stub” router feature where appropriate. A good example would be toward your access routers in either a 2 or 3 level hierarchy.

Just an observation. Hope it helps!

Change of focus

I have decided to change my focus quite a bit.

I was planning on tackling the IOS-XR exam this year and was preparing for it by going through the blueprint. However another track kept pulling me towards it, and ofcourse thats the CCDE track.

I have spent the last 6 years learning how to do something, but so far i havent spent alot of time thinking about why that is.

I am not doing the CCDE track in order to pass the exam. I might not even go as far as giving the practical exam a go. I am however going to pursue the written exam for now, as it will give me a target for which to learn new stuff.

To that end, a few of us have created a study group, which im very thrilled about. It will provide an outlet for any ideas and thoughts as well as input. All in all great stuff.

So thats a quick update 🙂