A Brief Review About Basic IGMP Timers

we will quickly discuss the use of most commonly needed IGMP timers. First, as we know, multicast routers periodically query hosts on a segment. If there are two or more routers sharing the same segment, the one with the lowest IP address is the IGMP querier (per IGMPv2 election procedure – as you remember, IGMPv1 let the multicast routing protocol define the querier).

The periodic interval is defined using the command:

ip igmp query-interval [interval in secs]

The hosts on the segment are supposed to report their group membership in response to the queries. Note that IGMPv2 defines special report suppression procedure, which allows host to suppress its own report, if it saw some other host reporting the same group. The query-interval timer is also used to define the amount of time a router will store particular IGMP state if it does not hear any reports on the group. This interval is 3xquery-time and it was the only mechanism available in IGMPv1 to expire a non-needed group. By default the interval is 60 seconds.

From what we said above follows that hosts must respond to a query during some time-window interval. This time window is specified in IGMPv2 packets using special field that defines the maximum response time. You set the value of this field using the command:

ip igmp query-max-response-time [time-in-seconds]

When a host receives the query packet, it starts counting to a random value, less that the maximum response time. When this timer expires, host replies with a report, provided that no other host has responded yet. This accomplishes two purposes:

a) Allows controlling the amount of IGMP reports sent during a time window.
b) Engages the report suppression feature, which permits a host to suppress its own report and conserve bandwidth.

Naturally, the maximum response timer could not be less than the query-interval. Note that IGMPv1 does not support the maximum response time field in its packets, and this timer is fixed to 10 seconds with version 1.

The next important timer, pertaining to IGMPv2, is last member query interval. This interval is configured using the following command:

ip igmp last-member-query-interval [interval in ms]

IGMP uses this value when router hears IGMPv2 Leave report. This means that at least one host wants to leave the group. After router receives the Leave report, it checks that the interface is not configured for IGMP Immediate Leave (single-host on the segment) and if not, it sends out an out-of-sequence query. The maximum-response-time in this query is set to last-member-query-interval which is 1000ms by default. The router sends out maximum of

ip igmp last-member-query-count [number]

messages and if no one responds during this time, the router removes the IGMP state for the group. The whole procedure controls if there are any more members left on the interface. After the last query send router waits some additional time, approximately 0,5 second to finally remove the group. So by default, after a reception of the Leave message the router waits for 2x1000ms+0,5seconds before stopping the multicast traffic flow.

If the interface is configured for immediate leave for a specific group list using the command:

ip igmp immediate-leave group-list [list]

Then the router will treat these groups as having single host member. After the reception of a Leave message, the router immediately removes the multicast forwarding state.
The last interesting timer is

ip igmp query-timeout [timeout]

This timer is used by “silent” routers, i.e. the routers that lost the IGMP querier election process. If the inactive routers did not hear any query for the 2 * [timeout] interval, they start election process again.

And in the end, a quick command to learn all default IGMP timer values:

Read More

Different States Of Spanning Tree Ports

Rapid Spanning Tree 802.1w reduced the number of port states from 5 down to 3 this short blog post details the 5 STP port states for Spanning Tree 802.1d and then Rapid Spanning Tree – as always these posts are purely my study notes which I hope can be of use to somebody else and provides an easy way for me to find them again. i.e I just google Spanning Tree Port States and I can find it again wherever I am!

Spanning Tree 802.1d

    Disabled – A port in the disabled state does not participate in frame forwarding and is considered
                      non-operational
    Blocking – During blocking state, the port is listening to and processing BPDUs After 20 seconds,
                      the switch port changes from the blocking state to the listening state.
    Listening – After blocking, a root port or a designated port will move to a listening state. During
                      the listening state the port discards frames received from the attached network segment it also discards frames switched from other ports for forwarding.  At this state, the port receives BPDUs from the network segment and directs them to the switch system module for processing. After 15 seconds, the switch port moves from the listening state to the learning state.
    Learning – A port moves into the learning state after the listening state. During the learning state, the port is listening for and processing BPDUs. In the listening state, the port starts to process user frames and starts updating the MAC address table. User frames are not forwarded to the destination. After 15 seconds, the switch port moves from learning to forwarding.
    Forwarding – Once in the forwarding state the port sends traffic. In a forwarding state, the port will process BPDUs, update its MAC Address table with frames that it receives, and forward user traffic through the port. Forwarding State is the normal operational state.

Spanning Tree 802.1W – reduced the number of port states from 5 to 3 and changed Disabled, Blocking & Listening to Discarding

STP Port State    -   RSTP State
Disabled                         Discarding
Blocking                         Discarding
Listening                        Discarding
Learning                         Learning
Forwarding                   Forwarding

To learn more about Rapid Spanning Tree and the Spanning Tree Port States Cisco’s website is the place to go the link:  Click Here

Read More

The Troubleshooting of MPLS LDP

This post will go through from start to finish the configuration required to setup a basic MPLS VPN which has 2 customers, each customer has 2 sites. The configuration is all done in GNS3. The topology I will be using is below.

This MPLS tutorial will cover OSPF, LDP, MP-BGP and route redistribution.
The MPLS Core is made up of P1-P4, the Provider Edge routers are PE1 & PE2.

Step 1 is to configure the IP addresses on all devices, a prerequisite for MPLS is to have a /32 loopback address on all devices. Once all the devices has been configured as per the diagram above you need to enable OSPF.

Enable OSPF

The quickest way to enable ospf on all interfaces is to go to each interface on each router and apply the config ip ospf 1 area 0. As each device has 4 interfaces I simply applied the following text to each device
conf t
int f0/0
ip ospf 1 area 0
int f0/1
ip ospf 1 area 0
int f1/0
ip ospf 1 area 0
int f2/0
ip ospf 1 area 0
int lo0
ip ospf area 0
A quick check on a few devices just to verify OSPF is up and running
P1#sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.10.29        1   FULL/DR         00:00:37    10.0.10.26      FastEthernet2/0
10.0.0.4          1   FULL/DR         00:00:31    10.0.10.18      FastEthernet1/0
10.0.0.2          1   FULL/DR         00:00:39    10.0.10.10      FastEthernet0/1
10.0.0.3          1   FULL/DR         00:00:36    10.0.10.2       FastEthernet0/0
P1#
P4#sh ip ospf neigh
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.5          1   FULL/BDR        00:00:33    10.0.10.38      FastEthernet2/0
10.0.0.1          1   FULL/BDR        00:00:38    10.0.10.17      FastEthernet1/0
10.0.0.3          1   FULL/BDR        00:00:33    10.0.10.13      FastEthernet0/1
10.0.0.2          1   FULL/BDR        00:00:33    10.0.10.5       FastEthernet0/0
P4#
We can assume that OSPF is fully configured across all devices and we have full reachability to all addresses. The next step is to enable MPLS. Enabling MPLS is actually a very simple configuration task. You just apply the command mpls ip to any interface you want to run MPLS on.
For this topology on P1-P4 all interfaces need to have mpls enabled.
Apply this config to P1,P2,P3,P4
conf t
int f0/0
mpls ip
int f0/1
mpls ip
int f1/0
mpls ip
int f2/0
mpls ip
Once this has applied you can verify which interfaces are running mpls with the command sh mpls interfaces
P4#sh mpls interfaces
Interface              IP            Tunnel   Operational
FastEthernet0/0        Yes (ldp)     No       Yes
FastEthernet0/1        Yes (ldp)     No       Yes
FastEthernet1/0        Yes (ldp)     No       Yes
FastEthernet2/0        Yes (ldp)     No       Yes
From here you can see that all interfaces on P4 are running MPLS and are using LDP as the label distribution protocol. Once you have configured MPLS on all the other P devices you can see the mpls neighbors come up.
*Mar  1 00:25:48.455: %LDP-5-NBRCHG: LDP Neighbor 10.0.0.3:0 (1) is UP
*Mar  1 00:25:48.463: %LDP-5-NBRCHG: LDP Neighbor 10.0.0.4:0 (2) is UP
You can now verify all the the ldp adjacencies with sh mpls ldp neighbor
P2#sh mpls ldp neigh
Peer LDP Ident: 10.0.0.3:0; Local LDP Ident 10.0.0.2:0
TCP connection: 10.0.0.3.46880 – 10.0.0.2.646
State: Oper; Msgs sent/rcvd: 19/19; Downstream
Up time: 00:02:24
LDP discovery sources:
FastEthernet1/0, Src IP addr: 10.0.10.22
Addresses bound to peer LDP Ident:
10.0.10.2       10.0.10.13      10.0.10.22      10.0.10.33
10.0.0.3
Peer LDP Ident: 10.0.0.4:0; Local LDP Ident 10.0.0.2:0
TCP connection: 10.0.0.4.21919 – 10.0.0.2.646
State: Oper; Msgs sent/rcvd: 19/19; Downstream
Up time: 00:02:24
LDP discovery sources:
FastEthernet0/0, Src IP addr: 10.0.10.6
Addresses bound to peer LDP Ident:
10.0.10.6       10.0.10.14      10.0.10.18      10.0.10.37
10.0.0.4
You now need to configure MPLS on the two interfaces facing the MPLS Core on PE1 and PE2. Do not configure MPLS on the customer facing interfaces.

 Configure VRF

The next step is to configure the VRF’s on the Provider Edge routers. You need to assign each VRF a route distinguisher and a route target – if you are unsure about the difference between a RD and RT check out my post – route distinguisher vs route target
For this tutorial I am going to use VRF A and VRF B and the the value of 64512:1 for Site A and 64512:2 for Site B. I will use the value 1:1 for route-target for site A and 2:2 for route-target for site

B
PE1(config)#ip vrf A
PE1(config-vrf)#rd 64512:1
PE1(config-vrf)#route-target both 1:1
PE1(config-vrf)#exit
PE1(config)#ip vrf B
PE1(config-vrf)#rd 64512:2
PE1(config-vrf)#route-target 2:2
PE2(config)#ip vrf A
PE2(config-vrf)#rd 64512:1
PE2(config-vrf)#route-target both 1:1
PE2(config-vrf)#exit
PE2(config)#ip vrf B
PE2(config-vrf)#rd 64512:2
PE2(config-vrf)#route-target 2:2

Read More

The Troubleshooting Of MPLS Layer 3 VPNs

I would like to dedicate this post to MPLS L3 VPNs troubleshooting and more particularly using the Traceroute command. It can be sometimes difficult to find out where is the issue when testing connectivity between sites attaches to a MPLS VPN backbone. I will explain the behavior of Traceroute in MPLS VPN environment which is quite different than in “classical” IP environment. Finally I will talk about the MPLS LSP Ping feature and how to use it to detect break in MPLS LSP.

Topology:

I am using almost the same topology as the one used in this post: Basic MPLS. I have just added a P router.

 Platform/IOS:

 Cisco 2691/12.4(15)T11 Adv IP services

 First of all if you want to get a basic understanding of MPLS and MPLS Layer 3 VPNs I suggest to read my previous posts: Basic MPLS and MPLS Layer 3 VPNs

 The following is already configured:

    MP-iBGP between R2 and R5
    EBGP between R2 and R1, R5 and R6
    OSPF area 0 between R2,R3,R4,R5
    LDP between R2,R3,R4,R5
    R3 and R4 are P routers and R2 and R5 are PE routers
    R1 is representing the CE device at Site A announcing its loopback address 1.1.1.1/32
    R2 is representing the CE device at Site B announcing its loopback address 6.6.6.6/32

 In this troubleshooting scenario we want to focus on the loopbacks reachability between Site A and Site B.

Read More

Basic Configuration Of MPLS

I would like to share a basic MPLS configuration example where I will explain how MPLS works and what are the different steps in order to configure it. This example is not related to MPLS layer 3 VPNs, this is just going to be the basic underlying logic of how an MPLS tunnel on its own works so I will neither talk about VRF nor MP-BGP which is the VPNv4 address family in order to exchange the customer routes and the MPLS VPN labels.

 Let´s consider the following topology:

PE routers R2 and R4
P router: R3
CE routers R1 and R5

MPLS router functionality is divided into two major parts: The control plane and the data plane.

    At the control plane we have the following protocols in this topology OSPF, BGP and LDP. OSPF is the core IGP which is the base for building the EBGP session between R2 and R4 but also in order for LDP to associate a label to each learned OSPF prefixes in the core. LDP uses the LIB and the LFIB. The LIB is at the control plane and it is the database used to stored prefix/label binding advertised and received by LDP where an IP prefix is assigned a locally significant label that is mapped to a next-hop label that has been learned from a neighbour.

    At the data plane we have the LFIB (Label Forwarding Information Base) and the FIB. The LFIB is used to forward packets based on labels. LDP adds labels to the FIB and the LFIB which means that when a PE router receives an unlabeled packet it will consult its FIB and send the packet as labeled based on the FIB content. On the other hand when a P router receives a labeled packet it will only use its LFIB to forward it.

Let´s enable MPLS on the R2, R3, R4 core interfaces. As soon as we enable MPLS each adjacent router discover each other through LDP (default ). From the debug mpls ldp bindings on R2 we can see the following output:

 

From the above output we can see that R2 is advertising the labels for all the prefixes it has in its routing table. All the connected routes of R2 like its loopback will be advertised with encoded label of 3. This label instructs upstream routers to remove the label instead of swapping it. What will be displayed in the routing table of the neighbor router will be “imp-null” rather than the value 3 or 1 for TDP. R2 also receives labels information from its LDP neighbor R3 where for example R3 advertises label 17 for prefix 4.4.4.4/32 which is the loopback of R4.

By default LDP peers will advertise a label/prefix binding for all the routes present in the routing table. We can see that from the above output because R2 is advertising LDP entries for networks that it has learned from R3 (for example 4.4.4.4/32 and 10.0.34.0/24).

 Let´s look at the LFIB of R2 now and see which labels it has learned from R3:

 

 10.0.34.0/24 prefix is associated with a Pop tag action which means that all traffic forwarded to this prefix should not be labeled by R2. R2 has been instructed to do that by R3 in the LDP labels exchange process (see the first output where R3 tells R2 that 10.0.34.0/24 should be associated with out label imp-null -> labels for: 10.0.34.0/24; nh 10.0.23.3, Fa0/1, inlabel 18, outlabel imp-null (from 3.3.3.3:0). The Pop tag action means that Penultimate Hop Popping mechanism is in use. PHP optimizes MPLS performance as it eliminates one LFIB lookup, in this case on R4. So R4 will only do a FIB lookup and not a LFIB lookup first and then a FIB look up.

Read More

Learning Basic QoS part 2 – Catalyst 3560 QoS

In this post I will talk about Cisco Catalyst 3560 QoS. In Basic QoS part 1 I talked about policing and shaping on Cisco IOS routers.

 To illustrate the different examples in this post I will use the following topology:

IGP: EIGRP 10

 Platform/IOS: Catalyst 3560/ c3560-advipservicesk9-mz.122-44.SE6.bin

 Catalyst 3560 QoS Port-Based Classification

 As long as the QoS in not enabled with the command mls QoS, the QoS values in the packets are left intact when flowing through SW1 and SW2. That can be verified as follows:

As we can see from the output above, SW1 has QoS disabled (default) and is seeing packets from R1 marked with DSCP 48 (These are EIGRP updates, since routing traffic uses IP precedence of six which corresponds to DSCP 48). All incoming routing updates bear COS value of zero, since IOS does not set the COS field by default.

Let´s verify on R2 if packets with DSCP 48 are received by the control-plane:

Side note: In order to get the debug output above I just configured a policy-map matching DSCP 48 which is attached to the control-plane. Then under the class-map I configured the log keyword.

 Now let´s just reset the counters on the policy-map on R2 (clear control-plane *) and let´s enable QoS on SW1.

So as soon as we enable QoS on SW1, the port connected to R1 is in an untrusted state which means that any markings will be rewritten by the switch to zero which in turns means that R2 will not see EIGRP packet marked with DSCP of 48 but with a DSCP of zero:

As a matter of fact SW1 is still receiving packet sent by R2 with a DSCP of 48 via the trunk link connected to SW2:

But as we can see in the output above SW1 is sending packets toward R2 from R1 out the trunk link with a DSCP of zero.

 Side note: Just as a little reminder, CoS bits (three bits) is located in 802.1q/ISL header of a tagged frame. Those bits are known as 802.1p priority bits and are used for L2 QoS. ToS field (8 bits) located in the IP header is used for L3 QoS. 6 bits in the ToS field represent the DSCP value.

 In order to keep the DSCP value sent by R1 intact we configure R1 to trust the port connected to R1 (F0/1). This step forms part of the classification stage. You may classify using either interface level setting or by applying a pre-configured policy-map. Here is how classification works on the catalyst 3560:

     Trust DSCP or IP precedence (higher 3 bits in ToS field): For IP packets we can either trust on IP precedence or on DSCP value. When you trust DSCP the switch resolve the CoS value using the DSCP to CoS mapping table. When trusting IP precedence (IPP) the switch resolve the DSCP value using the IP precedence to DSCP mapping

    Trust CoS: Works for both IP and non-IP packets (ARP for example). If no CoS present in the 802.1q/ISL header the default CoS value assigned on the interface is used. The IPP and DSCP value are not taking into account and the DSCP/IPP value will be rewrite in the packet using the CoS to DSCP mapping table.

Read More

Zone Based Firewall By Cisco

In this post I will talk about Cisco Zone Based Firewall (ZBF) which is a new approach to configure access control in the IOS firewall. I will first make an introduction to ZBF and then I will demonstrate how to configure it.

To illustrate the different examples in this post I will use the following topology:

  

IGP: EIGRP AS 10

 Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services.

 Side note: As I am using IOS 12.4(15)T I will only talk about ZBF rules for this IOS release. Some improvements and rules changes have been made in the last IOS releases (IOS 15.X).

 IP addressing: All routers in the topology are configured with loopback IP in the format X.X.X.X /32 where X is the router number.

Introduction to ZBF
 Before this feature, firewalling in IOS was configured using a combination of ACLs and inspection rules (CBAC), both applied directly to interfaces which may poorly reflect organization´s security policy. With Zone Based Firewall (ZBF) different interfaces are grouped into zones, sharing the same security attributes, the same level of trust. The router itself is in a zone per default called the self zone. Here are the important facts about ZBF: (for IOS 12.4(15)T):

     Interfaces in the same zone can communicate with each other
    Interfaces in different zones cannot communicate with each other by default
    Traffic from and to the self zone to any other zone is allowed by default to allow for control plane and management traffic
    ZBF implements the same set of features as CBAC
    ZBF configuration uses a configuration framework called Cisco Policy Language (CPL) similar to MQC used for configuring QoS for example
    ZBF can inspect, pass, drop or rate limit traffic
    Class-map type inspect are used to match the traffic that the Firewall should inspect, pass, drop or rate-limit
    Policy-map type inspect are used to set an action (pass, inspect, rate-limit or drop) on the traffic matched in the class-map
    Zone-pair are used to define the traffic flow direction.
    If the inspect keyword is used in a policy-map then the class-map must have at least one “match protocol” statement to specify the protocols for inspection. Otherwise all protocols will be inspected
    If a policy is applied for traffic from a zone to self zone, traffic from self zone to the other zone will be permitted but returning traffic may me blocked
    Stateful inspection router-generated traffic is limited to TCP, UDP and ICMP and H.323. Application inspection (HTTP,FTP,Telnet, etc.) is not available for self-zone policies.
    Rate-limiting cannot be configured on self-zone policies
    Stateful inspection support for multicast traffic is not supported between any zones, including the self zone

ZBF Configuration
 Let´s assign each interface to a zone as illustrated by the topology. To demonstrate that interface in the same zone can communicate with each other’s I will assign R2 and R4 in the zone inside. To test will ping from R2 to R4: 

Now Come on ping:

Great! Let us check by assigning R4 to zone outside and ping one more time:

Alright, that demonstrates that interfaces in different zone cannot communicate with each other´s.

The router itself is a member of the self zone and by default this zone is not limited from communicating with other zones. Although we cannot ping anymore from R2 to R4 as they are in different zones, the router can still ping to zone inside and outside: 

 

Now check by assigning R3 to the DMZ zone:

Great! So now let´s define the following security policy:

1) R1 should only be managed from the outside zone using the following protocols: Telnet, SSH and HTTP. Furthermore ICMP to R1 coming from the outside should be allowed.

2) Only Inside user 2.2.2.2 (represented in this example by the loopback of R2) is allowed to surf the Internet (represented by R4) using HTTP and to send DNS request to the Internet. Telnet and SSH to the Internet should also be allowed

3) Outside user (represented by R4 loopback) is allowed to reach the DMZ server (represented by R3) on port 80 as well as ping it

4) ICMP and telnet originated by the router itself should be permitted to any zone

Let´s start by implementing the 1 policy requirement which is about the self zone and the outside zone. The flow direction is from outside to self. Only Telnet, SSH, HTTP and ICMP are allowed. So let´s configure the following:

ZBF policy 1

So let´s test to SSH to R1 from R4:

 

On R1 we can see that the ZBF is matching SSH packets and pass them:

But what happen if we telnet from R1 to R4:

So R1 is blocking the returning traffic when originated from R1 itself. So if we wanted to allow returning traffic we could create a new policy inspecting TCP, UDP and ICMP (as self zone does not allow for advanced application inspection) from self zone to outside zone. As we are only passing traffic in our example there is no inspection.

Side note: Please not that although we are passing traffic from out to self the returning traffic from the router is automatically allowed back as we have not configured any zone-pair from self to outside.

Side note 2: Another point here is that we didn´t explicitly allowed EIGRP traffic in the policy but the neighbor relationship between R1 and R4 is still up and running. I guess that may be an issue related to the IOS version I am using or maybe related to GNS3.

ZBF policy 2

Perfect! Let´s implement policy number 2. The policy states that inside user (2.2.2.2 -> R2 loopback) is allowed to surf the internet (represented by R4), send DNS query to the outside as well as using telnet and SSH. Let´s configure the following to reflect this policy:

In the above configuration we are using class-map nesting in order to achieve an advanced matching. Here in the ACL we used permit ip but we could have been more specific by only allowing TCP,UDP and ICMP. But as we are only inspecting certain type of traffic it is alright.

So let´s try to make a DNS request. R4 is configured as the DNS server:

So R4 is resolving the DNS query and R2 can then telnet to R4. R1 is allowing both the DNS query and the telnet session as we are inspecting these two protocols in our policy:

The output above confirm that R1 is inspecting both sessions (DNS and TELNET), allowing return traffic from outside to inside zone.

ZBF policy 3

Let´s implement policy number 3 which states that outside user (represented by R4 loopback 4.4.4.4/32) is allowed to reach a DMZ server via TCP on port 80 as well as ping it. All other traffic from this user towards the DNS or the INSIDE zone should be denied. So let´s configure the following to reflect this policy:

Again here we are nesting a class-map in another in order to achieve our goal. The ACL only allowed TCP traffic and ICMP from R4 to R3 and we are only inspecting HTTP and ICMP traffic which means that traffic which is TCP but not HTTP will be dropped by the class-default. Let´s test it:

To test we just copy the running-config of R3 located in flash to null via HTTP:

So we can see that HTTP traffic is being inspected and it is allowed from outside to the DMZ zone. However as we inspect only HTTP traffic, a telnet to R3 will not work as it is not seen as HTTP traffic even if it is TCP traffic:

Let´s ping:

ZBF policy 4
 So let´s implement the last policy which concerns telnet and ping traffic originated from the router itself should be allowed to any zone. So let´s configure the following to reflect this policy:

Here basically as self zone can only inspect on ICMP, TCP, UDP and H,323 we are forced to use a combination of ACL and inspection on TCP and ICMP. If traffic is permitted by the ACL (telnet and ICMP) and the protocol is ICMP or TCP, let the traffic through and inspect TCP and ICMP sessions. So here we are doing basic inspection traffic. Let´s test:

The same will work for telnet but not SSH for example:

The SSH session is effectively dropped as only telnet is inspected.

So now we have implemented our security policy so let´s see what other features ZBF offers:

ZBF Rate Limiting

Let´s see some facts about ZBF rate-limiting first:

    Rate-limiting applies only for traffic moving between zones and not out/in of a single interface
    Use the syntax police rate <RATE> <BURST> under a policy-map
    Traffic exceeding is dropped
    ZBF also supports rate-limiting for limiting the max number/rate of half-open connections for UDP/TCP sessions. This configuration is achieved using a parameter-map which you apply to the inspected traffic for a specific class
    Not supported for zone self

Here I will just demonstrate how to configure ZBF for rate-limiting between security zones.

For example we could limit the amount of ICMP traffic sent from the OUTISDE zone to the DMZ zone. So let´s say that no more than 128 Kbit/s of ICMP traffic should be allowed from the OUTSIDE zone to the DMZ zone.

From the earlier configuration tasks we have already defined the following policy-map for traffic flowing from the OUTSIDE zone the the DMZ zone:

So we just modify the above configuration and add the following line:

So let´s test the above configuration:

Another feature of ZBF is to be able to do application inspection (Level 7 of the OSI models) which I will not develop in this post. Thanks to this feature you can do granular inspection filtering for example on GET/POST for HTTP or filter HTTP GET requesting a file called image.jpg. Application inspection uses a special type of class-map and policy-map in the format: class-map type inspect <PROTOCOL NAME>. The same apply to policy-map. This special type of policy-map must call the special type of class-map and be nested as a child policy under the normal inspect policy map.

Read More

Explaining Difference Between BPDU Filtering Vs BPDU Guard

BPDU Filtering, BPDU Guard, and Root Guard are STP security mechanisms. In this post I will only describe BPDU Filtering and BPDU Guard.

These 2 features provide protection against spanning-tree loops being created on ports where PortFast has been enabled. A device attached to a PortFast interface is not supposed to send BPDUs but should this happen BPDU Filtering and BPDU Guard provide protection.

BPDU Guard and BPDU Filtering can be configured in 2 different ways, from global configuration mode or in interface configuration mode. In global configuration mode the feature (either BPDU guard or BPDU Filtering) will have effect on PortFast enabled port only. In interface configuration mode it will only affect  a specified port.

BPDU Guard
PortFast should be configured on port where bridging loops are not expected to form (which means that no BPDUs should be receive on these ports), such as on end-devices port like a single workstation or server. PortFast provides quick network access by entering directly in STP forwarding state (bypassing listning and learning state). Even if PortFast can detect a bridging loop (While PortFast is enabled on a port, STP is still running), it will detect it in a finite amount of time that is to say the length of time required to move the port through the normal STP states.

If any BPDUs  (superior to the current root or not) are received on port configured with BPDU Guard that port is put immediately in errdisable state.

If configured in global configuration mode BPDU Guard will be enable on all configured PortFast ports:

 

If configured in interface configuration mode it will only be enable on the specific port:

 

BPDU guard should be configured on all switchs ports where STP PortFast is enabled. This prevents any possibility that a switch will be added to the port  either intentionally or by mistake.
BPDU Filtering

BPDU Filtering allows to stop sending/receiving BPDUs on a port depending on how is configured.

If it is configured from global configuration mode BPDU Filtering will be enabled on all configured PortFast ports. No BPDUs will be sent out of that port which will hide STP  topology to end-users.  But as soon as a BPDU is received the port will lose  is PortFast status and  BPDU Filtering will be disabled. The port is then taking back to normal STP operation and sends/receives BPDUs. See bellow for how to configure BPDU Filtering from global configuration mode:

If BPDU Filtering is configured from the interface configuration mode the result is completely different as this will cause the specific port to stop sending AND receiving (BPDUs are dropped) BPDUs. Tthe port ignores any incoming BPDUs and changes to Forwarding state. this solution is not recommended as it can result in bridging loops.

Important: If you enable BPDU Guard on the same interface as BPDU Filtering, BPDU Guard has no effect because BPDU Filtering takes precedence over BPDU Guard. Configuation of BPDU Filtering is not a recommended configuration.

Read More