IPSEC Configuration (CLI)

R4---R1(gi0/0)----(gi0/0)R2----R3---R5

Tunnel between R1 and R3

Crypto-Map:

=========

*Crypto-Map is a data-plane filter

*Traffic is matched using ACLs

            They define proxy IDs for IPSEC phase 2

            What should be encrypted

Applying Crypto-Maps:

----------------------------

*They are applied to physical interfaces

            - Only one crypto map per interface

            - Always outbound with respect to traffic direction

*One crypto map can apply to multiple interfaces

            -Entries processes top-down until ACL match occurs

            -Order is important

* Tunnel source defaults to interface ip

-Can be changed using command “crypto map MAP crypto-map local-address lo0”

* Applied to link level

            - Interface closest to destination

            -Multiple routes means multiple interfaces

Crypto-Map Order of Operations:

-----------------------------------------

*Encryption applies after routing

*Encryption applies after NAT.

*crypto, routing and NAT are independent of each other.

High Level Configuration Steps:

=======================

>> Define Phase 1 ISAKMP Policy

            crypto isakmp policy 10

>> Define Phase 2 IPsec Policy

>> Apply Crypto Map

>> Generate Interesting Traffic

Phase 1:

---------

*Define Phase 1 ISAKMP Policy

            crypto isakmp policy 10

->Authentication

            authentication pre-share

->Encryption

            encr aes 192

->Hash

            hash sha384

->DH group

            group 5

->Lifetime

*Applying isakmp peer and pre-shared key is done using :

            crypto isakmp key <pw> address <peer address>

*Policy is processes top-down until a match occurs by the responder

            -Based on policy priority (Lower value higher precedence)

Phase 2 & Applying Cryptomap:

----------------------------------------

* Define Phase 2 IPsec Policy

            crypto map MAP1 10 ipsec-isakmp

-> Who – Define peer address, hostname

            set peer 20.1.1.2

-> What – Define Proxy-ACL

            match address R1

-> How – Define Transform set

            set transform-set ESP_AES_192_SHA1

Defining Transform-set :

crypto ipsec transform-set ESP_AES_192_SHA1 esp-aes 192 esp-sha-hmac

 mode tunnel

Generate Interesting Traffic:

----------------------------------

ip access-list extended R1

 permit ip 5.1.1.0 0.0.0.255 25.1.1.0 0.0.0.255

Default Policies:

--------------------

*IOS includes default fallback policies

*It has both default isakmp and ipsec policies.

*Can be disabled using “no crypto isakmp default policy” and “no crypto ipsec      transform-set default”

*Both are active until user configured values are applied

Full Configuration:

===============

=============================

crypto isakmp policy 10

 encr aes 192

 hash sha384                                                                                     **PHASE 1**

 authentication pre-share

 group 5

crypto isakmp key cisco address 20.1.1.2    

==================================== 

crypto map MAP1 10 ipsec-isakmp

 set peer 20.1.1.2

 set transform-set ESP_AES_192_SHA1                                           **PHASE 2**

 match address R1

crypto ipsec transform-set ESP_AES_192_SHA1 esp-aes 192 esp-sha-hmac

 mode tunnel

ip access-list extended R1

 permit ip 5.1.1.0 0.0.0.255 25.1.1.0 0.0.0.255

====================================

interface GigabitEthernet0/0

 ip address 10.1.1.1 255.255.255.0

 crypto map MAP1

end

SHOW Commands:

===============

* show crypto isakmp sa  --- result of phase 1 negotiation

* debug crypto isakmp sa --- step-by-step phase 1 negotiation

* show crypto ipsec sa --- result of phase 2 negotiation

* debug crypto ipsec --- step-by-step phase 2 negotiation

* show crypto isakmp policy

* show crypto isakmp key

* show crypto ipsec transform-set

* show crypto debug-condition

* show crypto map interface


GRE With IPSEC:
=============

crypto isakmp policy 10
 encr aes 192
 hash sha384
 authentication pre-share
 group 5
crypto isakmp key cisco address 3.3.3.3      
!
!
crypto ipsec transform-set ESP_SA esp-aes 192
 mode tunnel
!
!
!
crypto map MAP1 local-address Loopback0
crypto map MAP1 10 ipsec-isakmp
 set peer 3.3.3.3
 set transform-set ESP_SA

 match address GRE

interface Tunnel0
 ip address 13.1.1.1 255.255.255.0
 ip mtu 1416
 tunnel source Loopback0
 tunnel destination 3.3.3.3

interface GigabitEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 ip ospf 1 area 0
 crypto map MAP1

ip access-list extended GRE
 permit gre any any

IPSEC VTI:
========

crypto isakmp policy 10
 encr aes 192
 hash sha384
 authentication pre-share
 group 5
crypto isakmp key cisco address 3.3.3.3

crypto ipsec profile PFI
 set transform-set ESP_SA

crypto map MAP1 local-address Loopback0

interface Tunnel0
 ip address 13.1.1.1 255.255.255.0
 tunnel source Loopback0
 tunnel mode ipsec ipv4
 tunnel destination 3.3.3.3
 tunnel protection ipsec profile PFI
!

interface GigabitEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 ip ospf 1 area 0
 media-type gbic
 speed 1000
 duplex full
 negotiation auto
end

BFD

https://www.youtube.com/watch?v=iv-vubxkhTI

IPSEC basic

IPSEC Control Plane:
-------------------------
ISAKMP & IKE negotiation

IPSEC Data Plane:
----------------------
ESP & AH encapsulations

IPSEC Features:
-------------------
->Authentication
          Who did the packet come from
->Integrity
          Was the packet changed in the transit
->Confidentiality
         Can anyone read packet during transit
-> Anti-Replay
         Did I already receive the packet

*Tunnels are dynamically created by IKE.

IPSEC use 2 data structures to build a tunnel
-----------------------------------------------------

->Security Associations:
         &An agreement of IPsec Parameters
         &Maintains encryption and authentication keys on peers
->Security Parameter Index (SPI):
        &Field in packet header to identify SA on receiver
        &Similar to vlan header or MPLS label



ISAKMP vs IKE:
--------------------

*they are negotiation protocols used to form SA's

->ISKAMP:
       ISKAMP is the framework
       Says that authentication and keying should occur

->IKE:
       IKE is the actual implementation
       Defines how authentication and keying occurs

IKEv1 vs IKEv2 Negotiation:
-----------------------------------

->IKEv1 was the original implementation
->IKEv2 adds new improvements

Affects only control plane not dataplane


IPSEC Tunnel Negotiation with IKE:
===========================

Goal of IPSEC exchange is to establish SA's. It has 2 phases

->Phase 1:
Authenticates endpoints and build a secure tunnel for further negotiation and result is called ISAKMP SA

->Phase 2:
Establish the tunnel to protect actual data traffic and result is IPsec SA.

Negotiating the ISAKMP SA(Phase 1):
----------------------------------------------

*Authentication Method
       Pre Shared Key(PSK)/X.509 Certificates(PKI)
*Diffie-Hellman Group - To exchange crypto keys
       Result of DH is what 3DES,AES etc use as their symmetric keys
      1/2/5 ....
*Encryption Type
      DES/3 DES/AES
*HASH Algorithm
     MD5/SHA1

-> Combination of above parameters are ISKAMP policy
   & IKE initiator send all its policies through proposal
   & IKE responder checks received policies against its own.
   & First match is used.

After phase 1 completes, an encrypted tunnel exists between the peers.
   *Phase 2 negotiation can now be hidden from devices in transit.

Negotiating IPsec SA (Phase 2):
--------------------------------------

Phase 2 parameters:

*Security Protocol (ESP/AH)
*Encapsulation Mode (Tunnel/Transport)
* Encryption (DES/3 DES/AES)
*Authentication(MD5/SHA/SHA-256)

Combination of all the above is called IPsec transform set

->AH vs ESP

& AH supports only authentication
& ESP supports both Authentication and Encryption

->Tunnel vs Transport

& Transport:
      * Original IP Header retained
& Tunnel
      * Adds new Header

AH With transport mode:
----------------------------

https://tools.ietf.org/html/rfc4302#section-3.1

Section 3.1.1

In transport mode, AH is inserted after the IP header and before a
   next layer protocol (e.g., TCP, UDP, ICMP, etc.) or before any other
   IPsec headers that have already been inserted.  In the context of
   IPv4, this calls for placing AH after the IP header (and any options
   that it contains), but before the next layer protocol.  (Note that
   the term "transport" mode should not be misconstrued as restricting
   its use to TCP and UDP.)  The following diagram illustrates AH
   transport mode positioning for a typical IPv4 packet, on a "before
   and after" basis.

                   BEFORE APPLYING AH
             ----------------------------
       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

                   AFTER APPLYING AH
             -------------------------------------------------------
       IPv4  |original IP hdr (any options) | AH | TCP |    Data   |
             -------------------------------------------------------
             |<- mutable field processing ->|<- immutable fields ->|
             |<----- authenticated except for mutable fields ----->|

ESP and AH headers can be combined in a variety of modes.  The IPsec
   Architecture document describes the combinations of security
   associations that must be supported.

AH With Tunnel Mode:

----------------------------

In tunnel mode, the "inner" IP header carries the ultimate (IP)
   source and destination addresses, while an "outer" IP header contains
   the addresses of the IPsec "peers," e.g., addresses of security
   gateways.  Mixed inner and outer IP versions are allowed, i.e., IPv6
   over IPv4 and IPv4 over IPv6.  In tunnel mode, AH protects the entire
   inner IP packet, including the entire inner IP header.  The position
   of AH in tunnel mode, relative to the outer IP header, is the same as
   for AH in transport mode.  The following diagram illustrates AH
   tunnel mode positioning for typical IPv4 and IPv6 packets.

        ----------------------------------------------------------------
   IPv4 |                              |    | orig IP hdr*  |   |      |
        |new IP header * (any options) | AH | (any options) |TCP| Data |
        ----------------------------------------------------------------
        |<- mutable field processing ->|<------ immutable fields ----->|
        |<- authenticated except for mutable fields in the new IP hdr->|

        --------------------------------------------------------------
   IPv6 |           | ext hdrs*|    |            | ext hdrs*|   |    |
        |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
        --------------------------------------------------------------
        |<--- mutable field -->|<--------- immutable fields -------->|
        |       processing     |
        |<-- authenticated except for mutable fields in new IP hdr ->|

          * = if present, construction of outer IP hdr/extensions and
              modification of inner IP hdr/extensions is discussed in
              the Security Architecture document.

ESP With Transport Mode:
--------------------------------

https://www.ietf.org/rfc/rfc4303.txt

In transport mode, ESP is inserted after the IP header and before a
   next layer protocol, e.g., TCP, UDP, ICMP, etc.  In the context of
   IPv4, this translates to placing ESP after the IP header (and any
   options that it contains), but before the next layer protocol.  (If
   AH is also applied to a packet, it is applied to the ESP header,
   Payload, ESP trailer, and ICV, if present.)  (Note that the term
   "transport" mode should not be misconstrued as restricting its use to
   TCP and UDP.)  The following diagram illustrates ESP transport mode
   positioning for a typical IPv4 packet, on a "before and after" basis.
   (This and subsequent diagrams in this section show the ICV field, the
   presence of which is a function of the security services and the
   algorithm/mode selected.)

                  BEFORE APPLYING ESP
             ----------------------------

       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

                  AFTER APPLYING ESP
             -------------------------------------------------
       IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
             |(any options)| Hdr | TCP | Data | Trailer | ICV|
             -------------------------------------------------
                                 |<---- encryption ---->|
                           |<-------- integrity ------->|

ESP With Tunnel Mode:
----------------------------

In tunnel mode, the "inner" IP header carries the ultimate (IP)
   source and destination addresses, while an "outer" IP header contains
   the addresses of the IPsec "peers", e.g., addresses of security
   gateways.  Mixed inner and outer IP versions are allowed, i.e., IPv6
   over IPv4 and IPv4 over IPv6.  In tunnel mode, ESP protects the
   entire inner IP packet, including the entire inner IP header.  The
   position of ESP in tunnel mode, relative to the outer IP header, is
   the same as for ESP in transport mode.  The following diagram
   illustrates ESP tunnel mode positioning for typical IPv4 and IPv6
   packets.

                 BEFORE APPLYING ESP
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------

                 AFTER APPLYING ESP

            -----------------------------------------------------------
      IPv4  | new IP hdr* |     | orig IP hdr*  |   |    | ESP   | ESP|
            |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
            -----------------------------------------------------------
                                |<--------- encryption --------->|
                          |<------------- integrity ------------>|


                      BEFORE APPLYING ESP
            ---------------------------------------
      IPv6  |             | ext hdrs |     |      |
            | orig IP hdr |if present| TCP | Data |
            ---------------------------------------

                     AFTER APPLYING ESP

            ------------------------------------------------------------
      IPv6  | new* |new ext |   | orig*|orig ext |   |    | ESP   | ESP|
            |IP hdr| hdrs*  |ESP|IP hdr| hdrs *  |TCP|Data|Trailer| ICV|
            ------------------------------------------------------------
                                |<--------- encryption ---------->|
                            |<------------ integrity ------------>|

            * = if present, construction of outer IP hdr/extensions and
                modification of inner IP hdr/extensions is discussed in
                the Security Architecture document.

IPSEC Control Plane vs Data Plane:
------------------------------------

IPSEC control plane (phase 1) - UDP 500, UDP 4500 for NAT
IPSEC data plabe (phase 2) - ESP(50) or AH(51), ESP over UDP 4500 if NAT

MST

Why MST?

1 vlan = 1 spanning tree
so if we have 1000 vlans we need 1000 spanning trees which will load CPU

Alternate 802.1Q: All Vlans on 1 spanning tree but no load balancing.

MST:
====

Flexible load-balancing
Need to handle few spanning tree instances

Instance:
---------

-> Vlans are placed into groups and the groups are called instances.

Region:
---------

Group of switches running same mst configuration.

Switch(config)#spanning-tree mode mst
Switch(config)#spanning-tree mst configuration
Switch(config-mst)#name cisco

By default Once mst region creates Instance-0(IST - Internal Spanning Tree) and all vlans are in this instance.

Switch# show spanning-tree mst configuration
Name    []
Revision 0
Instance     Vlans Mapped
----------     ------------------------------------------------
0                 1-4094(IST)
--------------------------------------------------------------

As you create additional instances (and place VLANS into these new instanes), the different bridges need to have a consistent vlan to "instance" mapping

An MST region is a group of switches having the same configuration

MST Region Configuration:(Must be same on all switches)

       -Name(32 bytes)
       -Revision Number(16 bits)
       -Vlan to Instance Table

Instances created manually are called Multiple Spanning Tree Instances(MSTIs).

Upto 65 instances can be created

=> MST ALWAYS SENDS ONLY ONE BPDU WHICH CONTAINS OF THE FOLLOWING DETAILS

->Region Information
         Region Name
         Revision Number
->A Configuration Digest of all VLANS and instances
         
   (Instance - Vlan Information) + Formula = Configration Digest

->One or more MRecords for each MSTI
         -All STP Parameters for the instance like Root BID, Sending BID, Root cost etc
         -MSTIs are RSTP instances that only exist inside the region
         -They don't directly interact with outside of the region.
         -Only one instance has timer related parameters(IST instance)
         -One MST BPDU per interface based on the vlans configured for that interface.

RSTP

RSTP Topology Change:
==================

->TC when non-edge port goes forward only

-> Broadcasted on the network by initiator(not by root as in 802.1d)
                  Sent on Root and non-edge Designated ports

-> Flush most of the cam entries in the network immediately except for edge ports.

-> MAC entries  learned from the port where the Topology change is forwarded are flushed out.

-> Do Not clear entries for ports that received the TC BPDU

RSTP Convergence Process:
====================

Switch x(Root)------- a(Switch A)

Handshake:

Below mechanism for Point-to-Point Full duplex links.

1) Switch Root sends proposal bit set.(3 proposals before moving the port to blocking)
2) On Switch A "a" becomes root port goes into forwarding and send back a BPDU with agreement bit set
3) As soon as x receives the agreement it goes to Forwarding.

If they are connected to HUB then same process as 802.1d


Propagating the Handshake:
----------------------------------

Switch X ----- Switch A

1)  X is the root.

So when a new switch B with lower priority is connected to the switch A

Switch X ----- Switch A ----- NEW(Switch B)

2) Switch B sends proposal to Switch A proposing it as a new root.
3) Switch A realises the B priority is better than X and does 3 things simultaneously after receiving proposal from B.

             a) Block the port connecting to X.
             b) Forward the proposal to X
             c) Send back agreement to B

4) Once X sends back the agreement to A the port a will be moved to forwarding again.


http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html

QOS - Tools and Challenges

QOS TOOLS:
==========
==========

1) Classifiers and Classes of Service :
===========================

 A classifi er has one input, the incoming packet, and it has N possible outputs, where

N is the number of possible classes of service into which the packet can be classified

2) Metering and Coloring – CIR / PIR Model:

================================

 The metering tool provides this second level of granularity. It measures the traffi  c

arrival rate and assigns colors to traffi  c according to that rate.

 So looking at the classifi  er and metering tools together, the classifi  er assigns traffi  c to

classes of service, which each have assigned resources, and the metering tool allows traffi  c

inside a single class of service to be differentiated according to its arrival rate.

3) The Policer Tool:

==============

 The policer tool is responsible for ensuring that traffi  c conforms to a defi  ned rate called

the bandwidth limit  . The output of the policer tool is the traffi  c that was present at input,

but that has been limited based on the bandwidth - limit parameter, with excess traffi  c being

discarded,

 The metering tool is commonly coupled with the policer as a way to increase the policer

’  s granularity. In this scenario, the metering tool measures the traffi  c arrival rate and splits

the traffi  c into the three - color scheme previously presented. The policer is responsible for

applying actions to the traffi  c according to its color

4)The Shaper Function:

=================

 The shaper function causes a traffi  c fl  ow to conform to a bandwidth value referred to as

the shaping rate  . Excess traffi  c beyond the shaping rate is stored inside the shaper and

transmitted only when doing so does not violate the defi  ned shaping rate

5) Comparing Policing and Shaping:

==========================

 The difference between the policed and the shaped fl  ows is visible by comparing the

two graphs. The main difference is how each tool deal with excess traffi  c. The policer discards it, while the shaper stores it, to be transmitted later, whenever doing so does not

violate the defi  ned shaping rate

6) Queue:

=======

 A queue contains two sub - blocks: a buffer and a dropper. The buffer is where packets

are stored while awaiting transmission.

 The decision whether a packet should be placed in the queue buffer or dropped is taken

by the other queue block, the dropper. The dropper has one input, which is the queue fi  ll

level. Its output is a decision either to place the packet in the queue or to drop it.

 When a packet enters a queue, it fi  rst crosses the dropper block, which, based on the

queue fi  ll level, makes a decision regarding whether the packet should be placed in the

FIFO buffer or discarded. If the packet is placed in the buffer, it stays there until it is

transmitted. The action of moving a packet out of the queue is the responsibility of the

next QOS tool we discuss, the scheduler

7) The Scheduler:

==============

The scheduler implements a multiplexing operation, placing N inputs into a single output.

The inputs are the queues containing packets to be serviced, and the output is a single

packet at a time leaving the scheduler. The scheduler services a queue by removing

packets from it.

8) The Rewrite Tool:

===============

The rewrite tool allows a packet ’ s internal QOS marking (simply called its marking), to

be changed.

CHALLENGES:

============

============

1. Defining the Classes of Service:

========================

The main foundation of the entire QOS concept is applying different behavior to different

traffi c types. Achieving traffi c differentiation is mandatory, because it is only by splitting

traffi c into different classes of service that different behavior can be selectively applied

to each.

2) Classes of Service and Queues Mapping:

===============================

 the combination of the queuing and scheduling tools directs traffi c from several queues into a single output, and the queue properties, allied with the scheduling rules, dictate specifi  c behavior regarding delay, jitter, and packet loss,

3) Inherent Delay Factors:

==================

When traffi c crosses a network from source to destination, the total amount of delay

inserted at each hop can be categorized in smaller factors that contribute to the overall

delay value.

There are two groups of contributors to delay. The fi rst group encompasses the QOS

tools that insert delay due to their inherent operation, and the second group inserts delay

as a result of the transmission of packets between routers. While the second group is not

directly linked to the QOS realm, it still needs to be accounted for.

4) Congestion Points:

================

 Congestion points in the network exist when there is a resource shortage, and the

importance of QOS within a network increases as the available network resources shrink.

5) Trust Borders:

==========

When traffi c arrives at a router, in terms of QOS, the router can trust it or not. The term

trust can be seen from two different perspectives. The fi rst is whether the information

present in the packets is valid input for the classifi er deciding the class of service to which

the packets belong. The concern is assuring that the classifi er is not fooled by any misinformation

present in the packets, which could lead to traffi c being placed in an incorrect

class of service.

6) Granularity Levels:

================

Routers inside a network fall into two main groups: routers that are placed at the edge of

the network, commonly named PE ( provider edge ), and core routers, commonly named

P (provider). From a QOS perspective, the key differentiation factor between PE and P

routers is not their position in the network topology but the types of interfaces they have.

A PE router has two types of interfaces, customer and core facing, while P routers only

have the second type.

7) Control Traffic:

=============

There are two major differences between control and customer traffi c. The fi rst is that

control traffi c results from the network operation and protocol signaling, and provides the

baseline for the connectivity between service end points on top of which customer traffi c

rides. In other words, control traffi c is what keeps the network alive and breathing. The

second difference is that the source of control traffi c is internal. It is generated inside the

network, while the customer traffi c that transits the network between the service end

points comes from outside the network.


Calculating Bc, Tc, CIR for shaping and Policing:
===================================

Tc = Bc/CIR (in seconds) is the formula.

The router internally calculates the value of Tc based on the configured CIR and Bc values.

If Bc/CIR is more than or equal to 125 ms, it uses an internal Tc value if the router determines that traffic flow will be more stable with a smaller interval.
You can use the show traffic-shape command to determine whether your router is using an internal value for Tc or the value that you configured.

In your example with CIR of 64K and Bc of 8000K, (8,000/64,000) = 0.125 or 125ms.    If we wanted a Tc of 100ms, we would simply configure the Bc to be 6400.  Then  using the formula Tc=Bc/CIR it would be 6,400/64,000 = .1  or 100ms. 

Optional Spanning Tree Features

PortFast:

Enabled only on edge ports and once it is enabled and if the port receives an electric signal immediately transitions to Forwarding state.

BPDUGuard:

If enabled along with Portfast and if the port receives BPDU port will be moved to err-disabled state.

Uplink Fast:

In this section, refer to the previous diagram, which uses a minimal backbone. The behavior of the STP is inspected in the event of uplink failure. Each step is followed with a diagram.

D1 and D2 are core switches. D1 is configured as the root bridge of the network. A is an access switch with one of its uplinks in blocking mode

1. Assume that the primary uplink from A to D1 fails.
   
2. Port P1 goes down immediately and switch A declares its uplink to D1 as down.
   Switch A considers its link to D2, which still receives BPDUs from the root, as an alternate root port. Bridge A can start to transition port P2 from the blocking state to the forwarding state. In order to achieve this, it has to go through the listening and learning stages. Each of these stages last forward_delay (15 seconds by default), and holds port P2 blocking for 30 seconds.
3. Once port P2 reaches the forwarding state, the network connectivity is re-established for hosts attached to switch A.
   The network outage lasted 30 seconds.
   
   The minimum value allowed for the forward_delay timer is seven seconds. Tuning the STP parameters can lead to a recovery time of 14 seconds. This is still a noticeable delay for a user, and this kind of tuning should be done with caution. This section of this document shows how UplinkFast dramatically reduces the downtime.

Backbone Fast:

This scenario is based on the first example, but, this time with backbone fast enabled on the three switches.

1. If link L1 goes down, switch B immediately detects the failure and assumes it is the root. It starts to send BPDUs to S and claims to be the new root.
2. As soon as S receives the inferior BPDU from B, it starts to reconfirm its non-designated ports instead of waiting max_age. It sends a RLQ query on its root port for root bridge R.
3. Root bridge R receives the query and immediately answers with a RLQ response that specifies there is still a root R in that direction.
4. S has now checked all its non-designated ports, and it still has connectivity to the root. It can then age out immediately the information stored on port P. P transitions to listening and starts to send BPDUs. At that stage, you have already saved max_age seconds, and the standard Spanning-Tree Algorithm (STA) applies then.
5. B receives the better BPDU from S (R better root than B) and considers now the ports that lead to L3 as its root port.

Root Guard:

The Root Guard feature can be enabled on all switch ports in the network off of which the root bridge should not appear (that is, every port that is not a root port , the port on each switch that is considered to be closest to the root

bridge). If a port configured for Root Guard receives a superior BPDU, instead of believing the BPDU, the port goes into a root-inconsistent state. While a port is in the root-inconsistent state, no user data is sent across it. However, after the superior BPDUs stop, the port returns to the forwarding state.