ASR1k – OTV
OTV全称Overlay Transport Virtualization。
它也是Overlay VPN的一种，主要用于DC的N7k中，ASR1k也支持。
他跟其他的2层VPN主要的优势就是传输网不用支持MPLS，只要支持IP和组播就可以了。
下面是针对OTV PPT中的对比，其实每种部署方案都有自己的优势，所以参考而已：
下面是测试Topology及最简配置：
SW1(SVI179:179.1.1.2)——–(l2)ASR1k_1(10.10.0.2)—–(1)SW3(3)—–(10.10.1.2)ASR1k_2(l2)———–(SVI179:179.1.1.3)SW2
SW1 SVI MAC: 2893.fec0.7842
SW2 SVI MAC: 2893.fec0.14c5
ASR1k_1 WAN MAC: 2c54.2d7b.9000
ASR1k_2 WAN MAC: 0022.5561.4c00
SW3-1 MAC: 0022.bd1e.5141
SW3-2 MAC: 0022.bd1e.5142
ASR1k_1:
ip multicast-routing distributed !---开启组播 otv site bridge-domain 179 otv site-identifier 0000.0000.0001 !---设置site的domain和identifier，不设置OTV起不来，不过本地有效 !---不过主要在Multi-Home时，选AED（Authoritative Edge）时才有用，类似HSRP的技术，但原理不一样 !---另外对于site bridge-domain，建议跟数据VLAN隔离开，这个VLAN是跑控制报文的，为了测试，我在1k-1上数据和控制都在vlan179，1k-2上则分开用的。 ! interface Overlay1 !---这就是OTV的主接口，大部分OTV的配置在这里配置 no ip address otv control-group 239.1.1.1 otv data-group 232.1.1.0/28 !---分别设置控制平面和数据平面的组播地址，OTV控制平面用的是Any Source Multicast；而数据平面用的是SSM，不过根据抓包，数据报文中没看到用这个232.1.1.0组播地址。。。 otv join-interface GigabitEthernet0/0/0 !---把实际物理口加入OTV otv vpn-name OTV no otv filter-fhrp !---为了让每个站点灵活部署Multi-Home，默认关闭在OTV口上传送HSRP等Hello，这样可以使每个站点都有自己的ACtive和Standby service instance 179 ethernet encapsulation dot1q 179 bridge-domain 179 ! ! interface GigabitEthernet0/0/0 ip address 10.10.0.2 255.255.255.0 ip pim passive ip igmp version 3 ip ospf network point-to-point negotiation auto cdp enable ! interface GigabitEthernet0/0/1 no ip address negotiation auto cdp enable service instance 179 ethernet encapsulation dot1q 179 bridge-domain 179 !---0/0/1相当于一个l2transport口，service instance就是一个EFP，这个EFP仅Match VLAN179的数据，并bridge到179中，跟OTV中的正好在一个domain里 ! ! router ospf 100 network 10.10.0.2 0.0.0.0 area 0
ASR1k_2:
ip multicast-routing distributed otv site bridge-domain 1 otv site-identifier 0000.0000.0002 ! interface Overlay1 no ip address otv control-group 239.1.1.1 otv data-group 232.1.1.0/28 otv join-interface GigabitEthernet0/0/0 otv vpn-name OTV no otv filter-fhrp service instance 1 ethernet encapsulation dot1q 1 bridge-domain 1 ! service instance 179 ethernet encapsulation dot1q 179 bridge-domain 179 ! ! interface GigabitEthernet0/0/0 ip address 10.10.1.2 255.255.255.0 ip pim passive ip igmp version 3 ip ospf network point-to-point negotiation auto cdp enable ! interface GigabitEthernet0/0/1 no ip address negotiation auto cdp enable service instance 1 ethernet encapsulation dot1q 1 bridge-domain 1 ! service instance 179 ethernet encapsulation dot1q 179 bridge-domain 179 ! ! router ospf 100 network 10.10.1.2 0.0.0.0 area 0
ASR1k_1路由信息：
ASR1k_1#show otv route
Codes: BD - Bridge-Domain, AD - Admin-Distance,
SI - Service Instance, * - Backup Route
OTV Unicast MAC Routing Table for Overlay1
Inst VLAN BD MAC Address AD Owner Next Hops(s)
----------------------------------------------------------
0 179 179 0000.0c07.acb3 50 ISIS BGL.R.16-ASR1000-2
0 179 179 2893.fec0.14c5 50 ISIS BGL.R.16-ASR1000-2
0 179 179 2893.fec0.7842 40 BD Eng Gi0/0/1:SI179
3 unicast routes displayed in Overlay1
----------------------------------------------------------
3 Total Unicast Routes Displayed
ASR1k_1 组播信息：
ASR1k_1#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 1w2d/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 1w2d/00:02:34
GigabitEthernet0/0/0, Forward/Sparse-Dense, 1w2d/Proxy
(10.10.1.2, 239.1.1.1), 1w2d/00:02:01, flags: T
Incoming interface: GigabitEthernet0/0/0, RPF nbr 10.10.0.1
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 1w2d/00:02:34
(10.10.0.2, 239.1.1.1), 1w2d/00:01:33, flags: T
Incoming interface: GigabitEthernet0/0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 1w2d/00:02:34
GigabitEthernet0/0/0, Forward/Sparse-Dense, 1w2d/Proxy
(*, 224.0.1.40), 5d16h/00:02:46, RP 0.0.0.0, flags: DPC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
IETF草案及封装内容
http://tools.ietf.org/html/draft-hasmit-otv-04
The format of OTV UDP IPv4 encapsulation is as follows:
数据包信息分析：
很遗憾，根据抓包信息，没有找到相应的信息，如OTV Shim中的VLAN ID （VLAN179 = B3），看来现有1K上运行的OTV跟IETF草案里的还不一样。
测试中的问题：
在测试中，发现一个有意思的问题，就是过一段时间后，从standby ping向active时失败，但从active ping向standby就ok，然后回ping也ok了。另外如果在standby上clear arp也能解决这个问题，这是怎么回事呢？
实际上当HSRP开始初始化时，都是以虚地址开始的，当选举完成，standby会用实地址向active发送hello，这样standby的MAC地址就会一直存在。所以active总是能ping到standby。对于standby到active，当最开始发送第一个ping时，两边都通过OTV学习到了相应的MAC地址，但经过一段时间，OTV的老化时间到了，所以会清掉MAC，但是这个时间要远远小于正常的ARP老化时间，所以在standby上，还是有active的MAC的，但OTV已经没有active的MAC了，所以包封装好到达OTV后就会直接drop掉，这也是OTV的feature，所以clear arp的动作迫使standby发送arp请求，所以就都通了。