5 files changed, 10 insertions, 10 deletions
diff --git a/docs/usecases/contiv/BUG_REPORTS.md b/docs/usecases/contiv/BUG_REPORTS.md
index 23c9a7c393c..648e67f2422 100644
--- a/docs/usecases/contiv/BUG_REPORTS.md
+++ b/docs/usecases/contiv/BUG_REPORTS.md
@@ -151,7 +151,7 @@ index 3676047..ffa4473 100644
                valueFrom:
 ```
 
-If VPP is the crashing process, please follow the [CORE_FILES](CORE_FILES.html) guide and provide the coredump file.
+If VPP is the crashing process, please follow the \[CORE_FILES\](CORE_FILES.html) guide and provide the coredump file.
 
 
 ### Inspect VPP Config
diff --git a/docs/usecases/contiv/K8s_Overview.md b/docs/usecases/contiv/K8s_Overview.md
index f9cf9c5a9ba..e3d8e1a0d44 100644
--- a/docs/usecases/contiv/K8s_Overview.md
+++ b/docs/usecases/contiv/K8s_Overview.md
@@ -78,7 +78,7 @@ network stack, and data-plane NIC interface controlled by VPP:
  - data-plane NIC is controlled directly by VPP using DPDK. Note, this means that
  this interface is not visible to the host Linux network stack, and the node either needs another
  management interface for k8s control plane communication, or 
- [STN (Steal The NIC)](SINGLE_NIC_SETUP.html) deployment must be applied.
+ \[STN (Steal The NIC)\](SINGLE_NIC_SETUP.html) deployment must be applied.
 
 **Contiv VPP Agent** is the control plane part of the vSwitch container. It is responsible
 for configuring the VPP according to the information gained from ETCD, and requests
@@ -99,11 +99,11 @@ and replies with a response, which is then forwarded back to Kubelet.
 
 
 ### Contiv STN Daemon
-This section discusses how the Contiv [STN (Steal The NIC)](SINGLE_NIC_SETUP.html) daemon operation works. As already mentioned, the default setup of Contiv/VPP requires two network interfaces
+This section discusses how the Contiv \[STN (Steal The NIC)\](SINGLE_NIC_SETUP.html) daemon operation works. As already mentioned, the default setup of Contiv/VPP requires two network interfaces
 per node: one controlled by VPP for data facing PODs, and one controlled by the host
 network stack for k8s control plane communication. In case that your k8s nodes
 do not provide two network interfaces, Contiv/VPP can work in the single NIC setup,
 when the interface will be "stolen" from the host network stack just before starting
 the VPP and configured with the same IP address on VPP, as well as 
 on the host-VPP interconnect TAP interface, as it had in the host before it. 
-For more information on STN setup, read the [Single NIC Setup README](./SINGLE_NIC_SETUP.html)
+For more information on STN setup, read the \[Single NIC Setup README\](./SINGLE_NIC_SETUP.html)
diff --git a/docs/usecases/contiv/NETWORKING.md b/docs/usecases/contiv/NETWORKING.md
index 0b6d08127fb..25ce3ce0410 100644
--- a/docs/usecases/contiv/NETWORKING.md
+++ b/docs/usecases/contiv/NETWORKING.md
@@ -20,7 +20,7 @@ ID is released back to the pool and will be re-used by the next node.
 The Node ID is used to calculate per-node IP subnets for PODs
 and other internal subnets that need to be unique on each node. Apart from the Node ID,
 the input for IPAM calculations is a set of config knobs, which can be specified
-in the `IPAMConfig` section of the [Contiv/VPP deployment YAML](../../../k8s/contiv-vpp.yaml):
+in the `IPAMConfig` section of the \[Contiv/VPP deployment YAML\](../../../k8s/contiv-vpp.yaml):
 
 - **PodSubnetCIDR** (default `10.1.0.0/16`): each pod gets an IP address assigned 
 from this range. The size of this range (default `/16`) dictates upper limit of 
@@ -132,6 +132,6 @@ whenever a node is added/deleted in the k8s cluster.
 
 
 #### More Info
-Please refer to the [Packet Flow Dev Guide](../dev-guide/PACKET_FLOW.html) for more 
+Please refer to the \[Packet Flow Dev Guide\](../dev-guide/PACKET_FLOW.html) for more 
 detailed description of paths traversed by request and response packets 
 inside Contiv/VPP Kubernetes cluster under different situations.
 \ No newline at end of file
diff --git a/docs/usecases/contiv/SINGLE_NIC_SETUP.md b/docs/usecases/contiv/SINGLE_NIC_SETUP.md
index 875a7323fff..83dd47d99a6 100644
--- a/docs/usecases/contiv/SINGLE_NIC_SETUP.md
+++ b/docs/usecases/contiv/SINGLE_NIC_SETUP.md
@@ -52,7 +52,7 @@ or individually for every node in the cluster.
 Global configuration is used in homogeneous environments where all nodes in 
 a given cluster have the same hardware configuration, for example only a single
 Network Adapter. To enable the STN feature globally, put the `StealFirstNIC: True`
-stanza into the [`contiv-vpp.yaml`][1] deployment file, for example:
+stanza into the \[`contiv-vpp.yaml`\]\[1\] deployment file, for example:
 ```
 data:
   contiv.yaml: |-
@@ -67,13 +67,13 @@ Setting `StealFirstNIC` to `True` will tell the STN Daemon on every node in the
 cluster to steal the first NIC from the kernel and assign it to VPP. Note that
 the Network Adapters on different nodes do not need to be of the same type. You
 still need to create the respective vswitch configurations on every node in the
-cluster, as shown [above](#creating-a-vpp-interface-configuration).
+cluster, as shown \[above\](#creating-a-vpp-interface-configuration).
 
 ##### Individual Configuration:
 Individual configuration is used in heterogeneous environments where each node
 in a given cluster may be configured differently. To enable the STN feature 
 for a specific node in the cluster, put the following stanza into its Node
-Configuration in the [`contiv-vpp.yaml`][1] deployment file, for example:
+Configuration in the \[`contiv-vpp.yaml`\]\[1\] deployment file, for example:
 ```
 ...
     NodeConfig:
diff --git a/docs/usecases/contiv/VPPTRACE.md b/docs/usecases/contiv/VPPTRACE.md
index 2b397427cb3..c9d2088266b 100644
--- a/docs/usecases/contiv/VPPTRACE.md
+++ b/docs/usecases/contiv/VPPTRACE.md
@@ -1,7 +1,7 @@
 ## Using vpptrace.sh for VPP Packet Tracing
 
 VPP allows tracing of incoming packets using CLI commands `trace add` and `show trace`
-as explained [here](VPP_PACKET_TRACING_K8S.html), but it is a rather cumbersome process.
+as explained \[here\](VPP_PACKET_TRACING_K8S.html), but it is a rather cumbersome process.
 
 The buffer for captured packets is limited in size, and once it gets full the tracing stops. The user has to manually clear the buffer content, and then repeat the trace command to resume the packet capture, losing information about all packets received in the meantime.