This is part of a series of posts – The Lisp Papers.
One of the key functions of the LISP implementation is baked-in multihoming and traffic engineering. EID spaces can be connected to the RLOC environment via several ETRs. The ETR responding to the querying ITR can offer a list of ETRs to be used. The LISP designers had two objectives when they were determining how this should function.
Firstly, the design should offer a preference of some ETRs over others. This allows some systems to act as primary ETRs and others as backups. This is implemented using the Priority field, with lower Priority systems being (counterintuitively) preferable over higher systems.
Secondly, the design should allow traffic distribution to be controlled. Once the priority comparison has taken place and, assuming that a number of systems with the lowest priority have been identified, the weight is considered. Traffic will be distributed between ETRs in the ratio of their weights. For example, ETR A might have a weight of 80 and ETR B might have a weight of 20. Traffic will be distributed between them in a ratio of 4:1.
Cisco LISP Network
In this case, the “MF” device combines Mapping Server and Mapping Resolver functionality (MF = Multi-Function). In addition, it peers with xTR3.1 and xTR3.2, which act as dual homing xTRs for Customer C. In this topology, xTR1 and xTR2 register with MS and xTR3.1 and xTR3.2 with MF for Mapping Server functionality. xTR1 and xTR2 use MR and xTR3.1 and xTR3.2 use MF to resolve EID to RLOC addresses. MF has GRE tunnels and BGP peers to both MS and MR. This allows the EID prefixes to be disseminated throughout the network and for Mapping Requests to to be delivered to the correct RLOC address.
This is a far more realistic topology than the one considered in the previous post for several reasons. The dual xTRs offer a resilient connection to Customer C. There remains a single point of failure in MF, which could be resolved by deploying a second MF and attaching it to a separate part of the core network. The MS and MR functionality are combined, which makes sense at a superficial level. This is for the practical reason that to separate the functions and provide resilience would require 4 systems (resilient MS and resilient MR), which would probably be an overkill for all but the largest environments. Perhaps there are scaling, security or topological reasons to separate MS and MR functionality.
The Mapping Request is routed over the ALT network, as described in the previous post, to one of the RLOCs registered for a specific EID space. The xTR that this corresponds to will respond with a list of RLOCs with associated priorities and weights.
MF’s LISP configuration looks as follows:
router lisp site CustomerC authentication-key cisco eid-prefix 10.1.0.0/24 accept-more-specifics exit ! ipv4 map-server ipv4 map-resolver ipv4 alt-vrf LISP exit
xTR3.1 and xTR3.2 have matching configurations:
router lisp !database mapping for xTR3.1 database-mapping 10.1.0.0/24 10.255.255.6 priority 2 weight 50 !database mapping for xTR3.2 database-mapping 10.1.0.0/24 10.255.255.7 priority 2 weight 50 !Configuring MF's loopback as Mapping Resolver ipv4 itr map-resolver 10.255.255.5 ipv4 itr !Configuring MF's loopback as Mapping Server ipv4 etr map-server 10.255.255.5 key cisco ipv4 etr exit
ETRs must be configured with all the EID address space database mappings for which they are authoritative for. In the above example, xTR3.1 is configured with database mappings for both xTR3.1 and xTR3.2. This makes sense when you consider that any ETR could respond to a mapping request and will need to respond with the addresses, priority and weight for the associated ETR RLOC addresses for a required EID address space. If you only configure xTR3.1 with the database mappings for xTR3.1, it will only respond with its own RLOC address and no load-balancing or resilience will be delivered.
Examining the LISP EID database table on MF shows that both xTRs have registered with it:
MF#sh lisp site detail LISP Site Registration Information Site name: CustomerC Allowed configured locators: any Allowed EID-prefixes: EID-prefix: 10.1.0.0/24 First registered: 00:47:03 Routing table tag: 0x0 Origin: Configuration, accepting more specifics Registration errors: Authentication failures: 0 Allowed locators mismatch: 0 ETR 10.1.3.26, last registered 00:00:41, no proxy-reply, no map-notify TTL 1d00h Locator Local State Pri/Wgt 10.255.255.6 no up 2/50 10.255.255.7 yes up 2/50 ETR 10.1.3.22, last registered 00:00:53, no proxy-reply, no map-notify TTL 1d00h Locator Local State Pri/Wgt 10.255.255.6 yes up 2/50 10.255.255.7 no up 2/50
If Customer A wishes to communicate with Customer C, xTR1 will send a Mapping Request to MR. MR will forward this over the ALT network, via the GRE tunnel between itself and MF, to the Customer C address, as detailed in the following packet trace:
You will notice that the above packet trace contains a GRE header sourced by MR and destined to MF. This is because the packet capture occured between Core and MF. The response below from xTR3.1 is not sent via the ALT (therefore no GRE header) and includes two RLOCs, a local RLOC (for xTR3.1) and an additional RLOC (xTR3.2):
Use the following table to decipher the traces, or for more detail, refer to the detailed diagram and configurations:
Examining the FIB on xTR1 shows that both RLOCs are used:
xTR1#sh ip cef 10.1.0.255 10.1.0.0/24 nexthop 10.1.0.0 Null0 xTR1#sh ip cef 10.1.0.255 det 10.1.0.0/24, epoch 0, flags subtree context, check lisp eligibility SC owned: LISP remote EID - locator status bits 0x00000003 LISP remote EID: 4 packets 400 bytes fwd action encap LISP source path list nexthop 10.255.255.6 LISP0 nexthop 10.255.255.7 LISP0 2 IPL sources [active source] Dependent covered prefix type inherit cover 0.0.0.0/0 recursive via 0.0.0.0/0 attached to Null0
You might have observed that the interface LISP0 on xTR1 has an extra line of config.
interface LISP0 ip load-sharing per-packet
This will share packets in a round-robin fashion between xTR3.1 and xTR3.2. This is probably not desirable as using different paths within a stream could cause out of sequence errors and excessive retransmissions, which is why the default is per-destination.
In the networks of today, load-balancing and resilience is predominantly delivered by the crude tools of deaggregation and AS Path prepending. LISP offers a much more subtle and manageable toolkit in a way that doesn’t beggar thy neighbour.