Dear Matt, That´s a very cool hack!
Please let me know if you have any further issues and the final outcome of this. Did you find any remarkable limitation? Thanks Albert On Mar 25, 2013, at 11:23 AM, Teto <[email protected]> wrote: > you perfectly understood what I wanted to do. I know it's not the > normal behavior or anything. I didn't send this as a patch but rather > as a quick hack to fulfill a need. I just needed endhosts behind > lispmob to be able to interrogate mapping servers (for an experiment). > That's the easiest way I found so far but if you have any other idea, > I take it. > > Matt > > On Mon, Mar 25, 2013 at 9:14 AM, Albert López <[email protected]> wrote: >> Dear Matt, >> >> I don't understand why do you want this behavior. LISPmob is an >> implementation of an XTR and not of a Map Resolver. When you send a map >> request to it, you could only obtain answer to the mapping of the EIDs >> belonging to this XTR. If I understood correctly, you are modifying >> LISPmob to be used as a proxy of the map resolver (the one configured in >> LISPmob) not a Map Resolver. >> Moreover, when you are using "handle_map_cache_miss", What you are doing is >> generating a new entry to the map cache databse. The control plane of >> LISPmob generate a map request and add map cache entry to the data base >> that will be filled from the obtained map reply. When you are sending a map >> request to LISPmob, it checks his local database (information of the EIDs >> configured in LISPmob) and not the map cache database (mapping of exteranl >> EIDs). >> >> Best regards >> >> Albert >> >> >> >> >> On 03/24/2013 02:20 PM, Teto wrote: >>> >>> ok sorry to have bothered you, it seems like I got it working via >>> further modification of the function: >>> >>> >>> >>> int process_map_request_record( >>> uint8_t **cur_ptr, >>> lisp_addr_t *local_rloc, >>> lisp_addr_t *remote_rloc, >>> uint16_t dst_port, >>> uint8_t rloc_probe, >>> uint64_t nonce) >>> { >>> lispd_pkt_map_request_eid_prefix_record_t *record; >>> lispd_identifier_elt requested_identifier; >>> lispd_identifier_elt *identifier; >>> map_reply_opts opts; >>> >>> // added by matt >>> lispd_map_cache_entry *entry = NULL; >>> >>> /* Get the requested EID prefix */ >>> record = (lispd_pkt_map_request_eid_prefix_record_t *)*cur_ptr; >>> init_identifier(&requested_identifier); >>> *cur_ptr = (uint8_t *)&(record->eid_prefix_afi); >>> if ((err=pkt_process_eid_afi(cur_ptr, >>> &requested_identifier))!=GOOD){ >>> lispd_log_msg(LISP_LOG_DEBUG_2,"%s: Requested EID could not >>> be processed",__func__); >>> return (err); >>> } >>> requested_identifier.eid_prefix_length = record->eid_prefix_length; >>> >>> /* Check the existence of the requested EID */ >>> /* XXX aloepz: We don't use prefix mask and use by default 32 or >>> 128*/ >>> identifier = lookup_eid_in_db(requested_identifier.eid_prefix); >>> >>> // >>> // >>> // if (!identifier){ >>> // lispd_log_msg(LISP_LOG_DEBUG_1,"The requested EID doesn't >>> belong to this node: %s/%d", >>> // >>> get_char_from_lisp_addr_t(requested_identifier.eid_prefix), >>> // requested_identifier.eid_prefix_length); >>> // return (BAD); >>> // } >>> // >>> >>> /* Modifications by matt */ >>> >>> if (!identifier){ >>> lispd_log_msg(LISP_LOG_DEBUG_1,"requested EID doesn't belong >>> to this node but will try to answer: %s/%d", >>> >>> get_char_from_lisp_addr_t(requested_identifier.eid_prefix), >>> requested_identifier.eid_prefix_length); >>> >>> >>> >>> entry = lookup_map_cache(requested_identifier.eid_prefix); >>> >>> //arnatal XXX: is this the correct error type? >>> if (entry == NULL){ /* There is no entry in the map cache */ >>> lispd_log_msg(LISP_LOG_DEBUG_1, "No map cache >>> retrieved for eid >>> %s",get_char_from_lisp_addr_t(requested_identifier.eid_prefix)); >>> >>> // handle_map_cache_miss(&original_dst_addr, >>> &original_src_addr); >>> >>> handle_map_cache_miss(&requested_identifier.eid_prefix, remote_rloc); >>> lispd_log_msg(LISP_LOG_DEBUG_1,"handle cache miss >>> with source : %s and dest %s", >>> get_char_from_lisp_addr_t( >>> requested_identifier.eid_prefix ), >>> get_char_from_lisp_addr_t(*remote_rloc) >>> ); >>> } >>> /* Packets with negative map cache entry, no active map >>> cache entry or no map cache entry are forwarded to PETR */ >>> if ((entry == NULL) || (entry->active == NO_ACTIVE) || >>> (entry->identifier->locator_count == 0) ){ /* There is no entry or is >>> not active*/ >>> lispd_log_msg(LISP_LOG_DEBUG_1,"Could not retrieve >>> EID: %s/%d", >>> >>> get_char_from_lisp_addr_t(requested_identifier.eid_prefix), >>> requested_identifier.eid_prefix_length); >>> return(GOOD); >>> } >>> >>> >>> // update identifier >>> identifier = entry->identifier; >>> >>> >>> } >>> >>> >>> /* Set flags for Map-Reply */ >>> opts.send_rec = 1; >>> opts.echo_nonce = 0; >>> opts.rloc_probe = rloc_probe; >>> >>> err = build_and_send_map_reply_msg(identifier, local_rloc, >>> remote_rloc, dst_port, nonce, opts); >>> if (rloc_probe){ >>> if (err == GOOD){ >>> lispd_log_msg(LISP_LOG_DEBUG_1, "Sent RLOC-probe reply to >>> %s", get_char_from_lisp_addr_t(*remote_rloc)); >>> }else { >>> lispd_log_msg(LISP_LOG_DEBUG_1, "process_map_request_msg: >>> couldn't build/send RLOC-probe reply"); >>> return(BAD); >>> } >>> }else { >>> if (err == GOOD){ >>> lispd_log_msg(LISP_LOG_DEBUG_1, "Sent Map reply to %s", >>> get_char_from_lisp_addr_t(*remote_rloc)); >>> }else { >>> lispd_log_msg(LISP_LOG_DEBUG_1, "process_map_request_msg: >>> couldn't build/send map-reply"); >>> return(BAD); >>> } >>> } >>> return (GOOD); >>> } >>> >>> On Sun, Mar 24, 2013 at 1:28 PM, Teto <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> I would like to be able from my computer to be able to use lig (more >>>> precisely to get the rlocs for a specific EID) while LISPmob being >>>> active. I wonder what's the best way would be. My current idea is to >>>> use LISPmob as a mapping server. With lig, I ask LISPmob which returns >>>> me a result for the EID this xTR is responsible (153.16.49.112 being >>>> my EID space): >>>> teto@tatooine:~/lig$ lig -m 153.16.49.112 153.16.49.112 >>>> Send map-request to 153.16.49.112 for 153.16.49.112 ... >>>> Received map-reply from 82.121.110.51 with rtt 0.00000 secs >>>> >>>> Mapping entry for EID '153.16.49.112': >>>> 153.16.49.112/28, instance ID: 0, via map-reply, record ttl: 10, >>>> auth, not mobile >>>> Locator State Priority/Weight >>>> 82.121.110.51 up 1/100 >>>> >>>> >>>> but not for the other EIDs: >>>> teto@tatooine:~/lig$ lig -m 153.16.49.112 153.16.11.0 >>>> Send map-request to 153.16.49.112 for 153.16.11.0 ... >>>> Send map-request to 153.16.49.112 for 153.16.11.0 ... >>>> >>>> >>>> I would like lispmob to answer for all EIDs, that is if I ask it an >>>> EID lispmob doesn't know , it should ask its configured mapping >>>> resolver, get the reply and then "forwards" it to my lig. >>>> I've started modifying process_map_request_record to use >>>> "handle_map_cache_miss" but I wonder if that's the best option. >>>> Here is the original code: >>>> /* Check the existence of the requested EID */ >>>> /* XXX aloepz: We don't use prefix mask and use by default 32 or >>>> 128*/ >>>> identifier = lookup_eid_in_db(requested_identifier.eid_prefix); >>>> >>>> >>>> >>>> if (!identifier){ >>>> lispd_log_msg(LISP_LOG_DEBUG_1,"The requested EID doesn't >>>> belong to this node: %s/%d", >>>> >>>> get_char_from_lisp_addr_t(requested_identifier.eid_prefix), >>>> requested_identifier.eid_prefix_length); >>>> return (BAD); >>>> } >>>> >>>> to which I added something like but I need more modifications since it >>>> doesn't work yet. >>>> if( >>>> handle_map_cache_miss(&requested_identifier.eid_prefix, remote_rloc) >>>> != GOOD){ >>>> lispd_log_msg(LISP_LOG_DEBUG_1,"Could not retrieve EID: >>>> %s/%d", >>>> >>>> get_char_from_lisp_addr_t(requested_identifier.eid_prefix), >>>> requested_identifier.eid_prefix_length); >>>> return (BAD); >>>> } >>>> >>>> Regards >>>> >>>> MAtt >> >> >>
