Solved: Re: SDA ARP Handling

JUANNN · ‎07-12-2026

Hello, I am just trying to understand how ARP in the overlay is handled by SDA. I get all the operation an order of operations. But I have a doubt:

When the endpoint sends the ARP request and the Edge Node intercepts it, and then the Edge Node sends the MAP Request to retrieve the target MAC address from the Control Plane node (if present in it), the reply to this Map Request is not a common one (this is, the reply is not the remote RLOC). Instead, it's the MAC address of the target host.

So how does the CP know that this Map Request should be resolved using the Address Resolution table (show lisp instance-id L2IIDXXXX ethernet server address-resolution) rather than using the typical behavior?

Is it because the Map Request is sent targeting a tuple like (L2 IID (the one correspondednt to the VLAN where the ARP request came from), IP Address), rather than the typical tuples (L3 IID, IP Address) or (L2 IID, MAC Address)? So by receiving the "rare tuple" the CP knows that the lookup should be made in the AR Table?

And also, I see in some examples that the CP replies with the target MAC Address, and then a second Map Request is sent by the Edge Node to get the RLOC for the target MAC Address... why does the CP not put everything on a single Map Reply the first time?

Thanks!

jalejand · ‎08-11-2026

To answer both questions:

1) So how does the CP know that this Map Request should be resolved using the Address Resolution table (show lisp instance-id L2IIDXXXX ethernet server address-resolution) rather than using the typical behavior?

Three methods exist to resolve ARP in SD-Access: LISP AR Relay (the method you are explaining), L2 Flooding (Flood ARP-ND) and Intra-Subnet Routing (L3 Only); the first is used as the default mode as the Device-Tracking LISP AR-RELAY policy is in place, the process is the following:

ARP Request comes in, snooped by ARPsnooper (an "slave" process of SISF/Device-Tracking) and then instructs LISP to query the CP for the Address-Resolution table, when Device-Tracking LISP AR Relay policy exists, this intercepts the ARP (Request, Reply, etc) and prevents the switch from forwarding it freely using its tables (CAM/Map-Cache, etc). Similar as if DAI was implemented, just that here it is device-tracking. The CP knows that the query is for an Address Resolution request as the Map-Request is for that special type (or LCAF/AF) in the L2 Instance, it's a field you can see in the Map-Request packet.

2) why does the CP not put everything on a single Map Reply the first time?
The idea of resolving ARP directly by the CP node to the endpoint might sound ideal/more efficient, but if that were the case, the destination endpoint would require to resolve ARP to the source using LISP as well, when the ARP request is sent all the way to the destination, the destination automatically learns the ARP information of the source from the ARP request, if suppression were to be enabled, another LISP query would be required; you could call it an architectural decision on ARP handling 🙂

View solution in original post

Andrii Oliinyk · ‎07-12-2026

"how does the CP know that this Map Request should be resolved using the Address Resolution table"
quick answer "nohow". in SDA, ARP (among of other maybe not as popular means) is used by EN|BN to learn EID (either or both L2|L3). When it's learned node just registers it in CP. Further MSMR-relevant messaging has nothing to do w/ ARP (& other means not as popular for learning).

jalejand · ‎08-11-2026

To answer both questions:

1) So how does the CP know that this Map Request should be resolved using the Address Resolution table (show lisp instance-id L2IIDXXXX ethernet server address-resolution) rather than using the typical behavior?

Three methods exist to resolve ARP in SD-Access: LISP AR Relay (the method you are explaining), L2 Flooding (Flood ARP-ND) and Intra-Subnet Routing (L3 Only); the first is used as the default mode as the Device-Tracking LISP AR-RELAY policy is in place, the process is the following:

ARP Request comes in, snooped by ARPsnooper (an "slave" process of SISF/Device-Tracking) and then instructs LISP to query the CP for the Address-Resolution table, when Device-Tracking LISP AR Relay policy exists, this intercepts the ARP (Request, Reply, etc) and prevents the switch from forwarding it freely using its tables (CAM/Map-Cache, etc). Similar as if DAI was implemented, just that here it is device-tracking. The CP knows that the query is for an Address Resolution request as the Map-Request is for that special type (or LCAF/AF) in the L2 Instance, it's a field you can see in the Map-Request packet.

2) why does the CP not put everything on a single Map Reply the first time?
The idea of resolving ARP directly by the CP node to the endpoint might sound ideal/more efficient, but if that were the case, the destination endpoint would require to resolve ARP to the source using LISP as well, when the ARP request is sent all the way to the destination, the destination automatically learns the ARP information of the source from the ARP request, if suppression were to be enabled, another LISP query would be required; you could call it an architectural decision on ARP handling 🙂

JUANNN · ‎08-12-2026

That helped a lot, thank you! You are right, now that I think about it, if the CP resolved ARP completely, then both the sender and receiver will have to query the CP for getting the MAC address... but both the sender EN and the receiver EN still have to query the CP to get the RLOC anyways for ARP in both directions, so I still think that it would be more effective to just have the CP resolve ARP all at once... or am I mistaken?

However I think I was not clear on the original question: why does the Edge Node has to send 2 different MAP Requests, one for retrieving target MAC and one for getting RLOC for MAC, instead of the CP returning the RLOC associated to the MAC in the MAP Reuqest for Address Resolution (this is, in the first MAP Request)?

Andrii Oliinyk · ‎08-13-2026

@JUANNN "2 different MAP Requests, one for retrieving target MAC..."
look, neither LISP RFC (RFC 6830,930[01],8060) defines Map-Request as query for MAC resolution.
It's always about to reply w/ RLOC or to return Action in case of Negative Map-Reply.
If you provide dump of packets u observe it will be easier to understand what u r dealing with.

JUANNN · ‎08-13-2026

@Andrii Oliinyk Is all actually shown in the document I referenced in my previous reply to you... Cisco shows the debugging and how the CP actually replies to the first ARP request with the MAC address of the target host. Look at the LISP Map-Reply for AR Resolution:

Locator/ID Separation Protocol
    0010 .... .... .... .... .... = Type: Map-Reply (2)
    .... 0... .... .... .... .... = P bit (Probe): Not set
    .... .0.. .... .... .... .... = E bit (Echo-Nonce locator reachability algorithm enabled): Not set
    .... ..0. .... .... .... .... = S bit (LISP-SEC capable): Not set
    .... ...0 0000 0000 0000 0000 = Reserved bits: 0x00000
    Record Count: 1
    Nonce: 0x50c5f2b60b41ca1c
    Mapping Record 1, EID Prefix: Unknown LCAF Type (53)/32, TTL: 1440, Action: No-Action, Not Authoritative
        Record TTL: 1440
        Locator Count: 1
        EID Mask Length: 32
        000. .... .... .... = Action: No-Action (0)
        ...0 .... .... .... = Authoritative bit: Not set
        .... .000 0000 0000 = Reserved: 0x000
        0000 .... .... .... = Reserved: 0x0
        .... 0000 0000 0000 = Mapping Version: 0
        EID Prefix AFI: LISP Canonical Address Format (LCAF) (16387)
        EID Prefix: Unknown LCAF Type (53)
            LCAF: Unknown (53)
                LCAF Header: 00003520000a
                    Reserved bits: 0x00
                    Flags: 0x00
                    Type: Unknown (53)
                    Reserved bits: 0x20
                    Length: 10
                [Expert Info (Error/Protocol): LCAF type 53 is not defined in draft-ietf-lisp-lcaf-05]
                    [LCAF type 53 is not defined in draft-ietf-lisp-lcaf-05]
                    [Severity level: Error]
                    [Group: Protocol]
        Locator Record 1, RLOC: 52:54:00:1e:ad:00, Unreachable, Priority/Weight: 1/100, Multicast Priority/Weight: 1/100
            Priority: 1
            Weight: 100
            Multicast Priority: 1
            Multicast Weight: 100
            Flags: 0x0000
                0000 0000 0000 0... = Reserved: 0x0000
                .... .... .... .0.. = Local: Not set
                .... .... .... ..0. = Probe: Not set
                .... .... .... ...0 = Reachable: Not set
            AFI: 802 (includes all 802 media plus Ethernet) (6)
            Locator: 52:54:00:1e:ad:00

See how the RLOC is just set to the MAC address being retrieved...

Andrii Oliinyk · ‎08-13-2026

i guess it's from here: https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/dna-center/215885-troubleshoot-arp-resolution-in-sd-access.html
Cisco implements proprietary Type 53 LCAF MR for EN to populate DST field of VXLAN'ed unicast ARP. imo Cisco simplifies entire step w/ use of 2 requests otherwise SRC EN would need to have a logic to separate 2 RLOCs from single reply.
well... this is actually a nice example of why it's right to separate "what LISP means by Map-Request" from "what Cisco's SD-Access implementation does with a particular LCAF." The first is standardized; the latter can go well beyond the base LISP semantics.

Andrii Oliinyk · ‎08-12-2026

looks like "...Edge Node sends the MAP Request to retrieve the target MAC address..." specifically requires clarification.
Map-Request in LISP is NOT "give me MAC-address". It's request for the CP to reply w/ RLOC of target EID. It's normal for EID known by CP to return RLOC (w/ whatever EID-Prefix-AFI/EID-Prefix are). If EID is unknown to CP reply may carry no RLOCs (Negative Map-Reply w/ appropriate Action). Thus i wonder what Request/Reply were exactly observed...

JUANNN · ‎08-12-2026

Hello. I suggest you take a look at Troubleshoot ARP Resolution in SD-Access Fabric - Cisco to understand the concept of L2 AR Table and how the first Map Request sent by the EN is actually "give me the MAC-address" because is an Address-Resolution Request 🙂