This is a very simple post to capture OTV packets which leave / come into the router. One can use this data and try to understand how an OTV packet looks like.
Before we go into configuring EPC, I would just like to mention a few things on the overhead which OTV introduces.
We all know that the overhead added by OTV is 42 bytes. The breakdown is as follows:
4 bytes - MPLS
4 bytes - GRE
20 bytes - IP Header
14 bytes - Outer Ethernet frame
However, as per the draft related to OTV, there isn't anything mentioned related MPLS and GRE [in fact it should have been UDP]
The reason for this could have been the go to market time frame. Encapsulations are expected to be made at the ASIC level and currently as per my understanding none of the ASIC's [as of today] are capable of providing this OTV encapsulation. However, in the future I believe the overhead breakdown of OTV could be something as follows:
4 bytes - OTV
4 bytes - UDP
20 bytes - IP Header
14 bytes - Outer Ethernet frame
Currently, this is how the 'show otv' output looks like:
ED1#show otv
Overlay Interface Overlay150
VPN name : None
VPN ID : 3
State : UP
AED Capable : Yes
IPv4 control group : 232.1.14.1
Mcast data group range(s): 232.14.1.0/24
Join interface(s) : GigabitEthernet0/0/1.14
Join IPv4 address : 10.1.14.2
Tunnel interface(s) : Tunnel0
Encapsulation format : GRE/IPv4
Site Bridge-Domain : 150
Capability : Multicast-reachable
Is Adjacency Server : No
Adj Server Configured : No
Prim/Sec Adj Svr(s) : None
ED1#
ED1#
The highlighted portion of of the output can be configured via the usage of the sub-command "otv encapsulation-format" seen under the 'interface overlay <num>'. Although applying / removing this command does not have any effect on the overall OTV bring up as of today, I believe this is the command that will be used to give us the option of UDP in the coming days.
ED2(config-if)#otv encapsulation-format ?
ip Use IP for outer header encapsulation
ED2(config-if)#otv encapsulation-format ip ?
gre Use GRE middle header encapsulation
ED2(config-if)#otv encapsulation-format ip gre
ED2(config-if)#otv encapsulation-format ip gre ?
<cr>
ED2(config-if)#otv encapsulation-format ip gre
ED2(config-if)#
With that said, lets configure EPC [embedded packet capture] on the Cisco ED:
NOTE: This is a continuation of basic multicast OTV. Request you to encourage you to open a tab of the same if you are getting confused.
Link for basic multicast: http://stayinginit.blogspot.in/2013/12/basic-multicast-otv.html
EPC Configuration:
Topology for reference:
Note that the configurations and verification's are done on ED1.
ED1#monitor capture otv_buff interface GigabitEthernet0/0/1.14 both match any buffer circular size 200 limit packets 100
ED1#show monitor capture otv_buff
Status Information for Capture otv_buff
Target Type:
Interface: GigabitEthernet0/0/1.14, Direction: both
Status : Inactive
Filter Details:
Capture all packets
Buffer Details:
Buffer Type: CIRCULAR
Buffer Size (in MB): 200
Limit Details:
Number of Packets to capture: 100
Packet Capture duration: 0 (no limit)
Packet Size to capture: 0 (no limit)
Maximum number of packets to capture per second: 1000
Packet sampling rate: 0 (no sampling)
ED1#
Direction is 'both' to capture packets leaving and entering the join-interface and all the packets are being captured [this can be further filtered using access-list]
NOTE: Its mandatory to have the match and interface option when configuring monitor capture.
ED1#monitor capture otv_buff start
ED1#
*Dec 10 06:00:00.500: %BUFCAP-6-ENABLE: Capture Point otv_buff enabled.
ED1#
[root@localhost ~]# ping 172.16.11.20 -c 5
PING 172.16.11.20 (172.16.11.20) 56(84) bytes of data.
64 bytes from 172.16.11.20: icmp_seq=2 ttl=64 time=0.723 ms
64 bytes from 172.16.11.20: icmp_seq=3 ttl=64 time=0.686 ms
64 bytes from 172.16.11.20: icmp_seq=4 ttl=64 time=0.636 ms
64 bytes from 172.16.11.20: icmp_seq=5 ttl=64 time=0.652 ms
--- 172.16.11.20 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.636/0.674/0.723/0.038 ms
[root@localhost ~]#
ED1#monitor capture otv_buff stop
ED1#
*Dec 10 06:00:21.688: %BUFCAP-6-DISABLE: Capture Point otv_buff disabled.
ED1#
ED1#show monitor capture otv_buff buffer brief
-------------------------------------------------------------
# size timestamp source destination protocol
-------------------------------------------------------------
0 1460 0.000000 10.1.14.2 -> 232.1.14.1 GRE
1 98 0.666018 10.1.14.1 -> 224.0.0.5 OSPF
2 146 1.381984 10.1.14.2 -> 232.1.14.1 GRE
3 1460 3.280991 10.1.14.2 -> 232.1.14.1 GRE
4 98 4.122995 10.1.14.2 -> 224.0.0.5 OSPF
5 106 4.759015 10.1.14.2 -> 232.1.14.1 GRE
6 1460 5.287995 10.2.14.2 -> 232.1.14.1 GRE
7 1460 6.096995 10.1.14.2 -> 232.1.14.1 GRE
8 106 6.799022 10.2.14.2 -> 232.1.14.1 GRE
9 106 6.800013 10.1.14.2 -> 10.2.14.2 GRE
10 129 6.882010 10.1.14.2 -> 232.1.14.1 GRE
11 144 7.798015 10.2.14.2 -> 10.1.14.2 GRE
12 144 7.798015 10.1.14.2 -> 10.2.14.2 GRE
13 144 8.798015 10.2.14.2 -> 10.1.14.2 GRE
14 144 8.798015 10.1.14.2 -> 10.2.14.2 GRE
15 1460 9.310989 10.1.14.2 -> 232.1.14.1 GRE
16 144 9.798015 10.2.14.2 -> 10.1.14.2 GRE
17 144 9.798015 10.1.14.2 -> 10.2.14.2 GRE
18 98 10.263994 10.1.14.1 -> 224.0.0.5 OSPF
19 146 10.355984 10.1.14.2 -> 232.1.14.1 GRE
20 144 10.798015 10.2.14.2 -> 10.1.14.2 GRE
21 144 10.798015 10.1.14.2 -> 10.2.14.2 GRE
22 1460 11.913014 10.1.14.2 -> 232.1.14.1 GRE
23 106 12.798015 10.1.14.2 -> 10.2.14.2 GRE
24 106 12.799022 10.2.14.2 -> 10.1.14.2 GRE
25 106 13.168998 10.1.14.2 -> 232.1.14.1 GRE
26 98 13.585984 10.1.14.2 -> 224.0.0.5 OSPF
27 58 14.432992 10.1.14.2 -> 224.0.0.22 IGMP
28 1460 14.819010 10.2.14.2 -> 232.1.14.1 GRE
29 1460 14.940006 10.1.14.2 -> 232.1.14.1 GRE
30 1460 18.189993 10.1.14.2 -> 232.1.14.1 GRE
ED1#
One can also use access-lists to limit the packet capture as shown below:
# show running-config | sec ip access-list
ip access-list extended otv_icmp
permit gre host 10.1.14.2 host 10.2.14.2
permit gre host 10.2.14.2 host 10.1.14.2
ED1#monitor capture otv_buff access-list otv_icmp
A filter is already attached to the capture. Replace with new access-list?[confirm]
ED1#
Before we can start the capture we should always clear the capture buffer and start. Hence, perform the 'clear' [monitor capture otv_buff clear]
ED1#show monitor capture otv_buff buffer brief
ED1#show monitor capture otv_buff buffer brief
-------------------------------------------------------------
# size timestamp source destination protocol
-------------------------------------------------------------
0 1488 0.000000 10.1.14.2 -> 10.2.14.2 GRE
1 1488 0.000991 10.2.14.2 -> 10.1.14.2 GRE
2 1488 1.000991 10.1.14.2 -> 10.2.14.2 GRE
3 1488 1.001998 10.2.14.2 -> 10.1.14.2 GRE
4 1488 2.000991 10.1.14.2 -> 10.2.14.2 GRE
5 1488 2.001998 10.2.14.2 -> 10.1.14.2 GRE
6 1488 3.000991 10.1.14.2 -> 10.2.14.2 GRE
7 1488 3.001998 10.2.14.2 -> 10.1.14.2 GRE
8 1488 4.000991 10.1.14.2 -> 10.2.14.2 GRE
9 1488 4.001998 10.2.14.2 -> 10.1.14.2 GRE
10 106 5.000000 10.2.14.2 -> 10.1.14.2 GRE
11 106 5.000991 10.1.14.2 -> 10.2.14.2 GRE
ED1#
One can export the packet captures observed onto a file and then view them using wireshark. Exporting can be done as below:
Exported Successfully
ED1#
Before concluding this post, I just want to mention about this one command, which isn't available on the Nexus devices due to which the DF bit was set by default for OTV.
Consider a case wherein a host is sending a ping traffic with packet size 1431.
ED1# monitor capture otv_buff export tftp://<IP>/<location>/<filename>.pcap
!Exported Successfully
ED1#
Before concluding this post, I just want to mention about this one command, which isn't available on the Nexus devices due to which the DF bit was set by default for OTV.
Consider a case wherein a host is sending a ping traffic with packet size 1431.
[root@vm-aries-cel ~]# ping 172.16.11.10 -s 1431 -c 5
PING 172.16.11.10 (172.16.11.10) 1431(1459) bytes of data.
--- 172.16.11.10 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
[root@vm-aries-cel ~]#
The packets reaches 1501 bytes [1459 + 42]. This being greater than 1500 bytes, we see drops on ED1 to confirm the same. [Note here that when we say 1431 bytes, it's a payload size. So, to this we will be adding a 28 byte header]
ED1#show platform hardware qfp active statistics drop
------------------------------------------------------------------
Global Drop Stats Packets Octets
------------------------------------------------------------------
IpFragErr 5 7505
ED1#
To make this work, we have one of two options:
- Increase the MTU throughout the network
- Remove the DF setting and fragment the packet before it goes out into the core
ED1(config)#otv fragmentation join-interface Gig0/0/1.14
ED2(config)#otv fragmentation join-interface Gig0/0/0.14
[root@vm-aries-cel ~]# ping 172.16.11.10 -s 1431 -c 5
PING 172.16.11.10 (172.16.11.10) 1431(1459) bytes of data.
1439 bytes from 172.16.11.10: icmp_seq=0 ttl=64 time=1.63 ms
1439 bytes from 172.16.11.10: icmp_seq=1 ttl=64 time=1.57 ms
1439 bytes from 172.16.11.10: icmp_seq=2 ttl=64 time=1.44 ms
1439 bytes from 172.16.11.10: icmp_seq=3 ttl=64 time=1.34 ms
1439 bytes from 172.16.11.10: icmp_seq=4 ttl=64 time=1.38 ms
--- 172.16.11.10 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 1.340/1.476/1.639/0.119 ms, pipe 2
[root@vm-aries-cel ~]#
ED1#show ip traffic | sec Frag
Frags: 5 reassembled, 0 timeouts, 0 couldn't reassemble
5 fragmented, 10 fragments, 0 couldn't fragment
ED1#
The above indicates that the packets were fragmented [we sent 5 packets, but see 10 fragments].
This ends our EPC post, wherein we had a chance to look at how to configure 'monitor capture' to view OTV packets and also, usage of our 'otv fragmentation join-interface <interface>' to fragment OTV packets.
Hope you found this post informative.
This ends our EPC post, wherein we had a chance to look at how to configure 'monitor capture' to view OTV packets and also, usage of our 'otv fragmentation join-interface <interface>' to fragment OTV packets.
Hope you found this post informative.
No comments:
Post a Comment