PORT COST vs PORT PRIORITY

Both parameters are used to determine which interface will be in forwarding state.

They have differences though:

•  If you want to affect how to the local switch elects the root port change the cost on the links.  Cost is cumulative throughout the STP domain. The higher cost is the less preferred.
•  If you want to affect how downstream switch elects its root port change the priority. This is only local significant between the two directly connected switches. Highest priority is less preferred.

 Going away from the root of the tree use priority whereas, when going towards the root of the tree use cost.

Reff: https://supportforums.cisco.com/thread/16435

SPANNING TREE:
to check total path cost/priority between current designated bridge to root bridge:
show spann root [cost/priority]

To change root port(towards root bridge) use spanning-tree cost on desired port.
To change the root port on below directly connected designated bridge(which is away from root bridge), use spanning-tree priority on desired port which is place on present switch.
note: if u r confused about toward/away root bridge, avoid rackets in above and read again, then read below
 Ex:

• If A is root bridge, C is designated bridge reach the root bridge A via designated bridge B. 
• Now we want to change the root port on B, use spanning-tree cost command on B. 
• Like this u change the root port on C using cost command on C. 
• Spanning-tree Priority command case is different, if we want to change the root port on C, but not use on C instead used on B.

BPDU FILTER:

• config at interface level or globally
• both have same effect disable STP on per interface basis
• this can stop STP information at incoming/outgoing interface
• Used at access layer at which end host are users
• this block the stp information reaching the end hosts
• if know (root bridge, mac add, priority), there is possibility malfunction of STP
• 
  

TS INE V1:1.1

sh cdp neighbor
sh int status
sh vlan br
ping
--------------------------
PROBLEMS FACED:
1) In the output of sh cdp ne cmd some devices are missing based on L2 diag.
- Because, directly connected interfaces were shutdown.
- based on the L2-diag we know the directly connected devices.
- After using no shutdown on  connected interfaces  then only directly connected devices appear in sh cdp neigh cmd.
2) un successful of ping cmd
- some times interfaces were shutdown
- some times switches between source & destination have

• required vlans are not created
• in between source to destination every switch must contain corresponding vlan
• check the required vlans & corresponding interfaces by using sh vlan br
• then create vlans according l3-diag
• create vlan around switches from diagrom
• Some interfaces of switches are connected routers but not showed in L3-dag
• easily identified by a straight line connected to 2 or more devices
• some times simply a straight line
• That inter faces are connected to switches

QUEUING:

• FIFIO QUEUING
• Simple and easiest to implement
• Only one parameter used is queue-depth
• Other queuing methods change the order of packets
• We cannot modify the tx-ring, only modify the output queue
• Tx-ring is controlled by clocking & serialization of line
• Controlled by how large the buffer as waiting to send traffic to tx-ring
• To config fifo disable previous queueing mechanisms
• At txr serialization of packet ocuurs
• After filling the output queue, if packets are arrived at tail of queue will be tail dropped
• TCP window: A TCP window is the amount of unacknowledged data a sender can send on a particular connection before it gets an acknowledgment back from the receiver, that it has received some of the data.
• Tcp sliding window:
• The sending device can send all packets within the TCP window size
• (as specified in the TCP header) without receiving an ACK,
• and should start a timeout timer for each of them.
• After receiving the ACK from the receiving device, the sending device slides the window.
• In this case, the sending device can send up to 5 TCP Segments without receiving an acknowledgement from the receiving device.
• After receiving the acknowledgement for Segment 1 from the receiving device, the sending device can slide its window one TCP Segment to the right side and the sending device can transmit segment 6 also.
• If any TCP Segment lost whiles its journey to the destination, the receiving device cannot acknowledge the sender.
• Consider while transmission, all other Segments reached the destination except Segment 3.
• The receiving device can acknowledge up to Segment 2.
• At the sending device, a timeout will occur and it will re-transmit the lost Segment 3.
• Now the receiving device has received all the Segments, since only Segment 3 was lost.
• Now the receiving device will send the ACK for Segment 5, because it has received all the Segments to Segment 5.
• Acknowledgement for Segment 5 ensures the sender the receiver has succesfully received all the Segments up to 5.
• defaultly faire queue is there, based on the weight of packet, packet will be switched
• before configuring fifo remove defaultly enabled fair queue
• hold-queue : no.of packets in fit in software queue
• serialization of pakcet: put the packets into the wires/optical interface , it will be done at TxRing

TRAFFIC SHAPING

• Design to slow the output breakdown from output queue to tx-ring
• Goal
• Smooth out or normalize traffic weight when we are sending packets out the interface
• Delay & queue the packets when exceeding traffic
• Shaping will require only when
• Physical serialization rate of link which is based on the physical clocking of interfaces hardware.
• Where serialization rate of out bound is not matching with policed inbound
• Generally based on policed inbound traffic will be shaped at outbound
• Exceed traffic at outbound will be delayed in shaping queue.
• IOS traffic shaping
• Delays the exceeding traffic ony
• Sometimes If queue is large traffic will be dropped when exceeding the rate

RSVP

RSVP


Resource reservation protocol


For intserv models


Both source and destination support RSVP


RSVP intserv flow reservations


Path messages flow downstream from source(can u support this specific reservation)


RESV messages flow upstreram from destination if aggrees


Reservation contains


Flow spec


Tspec (traffic spec, token bucket parameters: rate/burs)


Rspec (reservation spec, type of services)


Filter Spec: flwo sources to reserve recsource for


RSVP REQUIRES CBWFQ OR WFQ


Because RSVP flow can get separate weight


Configuration command


Based on interface bandwidth and Tspec configure on interface


Ip rsvp bandwidth { I am available to receive reservation on my interface)


Doesnot work with HQF


Should be WFQ of CBWFQ with WFQ in class-default


Only used for mpls traffic engineering for bandwidth asking


RSVP works with Per-VC queue


Require legacy FRTS


PVC Queue must be WFQ/CBWFQ


Ip rsvp resource-provider


Configuration


Sender


Ip rsvp sender-host


Receiver


Ip rsvp reservation-host


Transit notdes


Ip rsvp bandwidth