Trending Topics

VMware on AWS - How to restore NSX DFW firewall rules to previous state

Customers who uses NSX day-in, day-out would like to have a point-in time restore functionality of DFW firewall rules. Many customer have a large footprints in VMC and make changes to DFW quite often. This feature was missing for long time and we could see its included in recent versions . Let's see how DFW configuration roll back works  NSX DFW configuration has versioning, and it is stored in the NSX Manager.  Every time when someone update DFW configuration, NSX creates one more version but keep storing the previous ones. You can rollback for previous config but reapplying it once again.  You can find the options under Networking & Security tab , > Security > Distributed Firewall . In the right side we see an Actions drop down. Choose View to get to the below screen.  Let’s go through the use case:  1. Original state- default config with no custom rules:  a. There are no saved configurations during last 30 days: In my existing test setup, with the current setting

C. Trunking

·         VLANs are local to each switch's database, and VLAN information is not passed between switches.
·         Trunk links provide VLAN identification for frames traveling between switches.
·         Cisco switches have two Ethernet trunking mechanisms: ISL and IEEE 802.1Q.
·         Certain types of switches can negotiate trunk links.
·         Trunks carry traffic from all VLANs to and from the switch by default but can be configured to carry only specified VLAN traffic.
·         Trunk links must be configured to allow trunking on each end of the link.

Enabling Trunking

Trunk links are required to pass VLAN information between switches. A port on a Cisco switch is either an access port or a trunk port. Access ports belong to a single VLAN and do not provide any identifying marks on the frames that are passed between switches. Access ports also carry traffic that comes from only the VLAN assigned to the port. A trunk port is by default a member of all the VLANs that exist on the switch and carry traffic for all those VLANs between the switches. To distinguish between the traffic flows, a trunk port must mark the frames with special tags as they pass between the switches. Trunking is a function that must be enabled on both sides of a link. If two switches are connected together, for example, both switch ports must be configured for trunking, and they must both be configured with the same tagging mechanism (ISL or 802.1Q).
To enable trunking between the switches, use the following steps:
1.      Enable trunking on a port.
a.       Enable the trunk:
COS set trunk mod/port [auto | desirable | on | nonegotiate | off]
IOS (global) interface type mod/port
(interface) switchport mode dynamic [auto | desirable]
(interface) switchport mode trunk
(interface) switchport nonegotiate

b.      The most basic way to configure a trunk link is using the option on. This option enables the trunk and requires that you also specify a tagging mechanism for the trunk. For IOS devices, the command switchport mode trunk is equivalent to the set trunk mod/port on command. When specifying the option on, you must also choose a tagging mechanism (see Step 1b).
c.       Some IOS switches do not support Dynamic Trunking Protocol. For these switches, the only command that you can use to configure trunking is switchport mode trunk, which essentially turns trunking on.
d.      Many Cisco switches employ an automatic trunking mechanism known as the Dynamic Trunking Protocol (DTP), which allows a trunk to be dynamically established between two switches. All COS switches and integrated IOS switches can use the DTP protocol to form a trunk link. The COS options auto, desirable, and on and the IOS options of dynamic auto, dynamic desirable, and trunk configure a trunk link using DTP. If one side of the link is configured to trunk and will send DTP signals, the other side of the link will dynamically begin to trunk if the options match correctly.
e.       If you want to enable trunking and not send any DTP signaling, use the option nonegotiate for switches that support that function. If you want to disable trunking completely, use the off option for a COS switch or the no switchport mode trunk command on an IOS switch.
f.       Table 6-2 shows the DTP signaling and the characteristics of each mode.
g.      It is important to remember that not all switches support DTP and might not establish a trunk without intervention. Also remember that DTP offers no benefit when you are trunking with a non-Cisco switch. To eliminate any overhead associated with DTP, it is useful to use the nonegotiate option when DTP is not supported.
h.      When enabling trunking, it is not possible to specify a range of ports.

i.       Table 6-2 Trunking Mode Characteristics

Trunking Mode Characteristics
COS = on
IOS = mode trunk
Trunking is on for these links. They will also send DTP signals that attempt to initiate a trunk with the other side. This will form a trunk with other ports in the states on, auto, or desirable that are running DTP. A port that is in on mode always tags frames sent out the port.
COS = desirable
IOS = mode dynamic desirable
These links would like to become trunk links and will send DTP signals that attempt to initiate a trunk. They will only become trunk links if the other side responds to the DTP signal. This will form a trunk with other ports in the states on, auto, or desirable that are running DTP. This is the default mode for the 6000 running Supervisor IOS.
COS = auto
IOS = mode dynamic auto
These links will only become trunk links if they receive a DTP signal from a link that is already trunking or desires to trunk. This will only form a trunk with other ports in the states on or desirable. This is the default mode for COS switches.
COS = nonegotiate
IOS = mode nonegotiate
Sets trunking on and disables DTP. These will only become trunks with ports in on or nonegotiate mode.
COS = off
IOS = no switchport mode trunk
This option sets trunking and DTP capabilities off. This is the recommended setting for any access port because it will prevent any dynamic establishments of trunk links.

j.        Cisco 2950 and 3500XL switches do not support DTP and are always in a mode similar to nonegotiate. If you turn trunking on for one of these devices, it will not negotiate with the other end of the link and requires that the other link be configured to on or nonegotiate.
k.      Specify the encapsulation method:
COS set trunk mod/port [negotiate | isl | dot1Q]
IOS (global) interface type mod/port
(interface) switchport trunk encapsulation [negotiate | isl | dot1Q]

l.        The other option when choosing a trunk link is the encapsulation method. For Layer 2 IOS switches, such as the 2900XL or the 3500XL, the default encapsulation method is isl. You can change from the default with the switchport trunk encapsulation command. For COS switches or integrated IOS switches, the default encapsulation is negotiate. This method signals between the trunked ports to choose an encapsulation method. (ISL is preferred over 802.1Q.) The negotiate option is valid for auto or desirable trunking modes only. If you choose on as the mode or if you want to force a particular method or if the other side of the trunk cannot negotiate the trunking type, you must choose the option isl or dot1Q to specify the encapsulation method.
m.    Not all switches allow you to negotiate a trunk encapsulation setting. The 2900XL and 3500XL trunks default to isl and you must use the switchport trunk encapsulation command to change the encapsulation type. The 2950 and some 4000 switches support only 802.1Q trunking and provide no options for changing the trunk type.
n.      (Optional) Specify the native VLAN:
COS set vlan number mod/port
IOS (global) interface type mod/port
(interface) switchport trunk native vlan number

o.      For switches running 802.1Q as the trunking mechanism, the native VLAN of each port on the trunk must match. By default all COS ports are in VLAN 1; and the native VLAN on the IOS devices is also configured for VLAN 1, so the native VLAN does match. If you choose to change the native VLAN, use the set vlan command for COS switches or the switchport trunk native vlan command for IOS switches to specify the native VLAN. Remember that the native VLAN must match on both sides of the trunk link for 802.1Q; otherwise the link will not work. If there is a native VLAN mismatch, Spanning Tree Protocol (STP) places the port in a port VLAN ID (PVID) inconsistent state and will not forward on the link.
p.      Cisco Discovery Protocol (CDP) version 2 passes native VLAN information between Cisco switches. If you have a native VLAN mismatch, you will see CDP error messages on the console output.

Specifying VLANs to Trunk

By default a trunk link carries all the VLANs that exist on the switch. This is because all VLANs are active on a trunk link; and as long as the VLAN is in the switch's local database, traffic for that VLAN is carried across the trunks. You can elect to selectively remove and add VLANs from a trunk link. To specify which VLANs are to be added or removed from a trunk link, use the following commands.
1.      (Optional) Manually remove VLANs from a trunk link:
COS clear trunk mod/port vlanlist
IOS (global) interface type mod/port
(interface) switchport trunk allowed vlan remove vlanlist

2.      By specifying VLANs in the vlanlist field of this command, the VLANs will not be allowed to travel across the trunk link until they are added back to the trunk using the command set trunk mod/port vlanlist or switchport trunk allowed vlan add vlanlist.

Verifying Trunks

1.      After configuring a port for trunking, use one of the following commands to verify the VLAN port assignments:
COS show trunk [mod] [mod/port]
IOS (privileged) show interface type mod/port switchport
show interfaces trunk
show interface [mod] [interface_id] trunk

2.      The commands show interfaces trunk and show interface [mod] [interface_id] trunk are not available on all switches that run IOS.

Feature Example

Network Diagram for Trunk Configuration on Access_1, Distribution_1, and Core_1
An example of the Catalyst OS configuration for Distribution_1 follows:
Distribution_1 (enable)>clear trunk 1/1 2-1001
Distribution_1 (enable)>set trunk 1/1 desirable isl 10
Distribution_1 (enable)>clear trunk 2/1 2-1001
Distribution_1 (enable)>set trunk 2/1 on dot1q 5,8,10
An example of the Catalyst OS configuration for Core_1 follows:
Core_1 (enable)>clear trunk 1/1 2-1001
Core_1 (enable)>set trunk 1/1 10
An example of the Supervisor IOS configuration for Core_1 follows:
Core_1(config)#interface gigabitethernet 1/1
Core_1(config-if)#switchport encapsulation negotiate
Core_1(config-if)#switchport mode dynamic auto
Core_1(config-if)#switchport trunk allowed vlan remove 2-1001
Core_1(config-if)#switchport trunk allowed vlan add 10
Core_1 (config-if)#end
Core_1#copy running-config startup-config
An example of the Layer 2 IOS configuration for Access_1 follows:
Access_1 (config)#interface gigabitethernet 0/1
Access_1 (config-if)#switchport mode trunk
Access_1 (config-if)#switchport trunk encapsulation dot1q
Access_1 (config-if)#switchport trunk allowed vlan remove 2-1001
Access_1 (config-if)#switchport trunk allowed vlan add 5,8,10
Access_1 (config-if)#end
Access_1#copy running-config startup-config

Popular posts from this blog


DNS Scavenging.

AD LDS – Syncronizing AD LDS with Active Directory