- Specify the Host name.
Router(config)#hostname <host name> - Define a default domain name.
Router(config)#ip domain-name <Domain Name> - Generate RSA key pairs.
Router(config)#crypto key generate rsa - Configure SSH-RSA keys for user and server authentication.
Router(config)#ip ssh pubkey-chain - Configure the SSH username.
Router(conf-ssh-pubkey)#username <user name> - Specify the RSA public key of the remote peer.
Router(conf-ssh-pubkey-user)#key-string - Specify the SSH key type and version. (optional)
Router(conf-ssh-pubkey-data)#key-hash ssh-rsa <key ID> - Exit the current mode and return to privileged EXEC mode.
Router(conf-ssh-pubkey-data)#end
Thursday, June 21, 2012
SSH configuration
Tuesday, June 19, 2012
some troubleshooting skill related to CPU usage
process cpu threshold type total rising 80 interval 5
event syslog pattern "%SYS-1-CPURISINGTHRESHOLD"
action 1 cli command "enable"
action 1 cli command "<enable password>"
action 3 cli command "show clock | append flash:risecpu_info"
action 4 cli command "show proc cpu sorted | append flash:risecpu_info"
action 5 cli command "show proc cpu history | append flash:risecpu_info"
action 6 cli command "show interface | append flash:risecpu_info"
action 7 cli command "show int switching | append flash:risecpu_info"
action 8 cli command "show ip traffic | append flash:risecpu_info"
action 9 cli command "show ip cef switching stat feature | append flash:risecpu_info"
action 10 cli command "show debug | append flash:risecpu_info"
action 11 cli command "show align | append flash:risecpu_info"
Saturday, May 7, 2011
IP Prefix Notes
How a Prefix List Match Works
The matching is similar to that of the access-list—more specifically:
· An empty prefix list permits all prefixes.
· An implicit deny is assumed if a given prefix does not match any entries of a prefix list.
· When multiple entries of a prefix list match a given prefix, the one with the smallest sequence is considered as the “real” match. In short, the first match wins!
The matching is similar to that of the access-list—more specifically:
· An empty prefix list permits all prefixes.
· An implicit deny is assumed if a given prefix does not match any entries of a prefix list.
· When multiple entries of a prefix list match a given prefix, the one with the smallest sequence is considered as the “real” match. In short, the first match wins!
Wednesday, May 4, 2011
BGP notes
The BGP Path-Selection Process
1. Ignore paths marked as "not synchronized" in the output of show ip bgp
x.x.x.x. If BGP synchronization is enabled - which is the current default in IOS
Software - there must be a match for the prefix in the IP routing table for an
internal (that is, iBGP) path to be considered a valid path. Most ISPs will want
to disable synchronization using the no synchronization BGP subcommand.
2. Ignore paths for which the NEXT_HOP is inaccessible. This is why it is
important to have an IGP route to the NEXT_HOP associated with the path.
3. Ignore paths from an eBGP neighbor if the local AS appears in the AS path.
Such paths are denied upon ingress into the router and are not even installed
in the BGP RIB. The same applies to any path denied by routing policy
implemented through access, prefix, AS path, or community lists, unless
inbound soft reconfiguration is configured for the neighbor.
4. If bgp bestpath enforce-first-as is enabled and the UPDATE does not
contain the AS of the neighbor as the first AS number in the AS_SEQUENCE,
send a NOTIFICATION and close the session.
5. Ignore paths marked as "(received-only)" in the output of show ip bgp
x.x.x.x. This path has been rejected by policy but has been stored by the
router because soft-reconfiguration inbound has been configured for the
neighbor sending the path.
6. Ignore paths with a next -hop metric marked as inaccessible.
The BGP Best-Path Algorithm for IOS Software
1. Prefer the path with the largest weight. Note that weight is a Cisco specific
parameter, local to the router on which it is configured.
2. Prefer the path with the largest LOCAL_PREF.
3. Prefer the path that was locally originated through a network or aggregate
BGP subcommand or through redistribution from an IGP.
4. Prefer locally sourced network/redistributed paths over locally generated
aggregates.
5. Prefer the path with the shortest AS path.
A. This step is skipped if bgp bestpath as-path ignore is configured.
B. An AS_SET counts as one AS, no matter how many autonomous systems are in the set. The AS_CONFED_SEQUENCE is not included in the AS path length.
6. Prefer the path with the lowest origin type: IGP is lower than EGP, and EGP is
lower than INCOMPLETE.
7. Prefer the path with the lowest MED.
A. This comparison is done only if the first (that is, neighboring) AS is the
same in the two paths; any confederation sub-autonomous systems are ignored. In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same; any preceding AS_CONFED_SEQUENCE is ignored.
B. If bgp always-compare-med is enabled, MEDs are compared for all paths. This knob needs to be enabled over the entire AS. Otherwise, routing loops could occur.
C. If bgp bestpath med confed is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE (that is, paths originated within the local confederation).
D. Paths received with no MED are assigned a MED of 0, unless bgp bestpath missing-is-worst is enabled, in which case they effectively are considered to have (although not actually assigned) a MED of 4,294,967,295. Any route received from a neighbor with a MED of 4,294,967,295 will have the MED changed to 4,294,967,294 before insertion into the BGP table.
E. BGP Deterministic MED also can influence this step.
8. Prefer the eBGP over iBGP paths. Note that paths containing AS_CONFED_SEQUENCE are local to the confederation and, therefore, are treated as internal paths. There is no distinction between confederation external and confederation internal.
9. Prefer the path with the lowest IGP metric to the BGP next hop.
10. If maximum-paths N is enabled and there are multiple external/confederation-external paths from the same neighboring AS/sub-AS, then insert up to N most recently received paths in the IP routing table. This allows eBGP multipath load sharing. The maximum value of N is currently 6; the default value, with the knob disabled, is 1. The oldest received path is marked as the best path in the output of show ip bgp x.x.x.x, and the equivalent of next-hop-self is performed before forwarding this best path on to internal peers.
11. Prefer the path that was received first (that is, the oldest one).
A. This step minimizes route flapping because a newer path will not displace an older one, even if it otherwise would be selected on account of the additional decision criteria below. It makes more sense to apply the additional decision steps only below to iBGP paths, to ensure a consistent best-path decision within the network and thereby avoid loops.
B. This step is skipped if bgp bestpath compare-routerid is enabled.
C. This step is skipped if the ROUTER_ID is the same because the routers were received from the same router.
D. This step is skipped if there is no current best path. An example of losing the current best path occurs when the neighbor offering the path goes down.
12. Prefer the route coming from the BGP router with the lowest router ID. The
router ID is the highest IP address on the router, with preference given to loopback interfaces if one or more are configured. It also can be set manually
through bgp router-id x.x.x.x. Note that if a path contains route reflector attributes, the originator ID is substituted for the router ID in the path-selection process.
13. If the originator/router ID is the same, prefer the path with the minimum
cluster ID length. This will be present in BGP route-reflector environments
only, and it allows clients to peer with route reflectors/clients in other
clusters. In this scenario, the client must be aware of the route reflector-specific BGP attributes.
14. Prefer the path coming from the lowest neighbor address. This is the IP
address used in the BGP neighbor configuration, and it corresponds to the
address that the remote peer uses in the TCP connection with the local router.
Several limitations existed with BGP peer groups in older IOS Software versions:
· If used for clients of a route reflector, all the clients should be fully meshed.
· If used as an eBGP peer group, transit cannot be provided among the peer group members.
· All the eBGP peer-group members should be from the same subnet to avoid nonconnected next-hop announcements.
A list of peer groups commonly by ISPs follows:
· Normal iBGP peer group-For normal iBGP peers.
· iBGP client peer group- For reflection peers on a route reflector.
· eBGP full routes- For peers to receive full Internet routes.
· eBGP customer routes-For peers to receive routes from direct customers of the ISP only. Some members can be configured with default-origination to receive the default route as well as the customer routes.
· eBGP default routes-For peers to receive the default route and possibly a few other routes.
Two or more iBGP paths are considered candidates for multipath if the following
criteria are met:
· All attributes (weight, localpref, AS-PATH [entire attribute, not just length],
Origin, MED, and IGP distance are the same.
· The next hops are different.
Currently the prefix-list ORF is implemented for IPv4 unicast only. Some points to
note about the implementation are listed here:
· By default, the prefix-list ORF capability is not advertised to any neighbors.
· The capability cannot be advertised to a neighbor that is a peer group member.
· The prefix-list ORF is pushed over to the peer router immediately after the session is established if the local router has received the ORF capability and has configured an inbound prefix-list filter for the neighbor.
1. Ignore paths marked as "not synchronized" in the output of show ip bgp
x.x.x.x. If BGP synchronization is enabled - which is the current default in IOS
Software - there must be a match for the prefix in the IP routing table for an
internal (that is, iBGP) path to be considered a valid path. Most ISPs will want
to disable synchronization using the no synchronization BGP subcommand.
2. Ignore paths for which the NEXT_HOP is inaccessible. This is why it is
important to have an IGP route to the NEXT_HOP associated with the path.
3. Ignore paths from an eBGP neighbor if the local AS appears in the AS path.
Such paths are denied upon ingress into the router and are not even installed
in the BGP RIB. The same applies to any path denied by routing policy
implemented through access, prefix, AS path, or community lists, unless
inbound soft reconfiguration is configured for the neighbor.
4. If bgp bestpath enforce-first-as is enabled and the UPDATE does not
contain the AS of the neighbor as the first AS number in the AS_SEQUENCE,
send a NOTIFICATION and close the session.
5. Ignore paths marked as "(received-only)" in the output of show ip bgp
x.x.x.x. This path has been rejected by policy but has been stored by the
router because soft-reconfiguration inbound has been configured for the
neighbor sending the path.
6. Ignore paths with a next -hop metric marked as inaccessible.
The BGP Best-Path Algorithm for IOS Software
1. Prefer the path with the largest weight. Note that weight is a Cisco specific
parameter, local to the router on which it is configured.
2. Prefer the path with the largest LOCAL_PREF.
3. Prefer the path that was locally originated through a network or aggregate
BGP subcommand or through redistribution from an IGP.
4. Prefer locally sourced network/redistributed paths over locally generated
aggregates.
5. Prefer the path with the shortest AS path.
A. This step is skipped if bgp bestpath as-path ignore is configured.
B. An AS_SET counts as one AS, no matter how many autonomous systems are in the set. The AS_CONFED_SEQUENCE is not included in the AS path length.
6. Prefer the path with the lowest origin type: IGP is lower than EGP, and EGP is
lower than INCOMPLETE.
7. Prefer the path with the lowest MED.
A. This comparison is done only if the first (that is, neighboring) AS is the
same in the two paths; any confederation sub-autonomous systems are ignored. In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same; any preceding AS_CONFED_SEQUENCE is ignored.
B. If bgp always-compare-med is enabled, MEDs are compared for all paths. This knob needs to be enabled over the entire AS. Otherwise, routing loops could occur.
C. If bgp bestpath med confed is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE (that is, paths originated within the local confederation).
D. Paths received with no MED are assigned a MED of 0, unless bgp bestpath missing-is-worst is enabled, in which case they effectively are considered to have (although not actually assigned) a MED of 4,294,967,295. Any route received from a neighbor with a MED of 4,294,967,295 will have the MED changed to 4,294,967,294 before insertion into the BGP table.
E. BGP Deterministic MED also can influence this step.
8. Prefer the eBGP over iBGP paths. Note that paths containing AS_CONFED_SEQUENCE are local to the confederation and, therefore, are treated as internal paths. There is no distinction between confederation external and confederation internal.
9. Prefer the path with the lowest IGP metric to the BGP next hop.
10. If maximum-paths N is enabled and there are multiple external/confederation-external paths from the same neighboring AS/sub-AS, then insert up to N most recently received paths in the IP routing table. This allows eBGP multipath load sharing. The maximum value of N is currently 6; the default value, with the knob disabled, is 1. The oldest received path is marked as the best path in the output of show ip bgp x.x.x.x, and the equivalent of next-hop-self is performed before forwarding this best path on to internal peers.
11. Prefer the path that was received first (that is, the oldest one).
A. This step minimizes route flapping because a newer path will not displace an older one, even if it otherwise would be selected on account of the additional decision criteria below. It makes more sense to apply the additional decision steps only below to iBGP paths, to ensure a consistent best-path decision within the network and thereby avoid loops.
B. This step is skipped if bgp bestpath compare-routerid is enabled.
C. This step is skipped if the ROUTER_ID is the same because the routers were received from the same router.
D. This step is skipped if there is no current best path. An example of losing the current best path occurs when the neighbor offering the path goes down.
12. Prefer the route coming from the BGP router with the lowest router ID. The
router ID is the highest IP address on the router, with preference given to loopback interfaces if one or more are configured. It also can be set manually
through bgp router-id x.x.x.x. Note that if a path contains route reflector attributes, the originator ID is substituted for the router ID in the path-selection process.
13. If the originator/router ID is the same, prefer the path with the minimum
cluster ID length. This will be present in BGP route-reflector environments
only, and it allows clients to peer with route reflectors/clients in other
clusters. In this scenario, the client must be aware of the route reflector-specific BGP attributes.
14. Prefer the path coming from the lowest neighbor address. This is the IP
address used in the BGP neighbor configuration, and it corresponds to the
address that the remote peer uses in the TCP connection with the local router.
Several limitations existed with BGP peer groups in older IOS Software versions:
· If used for clients of a route reflector, all the clients should be fully meshed.
· If used as an eBGP peer group, transit cannot be provided among the peer group members.
· All the eBGP peer-group members should be from the same subnet to avoid nonconnected next-hop announcements.
A list of peer groups commonly by ISPs follows:
· Normal iBGP peer group-For normal iBGP peers.
· iBGP client peer group- For reflection peers on a route reflector.
· eBGP full routes- For peers to receive full Internet routes.
· eBGP customer routes-For peers to receive routes from direct customers of the ISP only. Some members can be configured with default-origination to receive the default route as well as the customer routes.
· eBGP default routes-For peers to receive the default route and possibly a few other routes.
Two or more iBGP paths are considered candidates for multipath if the following
criteria are met:
· All attributes (weight, localpref, AS-PATH [entire attribute, not just length],
Origin, MED, and IGP distance are the same.
· The next hops are different.
Currently the prefix-list ORF is implemented for IPv4 unicast only. Some points to
note about the implementation are listed here:
· By default, the prefix-list ORF capability is not advertised to any neighbors.
· The capability cannot be advertised to a neighbor that is a peer group member.
· The prefix-list ORF is pushed over to the peer router immediately after the session is established if the local router has received the ORF capability and has configured an inbound prefix-list filter for the neighbor.
Sunday, April 17, 2011
Spanning Tree Protocol
When a switch receives multiple Hellos with equal calculated cost, it uses the following tiebreakers:
1. Pick the lowest value of the forwarding switch's bridge ID.
2. Use the lowest port priority of the neighboring switch. The neighboring switch added its own port priority to the Hello before forwarding it.
3. Use the lowest internal port number (of the forwarding switch) as listed inside the received Hellos.
spanning-tree mode {mst | pvst | rapid-pvst}
[no] spanning-tree vlan vlan-id
spanning-tree vlan vlan-id {forwardtime seconds | hello-time seconds | max-age seconds | priority priority | {root {primary | secondary} [diameter net-diameter [hello-time seconds]]}}
spanning-tree vlan x cost y
spanning-tree vlan x port-priority y
channel-group channel-group-number mode {auto [non-silent] | desirable [non-silent] | on | active | passive}
channel-protocol {lacp | pagp}
interface port-channel port-channel-number
spanning-tree portfast
spanning-tree bpduguard {enable | disable}
spanning-tree uplinkfast
spanning-tree backbonefast
spanning-tree mst instance-id priority priority
spanning-tree mst configuration
show spanning-tree { root | brief | summary }
show spanning-tree { uplinkfast | backbonefast }
show interface
show interface trunk
show etherchannel [summary]
show interface switchport
show vtp status
show controllers
1. Pick the lowest value of the forwarding switch's bridge ID.
2. Use the lowest port priority of the neighboring switch. The neighboring switch added its own port priority to the Hello before forwarding it.
3. Use the lowest internal port number (of the forwarding switch) as listed inside the received Hellos.
spanning-tree mode {mst | pvst | rapid-pvst}
[no] spanning-tree vlan vlan-id
spanning-tree vlan vlan-id {forwardtime seconds | hello-time seconds | max-age seconds | priority priority | {root {primary | secondary} [diameter net-diameter [hello-time seconds]]}}
spanning-tree vlan x cost y
spanning-tree vlan x port-priority y
channel-group channel-group-number mode {auto [non-silent] | desirable [non-silent] | on | active | passive}
channel-protocol {lacp | pagp}
interface port-channel port-channel-number
spanning-tree portfast
spanning-tree bpduguard {enable | disable}
spanning-tree uplinkfast
spanning-tree backbonefast
spanning-tree mst instance-id priority priority
spanning-tree mst configuration
show spanning-tree { root | brief | summary }
show spanning-tree { uplinkfast | backbonefast }
show interface
show interface trunk
show etherchannel [summary]
show interface switchport
show vtp status
show controllers
Tuesday, April 12, 2011
VLAN
Using VLAN Database Mode to Create VLANs
Switch3# show vlan brief
Switch3# vlan database
Switch3# vlan database
Switch3(vlan)# vlan 21
Switch3(vlan)# show current
Switch3(vlan)# show proposed
Switch3(vlan)# apply
Switch3(vlan)# vlan 22 name ccie-vlan-22
Switch3(vlan)# show current 22
VLAN 22 does not exist in current database
Switch3(vlan)# show proposed 22
Switch3(vlan)# ^Z
Using Configuration Mode to Put Interfaces into VLANs
Switch3# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch3(config)# int fa 0/8
Switch3(config-if)# switchport access vlan 31
% Access VLAN does not exist. Creating vlan 31
Switch3(config-if)# exit
Switch3(config)# vlan 32
Switch3(config-vlan)# name ccie-vlan-32
Switch3(config-if)# ^Z
Switch3(config)# vtp domain CCIE-domain
Switch1# sh vtp status
Switch1# show vlan brief
VLAN Trunking
switchport | no switchport
switchport mode
switchport trunk
switchport access
show interface trunk
show interface type number trunk
show interface type number switchport
Trunking Configuration Options
switchport mode trunk
switchport nonegotiate
switchport mode dynamic desirable
switchport mode dynamic auto
switchport mode access
switchport trunk encapsulation
interface fastethernet 0/0.1
ip address 10.1.21.1 255.255.255.0
encapsulation isl 21
!
interface fastethernet 0/0.2
ip address 10.1.22.1 255.255.255.0
encapsulation isl 22
interface fastethernet 0/0
ip address 10.1.21.1 255.255.255.0
!
interface fastethernet 0/0.2
ip address 10.1.22.1 255.255.255.0
encapsulation dot1q 22
EdgeRouter# conf t
EdgeRouter(config)# interface fa0/1
EdgeRouter(config-if)# ip address 192.168.100.1 255.255.255.0
EdgeRouter(config-if)# ip nat inside
EdgeRouter(config)# interface fa0/1
EdgeRouter(config-if)# pppoe-client dial-pool-number 1
EdgeRouter(config-if)# exit
EdgeRouter(config)# interface dialer1
EdgeRouter(config-if)# mtu 1492
EdgeRouter(config-if)# encapsulation ppp
EdgeRouter(config-if)# ip address negotiated
EdgeRouter(config-if)# ppp authentication chap
EdgeRouter(config-if)# ip nat outside
EdgeRouter(config-if)# dialer pool 1
EdgeRouter(config-if)# dialer-group 1
EdgeRouter(config-if)# exit
EdgeRouter(config)# dialer-list 1 protocol ip permit
EdgeRouter(config)# ip nat inside source list 1 interface dialier1 overload
EdgeRouter(config)# access-list 1 permit 192.168.100.0 0.0.0.255
EdgeRouter(config)# ip route 0.0.0.0 0.0.0.0 dialer1
show pppoe session
debug pppoe [data | errors | events | packets]
show mac address-table [aging-time | count | dynamic | static] [address hw-addr] [interface interface-id] [vlan vlan-id]
show interfaces [interface-id | vlan vlan-id] switchport | trunk]
show vlan [brief | id vlan-id |name vlan-name | summary]
show vlan [vlan]
show vtp status
switchport mode {access | dot1q-tunnel | dynamic {auto | desirable} | trunk}
switchport nonegotiate
switchport trunk {allowed vlan vlan-list} | {encapsulation {dot1q | isl | negotiate}} | {native vlan vlan-id} | {pruning vlan vlan-list}
switchport access vlan vlan-id
VLAN Database
vtp {domain domain-name | password password | pruning | v2-mode | {server | client | transparent}}
vlan vlan-id [backupcrf {enable | disable}] [mtu mtu-size] [name vlan-name] [parent parent-vlan-id] [state {suspend | active}]
show {current | proposed | difference}
apply | abort | reset
VLAN Configuration Mode
vtp {domain domain-name | file filename | interface name | mode {client | server | transparent} | password password | pruning | version number}
vlan vlan-id
Step 1 Change the VTP mode to Transparent, which will reset the configuration
revision number to 0.
Step 2 Delete the vlan.dat file from the switch’s flash.
Step 3 Reboot the switch.
Step 4 Configure the appropriate VTP parameters.
Step 5 Configure trunking.
Step 6 Connect the switch to the network.
Switch3# show vlan brief
Switch3# vlan database
Switch3# vlan database
Switch3(vlan)# vlan 21
Switch3(vlan)# show current
Switch3(vlan)# show proposed
Switch3(vlan)# apply
Switch3(vlan)# vlan 22 name ccie-vlan-22
Switch3(vlan)# show current 22
VLAN 22 does not exist in current database
Switch3(vlan)# show proposed 22
Switch3(vlan)# ^Z
Using Configuration Mode to Put Interfaces into VLANs
Switch3# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch3(config)# int fa 0/8
Switch3(config-if)# switchport access vlan 31
% Access VLAN does not exist. Creating vlan 31
Switch3(config-if)# exit
Switch3(config)# vlan 32
Switch3(config-vlan)# name ccie-vlan-32
Switch3(config-if)# ^Z
Switch3(config)# vtp domain CCIE-domain
Switch1# sh vtp status
Switch1# show vlan brief
VLAN Trunking
switchport | no switchport
switchport mode
switchport trunk
switchport access
show interface trunk
show interface type number trunk
show interface type number switchport
Trunking Configuration Options
switchport mode trunk
switchport nonegotiate
switchport mode dynamic desirable
switchport mode dynamic auto
switchport mode access
switchport trunk encapsulation
interface fastethernet 0/0.1
ip address 10.1.21.1 255.255.255.0
encapsulation isl 21
!
interface fastethernet 0/0.2
ip address 10.1.22.1 255.255.255.0
encapsulation isl 22
interface fastethernet 0/0
ip address 10.1.21.1 255.255.255.0
!
interface fastethernet 0/0.2
ip address 10.1.22.1 255.255.255.0
encapsulation dot1q 22
EdgeRouter# conf t
EdgeRouter(config)# interface fa0/1
EdgeRouter(config-if)# ip address 192.168.100.1 255.255.255.0
EdgeRouter(config-if)# ip nat inside
EdgeRouter(config)# interface fa0/1
EdgeRouter(config-if)# pppoe-client dial-pool-number 1
EdgeRouter(config-if)# exit
EdgeRouter(config)# interface dialer1
EdgeRouter(config-if)# mtu 1492
EdgeRouter(config-if)# encapsulation ppp
EdgeRouter(config-if)# ip address negotiated
EdgeRouter(config-if)# ppp authentication chap
EdgeRouter(config-if)# ip nat outside
EdgeRouter(config-if)# dialer pool 1
EdgeRouter(config-if)# dialer-group 1
EdgeRouter(config-if)# exit
EdgeRouter(config)# dialer-list 1 protocol ip permit
EdgeRouter(config)# ip nat inside source list 1 interface dialier1 overload
EdgeRouter(config)# access-list 1 permit 192.168.100.0 0.0.0.255
EdgeRouter(config)# ip route 0.0.0.0 0.0.0.0 dialer1
show pppoe session
debug pppoe [data | errors | events | packets]
show mac address-table [aging-time | count | dynamic | static] [address hw-addr] [interface interface-id] [vlan vlan-id]
show interfaces [interface-id | vlan vlan-id] switchport | trunk]
show vlan [brief | id vlan-id |name vlan-name | summary]
show vlan [vlan]
show vtp status
switchport mode {access | dot1q-tunnel | dynamic {auto | desirable} | trunk}
switchport nonegotiate
switchport trunk {allowed vlan vlan-list} | {encapsulation {dot1q | isl | negotiate}} | {native vlan vlan-id} | {pruning vlan vlan-list}
switchport access vlan vlan-id
VLAN Database
vtp {domain domain-name | password password | pruning | v2-mode | {server | client | transparent}}
vlan vlan-id [backupcrf {enable | disable}] [mtu mtu-size] [name vlan-name] [parent parent-vlan-id] [state {suspend | active}]
show {current | proposed | difference}
apply | abort | reset
VLAN Configuration Mode
vtp {domain domain-name | file filename | interface name | mode {client | server | transparent} | password password | pruning | version number}
vlan vlan-id
Step 1 Change the VTP mode to Transparent, which will reset the configuration
revision number to 0.
Step 2 Delete the vlan.dat file from the switch’s flash.
Step 3 Reboot the switch.
Step 4 Configure the appropriate VTP parameters.
Step 5 Configure trunking.
Step 6 Connect the switch to the network.
Thursday, March 24, 2011
SPAN & RSPAN notes
Basic SPAN Configuration Example
MDF-ROC1# configure terminal
MDF-ROC1(config)# monitor session 1 source interface fa0/12
MDF-ROC1(config)# monitor session 1 destination interface fa0/24
Complex SPAN Configuration Example
MDF-ROC3# config term
MDF-ROC3(config)# monitor session 11 source interface fa0/18 rx
MDF-ROC3(config)# monitor session 11 source interface fa0/9 tx
MDF-ROC3(config)# monitor session 11 source interface fa0/19
MDF-ROC3(config)# monitor session 11 filter vlan 1 - 3 , 229
MDF-ROC3(config)# monitor session 11 destination interface fa0/24 encapsulation replicate
RSPAN Configuration Example
IDF-SYR1# config term
IDF-SYR1(config)# vlan 199
IDF-SYR1(config-vlan)# remote span
IDF-SYR1(config-vlan)# exit
IDF-SYR1(config)# monitor session 3 source vlan 66 – 68 rx
IDF-SYR1(config)# monitor session 3 destination remote vlan 199
!Now moving to IDF-SYR2:
IDF-SYR2# config term
IDF-SYR2(config)# vlan 199
IDF-SYR2(config-vlan)# remote span
IDF-SYR2(config-vlan)# exit
IDF-SYR2(config)# monitor session 23 source vlan 9 rx
IDF-SYR2(config)# monitor session 23 source vlan 11 rx
IDF-SYR2(config)# monitor session 23 destination remote vlan 199
!Now moving to MDF-SYR9
MDF-SYR9# config term
MDF-SYR9(config)# vlan 199
MDF-SYR9(config-vlan)# remote span
MDF-SYR9(config-vlan)# exit
MDF-SYR9(config)# monitor session 63 source remote vlan 199
MDF-SYR9(config)# monitor session 63 destination interface fa0/24
MDF-SYR9(config)# end
remote span
monitor session 1-66 source [vlan vlan-id | interface interface-id] [rx | tx | both]
monitor session 1-66 destination [remote vlan vlan-id] | interface interface-id]
monitor session 1-66 filter vlan [vlan | vlan-range]
show monitor session session-id
MDF-ROC1# configure terminal
MDF-ROC1(config)# monitor session 1 source interface fa0/12
MDF-ROC1(config)# monitor session 1 destination interface fa0/24
Complex SPAN Configuration Example
MDF-ROC3# config term
MDF-ROC3(config)# monitor session 11 source interface fa0/18 rx
MDF-ROC3(config)# monitor session 11 source interface fa0/9 tx
MDF-ROC3(config)# monitor session 11 source interface fa0/19
MDF-ROC3(config)# monitor session 11 filter vlan 1 - 3 , 229
MDF-ROC3(config)# monitor session 11 destination interface fa0/24 encapsulation replicate
RSPAN Configuration Example
IDF-SYR1# config term
IDF-SYR1(config)# vlan 199
IDF-SYR1(config-vlan)# remote span
IDF-SYR1(config-vlan)# exit
IDF-SYR1(config)# monitor session 3 source vlan 66 – 68 rx
IDF-SYR1(config)# monitor session 3 destination remote vlan 199
!Now moving to IDF-SYR2:
IDF-SYR2# config term
IDF-SYR2(config)# vlan 199
IDF-SYR2(config-vlan)# remote span
IDF-SYR2(config-vlan)# exit
IDF-SYR2(config)# monitor session 23 source vlan 9 rx
IDF-SYR2(config)# monitor session 23 source vlan 11 rx
IDF-SYR2(config)# monitor session 23 destination remote vlan 199
!Now moving to MDF-SYR9
MDF-SYR9# config term
MDF-SYR9(config)# vlan 199
MDF-SYR9(config-vlan)# remote span
MDF-SYR9(config-vlan)# exit
MDF-SYR9(config)# monitor session 63 source remote vlan 199
MDF-SYR9(config)# monitor session 63 destination interface fa0/24
MDF-SYR9(config)# end
remote span
monitor session 1-66 source [vlan vlan-id | interface interface-id] [rx | tx | both]
monitor session 1-66 destination [remote vlan vlan-id] | interface interface-id]
monitor session 1-66 filter vlan [vlan | vlan-range]
show monitor session session-id
Subscribe to:
Posts (Atom)