[LISPMAP-144] map-resolver replies with wrong mapping record and TTL Created: 30/Nov/16  Updated: 19/Oct/17  Resolved: 18/May/17

Status: Resolved
Project: lispflowmapping
Component/s: Service
Affects Version/s: Carbon
Fix Version/s: None

Type: Bug
Reporter: Filip Tehlar Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: File cap.pcap     Text File file_7272.txt     Text File file_7272.txt    
External issue ID: 7272

 Description   

git hash: 57fe8fc59843aff7f967bdeca97754d104dfaa9c

With initial following mapping
{
"input": {
"mapping-record": {
"recordTtl": 1440,
"action": "NoAction",
"authoritative": true,
"eid": {
"address-type": "ietf-lisp-address-types:source-dest-key-lcaf",
"source-dest-key":

{ "source": "6.0.1.0/24", "dest": "6.0.2.0/24" }

},
"LocatorRecord": [
{
"locator-id": "ISP1",
"priority": 1,
"weight": 1,
"multicastPriority": 255,
"multicastWeight": 0,
"localLocator": true,
"rlocProbed": false,
"routed": false,
"rloc":

{ "address-type": "ietf-lisp-address-types:ipv4-afi", "ipv4": "6.0.3.2" }

}
]
}
}
}

map-resolver received a src/dst map request triggered by source 6.0.1.2 and replied with the the mapping above as expected.
Then a new negative mapping is installed:

{
"input": {
"mapping-record": {
"recordTtl": 1440,
"action": "NoAction",
"authoritative": true,
"eid": {
"address-type": "ietf-lisp-address-types:source-dest-key-lcaf",
"source-dest-key":

{ "source": "6.0.0.0/16", "dest": "6.0.2.0/24" }

}
}
}
}

Notice that source part of src/dst key is a super-set prefix of the source in the existing mapping.
After this I deleted the old mapping 6.0.1.0/24|6.0.2.0/24 which resulted in SMR. Map resolver eventually received smr triggered map request and replied with negative mapping with 6.0.1.0/24|6.0.2.0/24 key instead of 6.0.0.0/16|6.0.2.0/24 as one would expect.

Apart from that the map-reply contained invalid TTL value - instead of 1440 wireshark showed value 15.

 Comments   
Comment by Filip Tehlar [ 30/Nov/16 ]

Attachment file_7272.txt has been added with description: odl log

Comment by Filip Tehlar [ 30/Nov/16 ]

Attachment file_7272.txt has been added with description: packet dump of incorrect map-reply

Comment by Lori Jakab [ 02/Dec/16 ]

(In reply to Filip Tehlar from comment #0)
> Apart from that the map-reply contained invalid TTL value - instead of 1440
> wireshark showed value 15.

I will look into the info you provided soon, but just wanted to note that negative map-replies do not return the TTL of a configured mapping, they are hardcoded to 15, that's expected. That's because the whole idea of the negative mapping is that there is no mapping in the mapping system for the value that was asked, and we return a somewhat arbitrary TTL (I think we just followed Cisco IOS here).

Comment by Lori Jakab [ 05/Dec/16 ]

(In reply to Lori Jakab from comment #2)
> (In reply to Filip Tehlar from comment #0)
> > Apart from that the map-reply contained invalid TTL value - instead of 1440
> > wireshark showed value 15.
>
> I will look into the info you provided soon, but just wanted to note that
> negative map-replies do not return the TTL of a configured mapping, they are
> hardcoded to 15, that's expected. That's because the whole idea of the
> negative mapping is that there is no mapping in the mapping system for the
> value that was asked, and we return a somewhat arbitrary TTL (I think we
> just followed Cisco IOS here).

Just to be clear, the above applies to negative mappings that are generated by the Map-Server (ODL) when no mapping is found, not for explicitly stored negative mappings, as in your example above. I assume if we fix the bug to return the actual negative mapping stored, the TTL will be correct too.

Comment by Filip Tehlar [ 05/Dec/16 ]

Attachment cap.pcap has been added with description: wireshark traffic capture

Comment by Lori Jakab [ 06/Dec/16 ]

Here's what I was able to figure out so far.

The srcdst:6.0.1.0/24|6.0.2.0/24 positive mapping gets added correctly. The srcdst:6.0.0.0/16|6.0.2.0/24 negative mapping is added correctly too. However, when removing the positive mapping, it seems that the 6.0.1.0/24 prefix stays in the lower (source) radix tree, and is found as the longest prefix match. However, the actual data is deleted, so the returned MappingRecord is null, which causes a "real" negative mapping (auto-generated, not pre-stored).

I will try to figure out with Florin's help where the issue is (RadixTrie or MultiTableMapCache?).

Comment by Lori Jakab [ 06/Dec/16 ]

Partial fix proposed: https://git.opendaylight.org/gerrit/#/c/49050/

Comment by Lori Jakab [ 07/Dec/16 ]

(In reply to Lori Jakab from comment #6)
> Partial fix proposed: https://git.opendaylight.org/gerrit/#/c/49050/

Can you please check if the above fix (already merged) fixes the bug for you?

Even then, we would like to keep the bug open, since for a full fix we need a few extra changes.

Comment by Filip Tehlar [ 08/Dec/16 ]

Confirming that the issue was resolved.

Comment by Lori Jakab [ 21/Dec/16 ]

(In reply to Lori Jakab from comment #7)
> Even then, we would like to keep the bug open, since for a full fix we need
> a few extra changes.

To elaborate, the above mentioned Gerrit fixes the MultiTableMapCache, but the issue is still present in the SimpleMapCache. The same fix can only be applied to the SimpleMapCache once the authentication keys are moved to a separate SimpleMapCache object.

Comment by Lori Jakab [ 21/Dec/16 ]

Proper fix proposed here: https://git.opendaylight.org/gerrit/#/c/49716/

Comment by Vina Ermagan [ 18/May/17 ]

final fix : https://git.opendaylight.org/gerrit/#/c/52112/

Generated at Wed Feb 07 20:06:36 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.