发件人: Xu
Xiaohu [mailto:xuxh@huawei.com]
发送时间: 2007年10月10日
22:11
收件人:
'rrg@psg.com'
主题: How to avoid
the side effect of cache in ITR
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