Hi all,
The cache in ITR reduce the forwarding or querying
pressure on some mapping server, but it also results in the following side effects.
Is there any other better solution to solve the above issues?
First, the mapping entry in cache is not real-time, it
depends some ICMP message to reflect the connection status of the multi-homed
site, which obviously brings some attack risks. The smaller TTL value of
mapping entry will result in frequent mapping request.
Second, it can result in black-hole or sub-optimal forwarding
path in some cases. For example, there are two prefixes in the mapping server, 1.1.1.0/24
and 1.1.0.0/24. At first, ITR receives a packet with destination of 1.1.2.1, and
it will get a mapping response which includes 1.1.0.0/24->ETR mapping. Then a
packet with destination of 1.1.1.1 arrives on ITR, it will result in black-hole
or sub-optimal forwarding path. There are some approaches to avoid this: one is
avoiding the EID prefixes in mapping database overlapped, the other is replying
with all the specific EID-prefixes’ mapping covered by the matching
EID-prefix. The former will result in non-aggregation, for example, some
enterprise has a /16 prefix, from which one /24 prefix is assigned to one site,
while the remaining /24 prefixes are assigned to another site called site B. With
this approach, all the remaining /24 prefixes in site B should be stored in the
mapping database separately. But in current Internet, prefix overlapping is
permitted. I wonder whether this overlapping phenomenon is ordinary or not? The
latter approach will result in some useless states in the ITR cache.
Is there any other better solution to solve the above
issues?
Best regards,
Xu Xiaohu