955: formatting changes; vrf-groups

Author: Nadia-JSch

docs/infrastructure-management/ipam/dns-zones.mdx

@@ -18,6 +18,7 @@ The DNS Zones add or edit page can be reached via the main menu, under **Resourc
     light: useBaseUrl('/assets/images/dns-zones/add_DNS_zone-light.png'),
     dark: useBaseUrl('/assets/images/dns-zones/add_DNS_zone-dark.png'),
   }}
+  style={{ width: '70%' }} 
 />
 
 To define a DNS Zone, add or edit the zone specific fields show above.

docs/infrastructure-management/ipam/subnet-tree-view.mdx

@@ -30,6 +30,7 @@ New subnets can be added to a VRF group by hovering over a VRF group and clickin
     light: useBaseUrl('/assets/images/subnet-tree-view/hover_subnet_tree-light.png'),
     dark: useBaseUrl('/assets/images/subnet-tree-view/hover_subnet_tree-dark.png'),
   }}
+  style={{ width: '80%' }} 
 />
 
 You can hover your mouse over any VRF groups, subnet, or IP and get more details on each. The subnet details includes a small graph that indicates the Percentage (%) of IP addresses used.
@@ -86,6 +87,7 @@ In the example above, you see the available subnets for the selected parent subn
     light: useBaseUrl('/assets/images/subnet-tree-view/subnet-tree-availability-2-light.png'),
     dark: useBaseUrl('/assets/images/subnet-tree-view/subnet-tree-availability-2-dark.png'),
   }}
+  style={{ width: '80%' }} 
 />
 
 These views will help you decide which subnet to assign.

docs/infrastructure-management/ipam/switch-templates.mdx

@@ -42,6 +42,7 @@ Module or Asset to show if a port belongs to a blade or fabric extender. Network
     light: useBaseUrl('/assets/images/switch-templates/Catering_to_different_switch_types_in_the_templates-light.png'),
     dark: useBaseUrl('/assets/images/switch-templates/Catering_to_different_switch_types_in_the_templates-dark.png'),
   }}
+  style={{ width: '70%' }} 
 />
 
 Whether the switch is singular, modular and/or distributed, you can add any type from the templates. Also, stacked switches and paired switches can be added. All different options are discussed below.
@@ -76,6 +77,7 @@ Taking a page from Cisco's 3750 switches, you can add multiple singular switches
     light: useBaseUrl('/assets/images/switch-templates/WEB-599_switch-template-createedit-switch-4-light.png'),
     dark: useBaseUrl('/assets/images/switch-templates/WEB-599_switch-template-createedit-switch-4-dark.png'),
   }}
+  style={{ width: '70%' }} 
 />
 
 Here you can enter a name for the cluster device(or choose an existing one) and similarly enter values for switches in the stack. Switch ports (and switches) are created based on the template.
@@ -88,6 +90,7 @@ Here you can enter a name for the cluster device(or choose an existing one) and
     light: useBaseUrl('/assets/images/switch-templates/WEB-599_switch-template-modulardistributed-switch-5-light.png'),
     dark: useBaseUrl('/assets/images/switch-templates/WEB-599_switch-template-modulardistributed-switch-5-dark.png'),
   }}
+  style={{ width: '80%' }} 
 />
 
 This type can be used to represent modular and/or distributed switches, e.g., a single 6509 switch with modules, Nexus 7k or Nexus 5k with fabric extender modules. Modules with hardware model, slot #, port prefixes and # of ports can be added here. You can also add asset templates( for Fabric Extenders) on this screen. Based on template values, you would be asked for switch/asset name etc. and it would create the switch, modules, assets(Fabric extenders) and switch ports based on the template.
@@ -100,6 +103,7 @@ This type can be used to represent modular and/or distributed switches, e.g., a
     light: useBaseUrl('/assets/images/switch-templates/WEB-599_switch-template-modularpaired-switch-6-light.png'),
     dark: useBaseUrl('/assets/images/switch-templates/WEB-599_switch-template-modularpaired-switch-6-dark.png'),
   }}
+  style={{ width: '80%' }} 
 />
 
 This template can serve few different use case scenarios. For example, Cisco VSS paired 6509s or 2 Nexus 5k running in active/active mode. You can add various port info, etc., and it will create modules/assets/switch ports. Ports on the fabric extender can be marked to show if they are connected to both the switches or just one.

docs/infrastructure-management/ipam/vlans.mdx

@@ -44,7 +44,7 @@ The VLAN number is the only required field in this form. The name is automatical
 
 With VLAN autodiscovery, all VLANs are pulled into Device42 from each switch that is discovered. During the discovery process, the system does not assume that matching VLAN numbers from different switches are the same VLAN. It is common to have duplicate VLANs after running autodiscovery. While most duplicate VLANs are actually the same VLAN, it is not always true. The **Merge selected Vlans** bulk action is available to address this by merging duplicate VLANs. There are two approaches to merging VLANs:
 
-* **Select all the VLANs in Device42 and let the system merge all matching VLAN numbers to eliminate duplicates**: As pictured in the example above, select all VLANs on the list, then choose **Merge selected Vlans** from the **Actions** dropdown menu, and click **Go**.
+**Select all the VLANs in Device42 and let the system merge all matching VLAN numbers to eliminate duplicates**: As pictured in the example above, select all VLANs on the list, then choose **Merge selected Vlans** from the **Actions** dropdown menu, and click **Go**.
 
 **Select a specific subset of VLANs you wish to merge**: For example, if VLAN #42 were discovered on 10 different switches and you knew each instance was the same VLAN, it should be merged. You would select the VLANs you want to merge, choose **Merge selected Vlans** from the **Actions** dropdown menu, then click **Go**.
 

docs/infrastructure-management/ipam/vrf-groups.mdx

@@ -8,9 +8,9 @@ import useBaseUrl from '@docusaurus/useBaseUrl'
 
 ## About VRF Groups
 
-Virtual routing and forwarding groups (VRF groups) are often used by ISPs and other larger network service providers to organize and track customers' (or their own) logical networks segments, subnets, and VLANs, some of which often overlap with IP ranges in use in other VRF groups -- _but never within the same VRF group_. The reason why is quite simple: There are really only three IP address ranges dedicated to private network use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16; however, there are thousands of end users on these networks that need to route traffic to the internet -- and in a few special cases, to each other. VRF groups to the rescue!
+Virtual routing and forwarding groups (VRF groups) are often used by ISPs and other larger network service providers to organize and track customers' (or their own) logical networks segments, subnets, and VLANs, some of which often overlap with IP ranges in use in other VRF groups - _but never within the same VRF group_. The reason why is quite simple: There are really only three IP address ranges dedicated to private network use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16; however, there are thousands of end users on these networks that need to route traffic to the internet - and in a few special cases, to each other. VRF groups to the rescue!
 
-Most VRF groups are designed so that they can't route between each other by default; however, all are able to route out to a larger network cloud (for example, the internet), thus allowing multiple customers to assign IP addresses to end users on their own networks as they please -- without interfering with one another.
+Most VRF groups are designed so that they can't route between each other by default; however, all are able to route out to a larger network cloud (for example, the internet), thus allowing multiple customers to assign IP addresses to end users on their own networks as they please - without interfering with one another.
 
 <ThemedImage
   alt="Device42 VRF Group menu item"
@@ -34,9 +34,9 @@ Device42 users can create VRF groups in Device42 to track and manage these overl
 
 **Name:** is required and must be unique among VRF groups.  
 **Description:** Free form text to enter any text.  
-**Default:** Select this checkbox to have all subnets auto-discovered added to this VRF group automatically (going forward). This option will \*not\* add existing subnets automatically. _Note that subnets are not displayed on the edit page._
+**Default:** Select this checkbox to have all subnets auto-discovered added to this VRF group automatically (going forward). This option will not add existing subnets automatically. _Note that subnets are not displayed on the edit page._
 
-If you make the VRF group the default, then subnets and IPs will be automatically assigned to this default VRF group -- unless otherwise specified.
+If you make the VRF group the default, then subnets and IPs will be automatically assigned to this default VRF group - unless otherwise specified.
 
 ## View an Existing VRF Group