Some thoughts on ACLs, as well as some commands to review:
distribute-list <#> [ in | out] - permit or deny routing protocols from adding a network into the routes propagated
Standard ACLs: 1-99, 1300-1999
Extended ACLs: 100-199, 2000-2699
A Cisco router removes the host inverse mask (0.0.0.0) from an ACL when doing a show running-config, because anything without a mask is assumed to be a host.
Apply standard ACLs on the interface closest to the destination.
An empty ACL allows all traffic.
When working on a router or firewall remotely, start with the reload in command to reload the device autmatically in case an error is made and everyone is locked out. Then cancel the reload to remove the reload command before the timer is up if everything is working correctly:
reload in 5
reload cancel
When configuring extended ACLs, be cautious about the source port and its placement. Entering port numbers after the source IP, you only filter that source port. Leaving source port information off the ACL means to assume all source ports
Best practice is to apply extended ACLs on the interface closest to the source. This is directly contrary to the best practice for standard ACLs.
(Standard near destination, Extended near source)
Use the established keyword to allow any packets with an ACK or RST through. This is commonly applied on the Internet interface inbound to allow any sessions initiated from the LAN back through the router.
A named ACL can have a single line deleted without removing the entire ACL. One major difference is that the named list must be prepended with the ip keyword.
A Cisco router creates entries in a named ACL starting at line number 10 and incrementing by 10.
resequence allows you to move an ACL line from one number to another.
More thoughts as they come to me...
Working my way toward being a Full Stack Engineer. I work for a state University leading the Systems Team, looking to chart a future of the data center and how it looks to build into the cloud in a responsible and innovative manner. This blog is largely a place to stash things I pick up in daily work life and pursuit of knowledge.
Thursday, July 18, 2013
Show commands for ACLs
Some "show" commands for quick reference:
show ip interface - IP settings, ACLs applied, NAT configuration
show int - Interface config, stats, encapsulation, errors at L2
show access-lists, show ip access-lists - simply list ACLs, these are the same
show ip interface - IP settings, ACLs applied, NAT configuration
show int - Interface config, stats, encapsulation, errors at L2
show access-lists, show ip access-lists - simply list ACLs, these are the same
Wednesday, July 17, 2013
Static NAT Cheat-sheet
Static NAT - Port Translation
1) Define inside NAT interface
2) Define outside NAT interface
3) Define NAT using static keyword and assign port only
Example:
R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int ser 0/0
R2(config-if)#ip nat outside
R2(config-if)#int fa 0/0
R2(config-if)#ip nat inside
R2(config)#ip nat inside source static tcp 10.2.1.10 80 192.168.2.2 80
Verify:
R2#sho ip nat trans
Pro Inside global Inside local Outside local Outside global
tcp 192.168.2.2:80 10.2.1.10:80 --- ---
R2#debug ip nat
IP NAT debugging is on
*Mar 1 00:39:46.131: ipnat_add_static_cfg: id 3, flag 6
*Mar 1 00:39:46.135: id 3, flags 0, domain 0, lookup 0, from_addr A02010A, from_mask FFFFFFFF, from_port 50, to_addr C0A80202, to_port 50 to_mask FFFFFFFF, proto 6
*Mar 1 00:40:20.575: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39818]
*Mar 1 00:40:20.623: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [0]
*Mar 1 00:40:20.627: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39819]
*Mar 1 00:40:20.627: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39820]
*Mar 1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20303]
*Mar 1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20304]
*Mar 1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20305]
*Mar 1 00:40:20.655: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39821]
*Mar 1 00:40:20.691: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20306]
*Mar 1 00:40:20.691: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20307]
*Mar 1 00:40:20.691: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39822]
*Mar 1 00:40:20.691: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13399]
*Mar 1 00:40:20.703: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39823]
*Mar 1 00:40:20.723: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [0]
*Mar 1 00:40:20.723: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39824]
*Mar 1 00:40:20.735: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13400]
*Mar 1 00:40:20.735: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13401]
*Mar 1 00:40:20.743: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20308]
*Mar 1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50985]
*Mar 1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50986]
*Mar 1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50987]
*Mar 1 00:40:20.771: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13402]
*Mar 1 00:40:20.791: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50988]
*Mar 1 00:40:20.791: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50989]
*Mar 1 00:40:20.791: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13403]
*Mar 1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50990]
*Mar 1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50991]
*Mar 1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50992]
*Mar 1 00:40:20.803: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13404]
*Mar 1 00:40:20.815: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13405]
*Mar 1 00:40:20.823: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13406]
*Mar 1 00:40:20.835: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13407]
*Mar 1 00:40:20.843: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13408]
*Mar 1 00:40:20.851: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50993]
exit
R2#no debug all
All possible debugging has been turned off
R2#
1) Define inside NAT interface
2) Define outside NAT interface
3) Define NAT using static keyword and assign port only
Example:
R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int ser 0/0
R2(config-if)#ip nat outside
R2(config-if)#int fa 0/0
R2(config-if)#ip nat inside
R2(config)#ip nat inside source static tcp 10.2.1.10 80 192.168.2.2 80
Verify:
R2#sho ip nat trans
Pro Inside global Inside local Outside local Outside global
tcp 192.168.2.2:80 10.2.1.10:80 --- ---
R2#debug ip nat
IP NAT debugging is on
*Mar 1 00:39:46.131: ipnat_add_static_cfg: id 3, flag 6
*Mar 1 00:39:46.135: id 3, flags 0, domain 0, lookup 0, from_addr A02010A, from_mask FFFFFFFF, from_port 50, to_addr C0A80202, to_port 50 to_mask FFFFFFFF, proto 6
*Mar 1 00:40:20.575: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39818]
*Mar 1 00:40:20.623: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [0]
*Mar 1 00:40:20.627: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39819]
*Mar 1 00:40:20.627: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39820]
*Mar 1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20303]
*Mar 1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20304]
*Mar 1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20305]
*Mar 1 00:40:20.655: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39821]
*Mar 1 00:40:20.691: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20306]
*Mar 1 00:40:20.691: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20307]
*Mar 1 00:40:20.691: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39822]
*Mar 1 00:40:20.691: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13399]
*Mar 1 00:40:20.703: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39823]
*Mar 1 00:40:20.723: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [0]
*Mar 1 00:40:20.723: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39824]
*Mar 1 00:40:20.735: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13400]
*Mar 1 00:40:20.735: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13401]
*Mar 1 00:40:20.743: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20308]
*Mar 1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50985]
*Mar 1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50986]
*Mar 1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50987]
*Mar 1 00:40:20.771: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13402]
*Mar 1 00:40:20.791: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50988]
*Mar 1 00:40:20.791: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50989]
*Mar 1 00:40:20.791: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13403]
*Mar 1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50990]
*Mar 1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50991]
*Mar 1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50992]
*Mar 1 00:40:20.803: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13404]
*Mar 1 00:40:20.815: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13405]
*Mar 1 00:40:20.823: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13406]
*Mar 1 00:40:20.835: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13407]
*Mar 1 00:40:20.843: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13408]
*Mar 1 00:40:20.851: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50993]
exit
R2#no debug all
All possible debugging has been turned off
R2#
Dynamic NAT cheat-sheet
Dynamic NAT - translate one subnet to a pool of addresses, often used when combining two networks with overlapping subnets.
1) Define inside NAT interface
2) Define outside NAT interface
3) Create pool of addresses to use for NAT
4) Create standard ACL for inside subnet
5) NAT statement using ACL and pool as source and destination
Example:
R1(config)#int fa 0/0
R1(config-if)#ip nat inside
R1(config-if)#int ser 0/1
R1(config-if)#ip nat outside
R1(config-if)#exit
R1(config)#ip nat pool POOL2 192.168.2.200 192.168.2.225 prefix-length 24
R1(config)#access-list 1 permit 10.1.1.0 0.0.0.255
R1(config)#ip nat inside source list 1 pool POOL2
R1(config)#end
Verify:
R1#debug ip nat
IP NAT debugging is on
R1#
*Mar 1 00:16:55.147: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar 1 00:16:55.163: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar 1 00:16:55.647: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52471]
*Mar 1 00:16:55.667: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52471]
*Mar 1 00:16:56.155: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar 1 00:16:56.167: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar 1 00:16:56.655: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52472]
*Mar 1 00:16:56.679: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52472]
*Mar 1 00:16:57.131: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar 1 00:16:57.159: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar 1 00:16:57.699: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52473]
*Mar 1 00:16:57.699: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52473]
sho ip nat trans
Pro Inside global Inside local Outside local Outside global
icmp 192.168.2.200:6659 10.1.1.10:6659 192.168.2.2:6659 192.168.2.2:6659
--- 192.168.2.200 10.1.1.10 --- ---
icmp 192.168.2.201:63436 10.1.1.100:63436 192.168.2.2:63436 192.168.2.2:63436
icmp 192.168.2.201:63692 10.1.1.100:63692 192.168.2.2:63692 192.168.2.2:63692
icmp 192.168.2.201:63948 10.1.1.100:63948 192.168.2.2:63948 192.168.2.2:63948
icmp 192.168.2.201:64204 10.1.1.100:64204 192.168.2.2:64204 192.168.2.2:64204
icmp 192.168.2.201:64460 10.1.1.100:64460 192.168.2.2:64460 192.168.2.2:64460
--- 192.168.2.201 10.1.1.100 --- ---
1) Define inside NAT interface
2) Define outside NAT interface
3) Create pool of addresses to use for NAT
4) Create standard ACL for inside subnet
5) NAT statement using ACL and pool as source and destination
Example:
R1(config)#int fa 0/0
R1(config-if)#ip nat inside
R1(config-if)#int ser 0/1
R1(config-if)#ip nat outside
R1(config-if)#exit
R1(config)#ip nat pool POOL2 192.168.2.200 192.168.2.225 prefix-length 24
R1(config)#access-list 1 permit 10.1.1.0 0.0.0.255
R1(config)#ip nat inside source list 1 pool POOL2
R1(config)#end
Verify:
R1#debug ip nat
IP NAT debugging is on
R1#
*Mar 1 00:16:55.147: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar 1 00:16:55.163: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar 1 00:16:55.647: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52471]
*Mar 1 00:16:55.667: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52471]
*Mar 1 00:16:56.155: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar 1 00:16:56.167: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar 1 00:16:56.655: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52472]
*Mar 1 00:16:56.679: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52472]
*Mar 1 00:16:57.131: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar 1 00:16:57.159: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar 1 00:16:57.699: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52473]
*Mar 1 00:16:57.699: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52473]
sho ip nat trans
Pro Inside global Inside local Outside local Outside global
icmp 192.168.2.200:6659 10.1.1.10:6659 192.168.2.2:6659 192.168.2.2:6659
--- 192.168.2.200 10.1.1.10 --- ---
icmp 192.168.2.201:63436 10.1.1.100:63436 192.168.2.2:63436 192.168.2.2:63436
icmp 192.168.2.201:63692 10.1.1.100:63692 192.168.2.2:63692 192.168.2.2:63692
icmp 192.168.2.201:63948 10.1.1.100:63948 192.168.2.2:63948 192.168.2.2:63948
icmp 192.168.2.201:64204 10.1.1.100:64204 192.168.2.2:64204 192.168.2.2:64204
icmp 192.168.2.201:64460 10.1.1.100:64460 192.168.2.2:64460 192.168.2.2:64460
--- 192.168.2.201 10.1.1.100 --- ---
NAT Overload cheat-sheet
NAT Overload:
1) Define inside NAT interface
2) Define outside NAT interface
3) Create standard ACL to permit inside (LAN) subnet
4) NAT statement with overload keyword
Example:
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int ser 0/1
R1(config-if)#ip nat outside
R1(config-if)#int f
*Mar 1 00:02:51.727: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to upa 0/0
R1(config-if)#ip nat inside
R1(config-if)#exit
R1(config)#ip access
R1(config)#ip access-list standard INSIDE_VLAN1
R1(config-std-nacl)#permit 10.1.1.0 0.0.0.255
R1(config-std-nacl)#exit
R1(config)#ip nat inside source list INSIDE_VLAN1 int ser 0/1 overload
Verify:
R1#debug ip nat
IP NAT debugging is on
R1#
*Mar 1 00:05:47.823: NAT*: s=10.1.1.10->192.168.2.1, d=192.168.2.2 [0]
*Mar 1 00:05:47.835: NAT*: s=192.168.2.2, d=192.168.2.1->10.1.1.10 [0]
*Mar 1 00:05:48.807: NAT*: s=10.1.1.10->192.168.2.1, d=192.168.2.2 [0]
*Mar 1 00:05:48.819: NAT*: s=192.168.2.2, d=192.168.2.1->10.1.1.10 [0]
1) Define inside NAT interface
2) Define outside NAT interface
3) Create standard ACL to permit inside (LAN) subnet
4) NAT statement with overload keyword
Example:
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int ser 0/1
R1(config-if)#ip nat outside
R1(config-if)#int f
*Mar 1 00:02:51.727: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to upa 0/0
R1(config-if)#ip nat inside
R1(config-if)#exit
R1(config)#ip access
R1(config)#ip access-list standard INSIDE_VLAN1
R1(config-std-nacl)#permit 10.1.1.0 0.0.0.255
R1(config-std-nacl)#exit
R1(config)#ip nat inside source list INSIDE_VLAN1 int ser 0/1 overload
Verify:
R1#debug ip nat
IP NAT debugging is on
R1#
*Mar 1 00:05:47.823: NAT*: s=10.1.1.10->192.168.2.1, d=192.168.2.2 [0]
*Mar 1 00:05:47.835: NAT*: s=192.168.2.2, d=192.168.2.1->10.1.1.10 [0]
*Mar 1 00:05:48.807: NAT*: s=10.1.1.10->192.168.2.1, d=192.168.2.2 [0]
*Mar 1 00:05:48.819: NAT*: s=192.168.2.2, d=192.168.2.1->10.1.1.10 [0]
Monday, July 15, 2013
Multicast addresses
Because a quick reference is always good for review:
224.0.0.2 - all routers on this subnet
224.0.0.5 - OSPF all routers
224.0.0.6 - OSPF DR/BDR
224.0.0.9 - RIPv2 all routers
224.0.0.10 - EIGRP all routers
224.0.0.2 - all routers on this subnet
224.0.0.5 - OSPF all routers
224.0.0.6 - OSPF DR/BDR
224.0.0.9 - RIPv2 all routers
224.0.0.10 - EIGRP all routers
Friday, June 21, 2013
Spanning-tree Review
Spanning Tree was standardized in IEEE 802.1d as a layer-2 protocol designed to eliminate switching loops - or rather "bridging" loops since bridges were the prominent device at the time of adoption of the standard.
Root Bridge
The root bridge is the "master" bridge for maintaining all STP information within a network. When a switch boots up, it immediately believes it is the root bridge and broadcasts a Bridge Protocol Data Unit (or BPDU) to all other switches on the network, at which time an election takes place. The switch with the lowest bridge ID becomes the root.
The bridge ID is composed of two factors. First is the root priority, which is a number between 0 and 61440, randomly assignable in increments of 4096 on the switch. The default priority is 32768 (in hex, 8000), which all Cisco switches are initially configured with. The second component of the bridge ID is the MAC address. In the case of an election, the switch with the lowest root ID becomes the root. First the priority is considered, then the MAC.
It is therefor advisable to configure the priority on a robust core switch when working in a highly complex or robust network to ensure that the switch controlling the STP is capable to handle the workload as well as in a central location.
BPDUs are multicast every two seconds by the root bridge following the initial election. Contained in this packet is the bridge ID of the root bridge, and as long as that number is lower than the ID of the switch receiving the BPDU no election will be forced. If a BPDU arrives with a lower ID than is configured on the switch, an election takes place and the STP topology will reconverge.
Root ports
After election of a root bridge, each nonroot switch forms an association back to the root. The path with the lowest cumulative cost is placed into a forwarding state, and all other paths to the root are placed in a blocking state. This information is contained in the BPDU, along with the root bridge ID and the sending switch's bridge ID. The cost is the inverse of the bandwidth on the link between it and the root, so the lowest cost is the fastest path back to the root. Costs are:
10 Gb: Cost 2
1 Gb: Cost 4
100 Mb: Cost 19
10 Mb: Cost 100
Each switch that receives a BPDU from the root will have a cost of 0. It adds the cost of the interface on which it was received to that value and forwards that information to other switches with the new cost. Each switch in turn performs the same action to determine what is the most efficient path to the root.
When equal cost paths are available, the system determines which port becomes the root port by first looking at the bridge ID and will select the lowest ID as the root. If both links are to the same switch, it will use the lowest port priority, which is 128 by default but can be administratively set to chooose one link over another. If port priority is equal, the switch will choose the lowest port number to determine the root port.
Designated Ports
Designated ports connect to another switch and are a path back to the root bridge. They are the "input" to the "output" of the root port and are selected based on the same path cost criteria as the root port.
Blocked Ports
When there are two paths from a switch back to the root port, STP will block client traffic from leaving the port with the highest path cost back to the root. The port will still listen for BPDUs so that the switch can react to topology changes and notifications, but it simply doesn't send any data.
Port State Transitions
STP ports will go through a process of transitioning from a blocked state to a forwarding state. Those states are:
Blocking - no client data is sent, but still listens for BPDU
Listening - no client data sent, but listens for topolgy updates
Learning - no client data sent, but learning MAC addresses on connected ports
Forwarding - now passing data as well as listening for BPDUs
The timers associated with those states:
Blocking - 20 seconds (max age timeout, or 10 BPDUs missed)
Listening - 15 seconds
Learning - 15 seconds
When a link goes down, a topology change notification BPDU (TCN BPDU) is sent from the switch reporting a link failure. This is one of the only times a BPDU doesn't originate from the root bridge. The root will eventually receive the TCN and notify the switches in its topology to start aging out MAC addresses 8 times more quickly than its default of 300 seconds. The switches then begin rebuilding the topology by assigning ports to either designated, root or blocking states based on the updated condition of the network.
Because of these default timers, a network could take up to 50 seconds to converge and start sending data again. To modify the default timers, only the root bridge needs to be adjusted and the timer changes will propagate through the topology.
Root Bridge
The root bridge is the "master" bridge for maintaining all STP information within a network. When a switch boots up, it immediately believes it is the root bridge and broadcasts a Bridge Protocol Data Unit (or BPDU) to all other switches on the network, at which time an election takes place. The switch with the lowest bridge ID becomes the root.
The bridge ID is composed of two factors. First is the root priority, which is a number between 0 and 61440, randomly assignable in increments of 4096 on the switch. The default priority is 32768 (in hex, 8000), which all Cisco switches are initially configured with. The second component of the bridge ID is the MAC address. In the case of an election, the switch with the lowest root ID becomes the root. First the priority is considered, then the MAC.
It is therefor advisable to configure the priority on a robust core switch when working in a highly complex or robust network to ensure that the switch controlling the STP is capable to handle the workload as well as in a central location.
BPDUs are multicast every two seconds by the root bridge following the initial election. Contained in this packet is the bridge ID of the root bridge, and as long as that number is lower than the ID of the switch receiving the BPDU no election will be forced. If a BPDU arrives with a lower ID than is configured on the switch, an election takes place and the STP topology will reconverge.
Root ports
After election of a root bridge, each nonroot switch forms an association back to the root. The path with the lowest cumulative cost is placed into a forwarding state, and all other paths to the root are placed in a blocking state. This information is contained in the BPDU, along with the root bridge ID and the sending switch's bridge ID. The cost is the inverse of the bandwidth on the link between it and the root, so the lowest cost is the fastest path back to the root. Costs are:
10 Gb: Cost 2
1 Gb: Cost 4
100 Mb: Cost 19
10 Mb: Cost 100
Each switch that receives a BPDU from the root will have a cost of 0. It adds the cost of the interface on which it was received to that value and forwards that information to other switches with the new cost. Each switch in turn performs the same action to determine what is the most efficient path to the root.
When equal cost paths are available, the system determines which port becomes the root port by first looking at the bridge ID and will select the lowest ID as the root. If both links are to the same switch, it will use the lowest port priority, which is 128 by default but can be administratively set to chooose one link over another. If port priority is equal, the switch will choose the lowest port number to determine the root port.
Designated Ports
Designated ports connect to another switch and are a path back to the root bridge. They are the "input" to the "output" of the root port and are selected based on the same path cost criteria as the root port.
Blocked Ports
When there are two paths from a switch back to the root port, STP will block client traffic from leaving the port with the highest path cost back to the root. The port will still listen for BPDUs so that the switch can react to topology changes and notifications, but it simply doesn't send any data.
Port State Transitions
STP ports will go through a process of transitioning from a blocked state to a forwarding state. Those states are:
Blocking - no client data is sent, but still listens for BPDU
Listening - no client data sent, but listens for topolgy updates
Learning - no client data sent, but learning MAC addresses on connected ports
Forwarding - now passing data as well as listening for BPDUs
The timers associated with those states:
Blocking - 20 seconds (max age timeout, or 10 BPDUs missed)
Listening - 15 seconds
Learning - 15 seconds
When a link goes down, a topology change notification BPDU (TCN BPDU) is sent from the switch reporting a link failure. This is one of the only times a BPDU doesn't originate from the root bridge. The root will eventually receive the TCN and notify the switches in its topology to start aging out MAC addresses 8 times more quickly than its default of 300 seconds. The switches then begin rebuilding the topology by assigning ports to either designated, root or blocking states based on the updated condition of the network.
Because of these default timers, a network could take up to 50 seconds to converge and start sending data again. To modify the default timers, only the root bridge needs to be adjusted and the timer changes will propagate through the topology.
Subscribe to:
Posts (Atom)