just passed it... switch and route down, tshoot is all that's left for me on ccnp...
network cisco ccna gns3 certification arteq
a network runs through it
Showing posts with label ccnp switch. Show all posts
Showing posts with label ccnp switch. Show all posts
Friday, November 30, 2012
Sunday, October 28, 2012
ios v junos... memory...
most cisco ios flavors use a flat memory space which means that the current processes have access to all allocated memory at any given time... this allows for a loose and fast process allocation per requesting process...
junos, conversely, uses protected memory resources which means that specific memory is reserved for use by specific processes at any given time...
the argument can be made for advantages in both models; the flat memory model is arguably faster while the protected memory model disallows process corruption vis a vis, one process cannot subsume the others memory area; it is protected...
ios is non preemptive multitasking which means that the process gives back the resources when the process decides to, with some limits...
in ios, a process can be in one of 5 self-evident states, determined by the scheduler...
New— The process has just been created and has no resources. It has never been scheduled to run.
Ready— The process is ready to run and should be scheduled on the processor the next time it is eligible.
Run— The process is currently running.
Idle— The process is waiting for some event to become ready to run.
Dead— The process is dead; it is being cleaned up.
junos, conversely, uses protected memory resources which means that specific memory is reserved for use by specific processes at any given time...
the argument can be made for advantages in both models; the flat memory model is arguably faster while the protected memory model disallows process corruption vis a vis, one process cannot subsume the others memory area; it is protected...
ios is non preemptive multitasking which means that the process gives back the resources when the process decides to, with some limits...
in ios, a process can be in one of 5 self-evident states, determined by the scheduler...
New— The process has just been created and has no resources. It has never been scheduled to run.
Ready— The process is ready to run and should be scheduled on the processor the next time it is eligible.
Run— The process is currently running.
Idle— The process is waiting for some event to become ready to run.
Dead— The process is dead; it is being cleaned up.
Sunday, July 29, 2012
net acad labs...
one of the things i liked most about doing the netacad labs for switch is that they are structured, meaning they get you into good habits... of course it's a pain in the ass, but nothing that was ever worth anything wasn't a pain in the ass...
repetition is paramount here; doing things without having to think about them...
i can set up an enterprise switch block in a half hour from scratch... i don't even think about the vlans, the addressing, port channles or hsrp anymore, routing, it's built in...
funny, some people i know talk about hsrp like it's old... well, yeah, it is old, but it works great, and it's the father of ha and redundancy... if you know hsrp, you also know vrrp and glbp, and the idea of vitualization is planted firmly...
don't be jaded when it comes to certain older technologies; they are still taught for very good reason... without a foundation your house falls down... don't be the guy who wants to start at chapter 48, there were 47 chapters you missed along the way... i have no patience for people like that... you'll never be good at building a nexus system if you can't already build a basic switch...
i've been getting into nx-os lately... what you find is everything old is new again...
between junos and nx-os the idea of burying the system under a bunch of aliased commands is becoming obsolete, and the unix command line coming back into the fore of these systems is for me, welcome and refreshing...
if you can't navigate a file system you will be left behind... dust off the old system V and berkeley books; use a linux distro instead of nasty windows as your desktop... get back to where the power is... the gui is your enemy...
when you follow my labs, don't just scrape the configs into your topologies... type em like you got a pair...
repetition is paramount here; doing things without having to think about them...
i can set up an enterprise switch block in a half hour from scratch... i don't even think about the vlans, the addressing, port channles or hsrp anymore, routing, it's built in...
funny, some people i know talk about hsrp like it's old... well, yeah, it is old, but it works great, and it's the father of ha and redundancy... if you know hsrp, you also know vrrp and glbp, and the idea of vitualization is planted firmly...
don't be jaded when it comes to certain older technologies; they are still taught for very good reason... without a foundation your house falls down... don't be the guy who wants to start at chapter 48, there were 47 chapters you missed along the way... i have no patience for people like that... you'll never be good at building a nexus system if you can't already build a basic switch...
i've been getting into nx-os lately... what you find is everything old is new again...
between junos and nx-os the idea of burying the system under a bunch of aliased commands is becoming obsolete, and the unix command line coming back into the fore of these systems is for me, welcome and refreshing...
if you can't navigate a file system you will be left behind... dust off the old system V and berkeley books; use a linux distro instead of nasty windows as your desktop... get back to where the power is... the gui is your enemy...
when you follow my labs, don't just scrape the configs into your topologies... type em like you got a pair...
Friday, July 20, 2012
ccnp switch... passed today...
that was an arduous six months... the best part of it all is that ccna has been extended three years for me and i will officially never have to take the ccna exam again... thank God...
i often hear about people who allow their ccna to lapse... that is a sin... like starting all over again in beginners... who wants to doggy paddle again after learning to swim... argghhh...
although i started route towards the end, it is nice to know that i can now dive in head first without a twinge of guilt...
what i used:
the ocg, of course, and used that to create a bunch of anki decks that included, glossary, key topics, diagrams, tables, do i know this already, etc. anki is invaluable...
i've recently been checking out freemind lately, seems like a lot of work, but worth the effort... any active studying is good studying...
also:
paul browning, switch simplified; chris bryant, ccnp switch (great mp3's that i played every day on the way to work); of course cisco.com and cln, and anybody's site out there...
and my lab... ahhh my lab...
countless hours on the lab... there is no other way at the professional level... build em, tear em down, troubleshoot em, and do it again... create your own break/fix... test the limits of the commands and interfaces, any scenario... and i highly recommend the net academy switch lab book from cisco press... learn to do it the cisco way or the highway... it's part of the drill...
i've also looked into jncia... if you like unix, you will love junos...
below is a diagram from a friend (nuno) who has been putting ospf into freemind... you need to use this...
i often hear about people who allow their ccna to lapse... that is a sin... like starting all over again in beginners... who wants to doggy paddle again after learning to swim... argghhh...
although i started route towards the end, it is nice to know that i can now dive in head first without a twinge of guilt...
what i used:
the ocg, of course, and used that to create a bunch of anki decks that included, glossary, key topics, diagrams, tables, do i know this already, etc. anki is invaluable...
i've recently been checking out freemind lately, seems like a lot of work, but worth the effort... any active studying is good studying...
also:
paul browning, switch simplified; chris bryant, ccnp switch (great mp3's that i played every day on the way to work); of course cisco.com and cln, and anybody's site out there...
and my lab... ahhh my lab...
countless hours on the lab... there is no other way at the professional level... build em, tear em down, troubleshoot em, and do it again... create your own break/fix... test the limits of the commands and interfaces, any scenario... and i highly recommend the net academy switch lab book from cisco press... learn to do it the cisco way or the highway... it's part of the drill...
i've also looked into jncia... if you like unix, you will love junos...
below is a diagram from a friend (nuno) who has been putting ospf into freemind... you need to use this...
Saturday, July 14, 2012
mac spoofing and cam table overflow...
these two wear me out because mitigation is the same basic procedure for both...
a word from an earlier post:
http://insearchofthecert.blogspot.com/2012/07/quote-of-day-attack-mitigation.html
CAM table overflow— In a CAM table overflow attack, an attacker sends thousands of bogus MAC addresses from one port, which looks like valid hosts' communication to the switch. You can mitigate CAM table overflow attacks in several ways. One of the primary ways is to configure port security on the switch. You can apply port security in three ways: static secure MAC addresses, dynamic secure MAC addresses, and sticky secure MAC addresses.
and
MAC address spoofing— MAC address spoofing involves the use of a known MAC address of another host authorized to access the network. The attacker attempts to make the target switch forward frames destined for the actual host to the attacker device instead. Another way to spoof MAC addresses is by using ARP.
Use the port-security command described in the "Mitigating CAM Table Overflow Attacks" section to specify MAC addresses connected to particular ports. DHCP snooping could be used as a method to mitigate MAC address spoofing. Another method of mitigating MAC address spoofing is DAI.
as stated above, cam table overflow is mitigated by port security... mac spoofing is also mitigated by port security, but it would also be helpful to use dhcp snooping and/or dai...
the attack is different...
vlan hopping is mitigated by limiting the impact of dtp in the network, ie making unused ports access and placing them in a dysfunctional vlan, et al...
these kind of gray areas kill me... like loop guard and udld, that exhibit a similar behavior when preventing loops... the big difference in loop guard and udld, as i see it is media... udld for fiber and loop guard for ethernet... both freak out when bpdu's suddenly go missing...
from : http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094640.shtml
The STP loop guard feature provides additional protection against Layer 2 forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually happens because one of the ports of a physically redundant topology (not necessarily the STP blocking port) no longer receives STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs based on the port role. The designated port transmits BPDUs, and the non-designated port receives BPDUs.
When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes designated and moves to a forwarding state. This situation creates a loop.
The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop.
then this:
Loop guard and Unidirectional Link Detection (UDLD) functionality overlap, partly in the sense that both protect against STP failures caused by unidirectional links. However, these two features differ in functionality and how they approach the problem. This table describes loop guard and UDLD functionality:
Based on the various design considerations, you can choose either UDLD or the loop guard feature. In regards to STP, the most noticeable difference between the two features is the absence of protection in UDLD against STP failures caused by problems in software. As a result, the designated switch does not send BPDUs. However, this type of failure is (by an order of magnitude) more rare than failures caused by unidirectional links. In return, UDLD might be more flexible in the case of unidirectional links on EtherChannel. In this case, UDLD disables only failed links, and the channel should remain functional with the links that remain. In such a failure, the loop guard puts it into loop-inconsistent state in order to block the whole channel.
Additionally, loop guard does not work on shared links or in situations where the link has been unidirectional since the link-up. In the last case, the port never receives BPDU and becomes designated. Because this behaviour could be normal, this particular case is not covered by loop guard. UDLD provides protection against such a scenario.
As described, the highest level of protection is provided when you enable UDLD and loop guard.
a word from an earlier post:
http://insearchofthecert.blogspot.com/2012/07/quote-of-day-attack-mitigation.html
CAM table overflow— In a CAM table overflow attack, an attacker sends thousands of bogus MAC addresses from one port, which looks like valid hosts' communication to the switch. You can mitigate CAM table overflow attacks in several ways. One of the primary ways is to configure port security on the switch. You can apply port security in three ways: static secure MAC addresses, dynamic secure MAC addresses, and sticky secure MAC addresses.
and
MAC address spoofing— MAC address spoofing involves the use of a known MAC address of another host authorized to access the network. The attacker attempts to make the target switch forward frames destined for the actual host to the attacker device instead. Another way to spoof MAC addresses is by using ARP.
Use the port-security command described in the "Mitigating CAM Table Overflow Attacks" section to specify MAC addresses connected to particular ports. DHCP snooping could be used as a method to mitigate MAC address spoofing. Another method of mitigating MAC address spoofing is DAI.
as stated above, cam table overflow is mitigated by port security... mac spoofing is also mitigated by port security, but it would also be helpful to use dhcp snooping and/or dai...
the attack is different...
vlan hopping is mitigated by limiting the impact of dtp in the network, ie making unused ports access and placing them in a dysfunctional vlan, et al...
these kind of gray areas kill me... like loop guard and udld, that exhibit a similar behavior when preventing loops... the big difference in loop guard and udld, as i see it is media... udld for fiber and loop guard for ethernet... both freak out when bpdu's suddenly go missing...
from : http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094640.shtml
The STP loop guard feature provides additional protection against Layer 2 forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually happens because one of the ports of a physically redundant topology (not necessarily the STP blocking port) no longer receives STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs based on the port role. The designated port transmits BPDUs, and the non-designated port receives BPDUs.
When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes designated and moves to a forwarding state. This situation creates a loop.
The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state. Without the loop guard feature, the port assumes the designated port role. The port moves to the STP forwarding state and creates a loop.
then this:
Loop guard and Unidirectional Link Detection (UDLD) functionality overlap, partly in the sense that both protect against STP failures caused by unidirectional links. However, these two features differ in functionality and how they approach the problem. This table describes loop guard and UDLD functionality:
| Functionality | Loop Guard | UDLD |
|---|---|---|
| Configuration | Per-port | Per-port |
| Action granularity | Per-VLAN | Per-port |
| Autorecover | Yes | Yes, with err-disable timeout feature |
| Protection against STP failures caused by unidirectional links | Yes, when enabled on all root and alternate ports in redundant topology | Yes, when enabled on all links in redundant topology |
| Protection against STP failures caused by problems in the software (designated switch does not send BPDU) | Yes | No |
| Protection against miswiring. | No | Yes |
Based on the various design considerations, you can choose either UDLD or the loop guard feature. In regards to STP, the most noticeable difference between the two features is the absence of protection in UDLD against STP failures caused by problems in software. As a result, the designated switch does not send BPDUs. However, this type of failure is (by an order of magnitude) more rare than failures caused by unidirectional links. In return, UDLD might be more flexible in the case of unidirectional links on EtherChannel. In this case, UDLD disables only failed links, and the channel should remain functional with the links that remain. In such a failure, the loop guard puts it into loop-inconsistent state in order to block the whole channel.
Additionally, loop guard does not work on shared links or in situations where the link has been unidirectional since the link-up. In the last case, the port never receives BPDU and becomes designated. Because this behaviour could be normal, this particular case is not covered by loop guard. UDLD provides protection against such a scenario.
As described, the highest level of protection is provided when you enable UDLD and loop guard.
Wednesday, July 4, 2012
aaa new-model...
we know that one must globally enable aaa in order to support tacacs or radius authentication...
but before implementing tacacs, you setup ssh on the device for use with the local database...
username x password x
and
transport input ssh
login local
once aaa is enabled, login local goes away, and will force authentication to the tacacs box... fair enough... if you look at the vty config you'll notice login local disappears...
but arteq, you protest, what will we do if the tacacs server goes down; how will we get to the device...
when aaa is not available, login local will magically reappear, and allow authentication with the user database that you know you set up prior to implementing aaa...
be a backdoor man...
but before implementing tacacs, you setup ssh on the device for use with the local database...
username x password x
and
transport input ssh
login local
once aaa is enabled, login local goes away, and will force authentication to the tacacs box... fair enough... if you look at the vty config you'll notice login local disappears...
but arteq, you protest, what will we do if the tacacs server goes down; how will we get to the device...
when aaa is not available, login local will magically reappear, and allow authentication with the user database that you know you set up prior to implementing aaa...
be a backdoor man...
port dot1x...
see below... this is nice...
omg, what's wrong with my port... this makes perfect sense... if you are using radius (sorry) configuring the interface for use is paramount to complete the configuration...
globally:
enable aaa
define the server and key
define the authentication
enable dot1x
the point... dot1x on the port won't work if it's not an access port... why?
because we are not men...
we are devo...
dls1(config)#int f0/19
dls1(config-if)#dot1x port-control auto
^
% Invalid input detected at '^' marker.
dls1(config-if)#
dls1(config-if)#dot1x port-control auto
^
% Invalid input detected at '^' marker.
dls1(config-if)#
omg, what's wrong with my port... this makes perfect sense... if you are using radius (sorry) configuring the interface for use is paramount to complete the configuration...
globally:
enable aaa
define the server and key
define the authentication
enable dot1x
dls1(config)#aaa new-model
dls1(config)#radius-server host 192.168.1.102 key 789
dls1(config)#aaa authentication dot1x default group radius
dls1(config)#dot1x system-auth-control
dls1(config)#int f0/20
dls1(config-if)#dot1x port-control force-un
^
% Invalid input detected at '^' marker.
dls1(config-if)#sw mode acc
dls1(config-if)#dot1x port-control force-un
dls1(config-if)#
dls1(config)#radius-server host 192.168.1.102 key 789
dls1(config)#aaa authentication dot1x default group radius
dls1(config)#dot1x system-auth-control
dls1(config)#int f0/20
dls1(config-if)#dot1x port-control force-un
^
% Invalid input detected at '^' marker.
dls1(config-if)#sw mode acc
dls1(config-if)#dot1x port-control force-un
dls1(config-if)#
the point... dot1x on the port won't work if it's not an access port... why?
because we are not men...
Tuesday, July 3, 2012
vlan access-map
good...
Extended IP access list no_telnet
10 permit tcp host 192.168.100.10 192.168.100.0 0.0.0.255 eq telnet (3 estim
ate matches)
dls1(config)#vlan access-map stop
dls1(config-access-map)#action drop
dls1(config-access-map)#match ip add no_telnet
dls1(config-access-map)#vlan access-map stop
dls1(config-access-map)#action forward
dls1(config-access-map)#exit
dls1(config)#vlan filter stop vlan-list 100
this works to block telnet for host 192.168.100.10 to vlan 100...
let's examine this thing... access-maps are counterintuitive. create the access list to permit first so then you can filter it with the vlan map using various criteria. it's ass backwards, but works... the consensus here is that if you can get these, route maps make complete sense...
the no_telnet is a variable to describe the ip that will be acted upon... basic RACL stuff and easier because it's permit... no thinking...
instead of access-list there is access-map for the vlan... in the example above stop is the variable for the action... call it poop, whatever, doesn't matter... the action in this case is to drop, and then we match the ip defined in the access-list which we called no_telnet, the action drop will be performed on it...
we then redefine stop to forward, which is the default action if one is not proscribed, and since we don't match an access list to it, it will forward everything not defined by the acl...
then assign the vlan (vlan 100 in this case) to filter using stop, which is our access map...
here's another:
dls1(config)#ip access-list extended NO
dls1(config-ext-nacl)#permit ip host 192.168.1.10 host 192.168.1.100
dls1(config)#vlan access-map YES
dls1(config-access-map)#action drop
dls1(config-access-map)#match ip address NO
dls1(config-access-map)#vlan access-map YES
dls1(config-access-map)#action forward
dls1(config-access-map)#exit
dls1(config)#vlan filter YES vlan-list 200
dls1(config)#
see below, vlan 200 cannot be pinged by the host
arteq@bo:~$ ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_req=1 ttl=63 time=1.24 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.567 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.592 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.562 ms
arteq@bo:~$ ping 192.168.200.1
PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
Extended IP access list no_telnet
10 permit tcp host 192.168.100.10 192.168.100.0 0.0.0.255 eq telnet (3 estim
ate matches)
dls1(config)#vlan access-map stop
dls1(config-access-map)#action drop
dls1(config-access-map)#match ip add no_telnet
dls1(config-access-map)#vlan access-map stop
dls1(config-access-map)#action forward
dls1(config-access-map)#exit
dls1(config)#vlan filter stop vlan-list 100
this works to block telnet for host 192.168.100.10 to vlan 100...
let's examine this thing... access-maps are counterintuitive. create the access list to permit first so then you can filter it with the vlan map using various criteria. it's ass backwards, but works... the consensus here is that if you can get these, route maps make complete sense...
the no_telnet is a variable to describe the ip that will be acted upon... basic RACL stuff and easier because it's permit... no thinking...
instead of access-list there is access-map for the vlan... in the example above stop is the variable for the action... call it poop, whatever, doesn't matter... the action in this case is to drop, and then we match the ip defined in the access-list which we called no_telnet, the action drop will be performed on it...
we then redefine stop to forward, which is the default action if one is not proscribed, and since we don't match an access list to it, it will forward everything not defined by the acl...
then assign the vlan (vlan 100 in this case) to filter using stop, which is our access map...
here's another:
dls1(config)#ip access-list extended NO
dls1(config-ext-nacl)#permit ip host 192.168.1.10 host 192.168.1.100
dls1(config)#vlan access-map YES
dls1(config-access-map)#action drop
dls1(config-access-map)#match ip address NO
dls1(config-access-map)#vlan access-map YES
dls1(config-access-map)#action forward
dls1(config-access-map)#exit
dls1(config)#vlan filter YES vlan-list 200
dls1(config)#
see below, vlan 200 cannot be pinged by the host
arteq@bo:~$ ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_req=1 ttl=63 time=1.24 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.567 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.592 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.562 ms
arteq@bo:~$ ping 192.168.200.1
PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data.
Monday, July 2, 2012
glbp...
is as easy as hsrp.... it's just cooler...
notice the virtual mac's below...
and the ping macro...
this is very exciting...
interface Vlan1
ip address 192.168.1.1 255.255.255.0
glbp 1 ip 192.168.1.5
glbp 1 priority 110
glbp 1 preempt
!
interface Vlan100
ip address 192.168.100.1 255.255.255.0
glbp 1 ip 192.168.100.5
glbp 1 priority 110
glbp 1 preempt
!
interface Vlan200
ip address 192.168.200.1 255.255.255.0
glbp 1 ip 192.168.200.5
glbp 1 priority 110
glbp 1 preempt
ip address 192.168.1.1 255.255.255.0
glbp 1 ip 192.168.1.5
glbp 1 priority 110
glbp 1 preempt
!
interface Vlan100
ip address 192.168.100.1 255.255.255.0
glbp 1 ip 192.168.100.5
glbp 1 priority 110
glbp 1 preempt
!
interface Vlan200
ip address 192.168.200.1 255.255.255.0
glbp 1 ip 192.168.200.5
glbp 1 priority 110
glbp 1 preempt
notice the virtual mac's below...
dls1#sh glbp brie
Interface Grp Fwd Pri State Address Active router Standby router
Vl1 1 - 110 Active 192.168.1.5 local 192.168.1.2
Vl1 1 1 - Active 0007.b400.0101 local -
Vl1 1 2 - Listen 0007.b400.0102 192.168.1.2 -
Vl100 1 - 110 Active 192.168.100.5 local 192.168.100.2
Vl100 1 1 - Listen 0007.b400.0101 192.168.100.2 -
Vl100 1 2 - Active 0007.b400.0102 local -
Vl200 1 - 110 Active 192.168.200.5 local 192.168.200.2
Vl200 1 1 - Listen 0007.b400.0101 192.168.200.2 -
Vl200 1 2 - Active 0007.b400.0102 local -
dls1#
Interface Grp Fwd Pri State Address Active router Standby router
Vl1 1 - 110 Active 192.168.1.5 local 192.168.1.2
Vl1 1 1 - Active 0007.b400.0101 local -
Vl1 1 2 - Listen 0007.b400.0102 192.168.1.2 -
Vl100 1 - 110 Active 192.168.100.5 local 192.168.100.2
Vl100 1 1 - Listen 0007.b400.0101 192.168.100.2 -
Vl100 1 2 - Active 0007.b400.0102 local -
Vl200 1 - 110 Active 192.168.200.5 local 192.168.200.2
Vl200 1 1 - Listen 0007.b400.0101 192.168.200.2 -
Vl200 1 2 - Active 0007.b400.0102 local -
dls1#
and the ping macro...
dls1(config)#macro global apply mping
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.101, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.102, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
dls1(config)#
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.101, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.102, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
dls1(config)#
this is very exciting...
Sunday, June 24, 2012
cef punt..
why?
kick it...
the fib is full (i'm all outta fib)
entry can't be located by the fib
ttl has expired
fragment required because mtu has been exceeded
icmp redirect needed
unsupported encapsulation
tunneled packets needing encryption or compression
acl with log operation
nat needed, except for 6500 sup 720 or better which can do nat in hardware
ask fibber...
kick it...
the fib is full (i'm all outta fib)
entry can't be located by the fib
ttl has expired
fragment required because mtu has been exceeded
icmp redirect needed
unsupported encapsulation
tunneled packets needing encryption or compression
acl with log operation
nat needed, except for 6500 sup 720 or better which can do nat in hardware
ask fibber...
4096...
the significance of 4096 is understood in relation to switching, especially spanning tree...
what is 2 to the 12th?
4096...
from: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/spantree.html#wp1037363
A 12-bit extended system ID field is part of the bridge ID (see Table 28-1). Chassis that support only 64 MAC addresses always use the 12-bit extended system ID. On chassis that support 1024 MAC addresses, you can enable use of the extended system ID. STP uses the VLAN ID as the extended system ID.
When the extended system ID is enabled, the root bridge priority becomes a multiple of 4096 plus the VLAN ID. With the extended system ID enabled, a switch bridge ID (used by the spanning tree algorithm to determine the identity of the root bridge, the lowest being preferred) can only be specified as a multiple of 4096. Only the following values are possible: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, and 61440.
then given this:
Bridge Priority (2 bytes)—The priority or weight of a switch in relation to all other switches. The Priority field can have a value of 0 to 65,535 and defaults to 32,768 (or 0x8000) on every Catalyst switch.
what is 2 to the 12th?
4096...
from: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/spantree.html#wp1037363
A 12-bit extended system ID field is part of the bridge ID (see Table 28-1). Chassis that support only 64 MAC addresses always use the 12-bit extended system ID. On chassis that support 1024 MAC addresses, you can enable use of the extended system ID. STP uses the VLAN ID as the extended system ID.
When the extended system ID is enabled, the root bridge priority becomes a multiple of 4096 plus the VLAN ID. With the extended system ID enabled, a switch bridge ID (used by the spanning tree algorithm to determine the identity of the root bridge, the lowest being preferred) can only be specified as a multiple of 4096. Only the following values are possible: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, and 61440.
then given this:
Bridge Priority (2 bytes)—The priority or weight of a switch in relation to all other switches. The Priority field can have a value of 0 to 65,535 and defaults to 32,768 (or 0x8000) on every Catalyst switch.
so interpreting hex here from right to left, the first zero is the one's place holder, the second zero is the 16's place holder, the third zero is the 256's place holder and the 8 is the 4096's place holder...
8 times 4096 is 32768
0x1000 equals 4096
0x0100 equals 256
0x0010 equals 16
0x0000 equals ?
Saturday, June 23, 2012
radius...
why?
radius = remote authentication dial in user service...
the first question one should ask is, do user's actually dial in anymore?
at any rate...
enable aaa new-model as you would for tacacs
aaa new-model
then the radius server
radius-server host (hostname) (key)
define the 802.1x authentication method
configure each switchport for usage
radius = remote authentication dial in user service...
the first question one should ask is, do user's actually dial in anymore?
at any rate...
enable aaa new-model as you would for tacacs
aaa new-model
then the radius server
radius-server host (hostname) (key)
define the 802.1x authentication method
aaa authentication dot1x default group radius
enable 802.1x on the switch
dot1x system-auth-control
configure each switchport for usage
(config-if)# dot1x port-control {force-authorized | forceunauthorized
| auto}
| auto}
then sit back and try to figure out why you'd ever use this garbage...
Sunday, June 17, 2012
rpr to sso...
this is the best graphic that i could find... from the hucaby ocg... read it and weep...
hsrp states...
hsrp goes through various states to obtain the active role... according to david hucaby in the ccnp switch ocg we have:
When HSRP is configured on an interface, the router progresses through a series of states before becoming active. This forces a router to listen for others in a group and see where it fits into the pecking order. Devices participating in HSRP must progress their interfaces through the following state sequence:
1. Disabled
2. Init
3. Listen
4. Speak
5. Standby
6. Active
2. Init
3. Listen
4. Speak
5. Standby
6. Active
whoa... according to rfc 2281 we have...
All routers begin in the Initial state. This section discusses the
intent of each state. For specific details on the actions taken in
each state, please see the state transition table in section 5.7.
1. Initial
This is the starting state and indicates that HSRP is not running.
This state is entered via a configuration change or when an
interface first comes up.
2. Learn
The router has not determined the virtual IP address, and not yet
seen an authenticated Hello message from the active router. In
this state the router is still waiting to hear from the active
router.
3. Listen
The router knows the virtual IP address, but is neither the active
router nor the standby router. It listens for Hello messages from
those routers.
Li, et. al. Informational [Page 8]
RFC 2281 Cisco HSRP March 1998
4. Speak
The router sends periodic Hello messages and is actively
participating in the election of the active and/or standby router.
A router cannot enter Speak state unless it has the virtual IP
address.
5. Standby
The router is a candidate to become the next active router and
sends periodic Hello messages. Excluding transient conditions,
there MUST be at most one router in the group in Standby state.
6. Active
The router is currently forwarding packets that are sent to the
group's virtual MAC address. The router sends periodic Hello
messages. Excluding transient conditions, there MUST be at most
one router in Active state in the group.
i hate when that shit happens...
then from cisco.com we have...
http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/dt_hsrpi.html
Active—Current Hot Standby router
here there is learn, but no mention of disabled... in all 3 cases there are six states...
and finally...
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gthsrpv2.html
initial and disabled got married in the fourth one...
would someone please try to get these people together...
assured forwarding and drop precedence...
it is important to remember that less is more, or better, much like with stp, when it comes to assured forwarding and its corresponding drop precedence...
look at that great dscp table again...
within this table there is no explanation of the drop precedence, but we understand that drop precedence is implied in the af number itself...
in class selector 3 the af value for the first number is THE class selector...
af31, af32, af33
the second number defines the drop precedence; 1 is low, 2 is medium and 3 is high...
the drop precedence is lower or better, which means the lower number 1 has a low drop probability compared with 3 (high drop probability), and 2 is medium...
most likely the consideration will be made in favor of af31 for traffic defined by class selector 3...
notice these granular choices are not available for cs5, 6 and 7...
one last point... the higher the class selector, the higher the priority, so cs4 beats cs3, etc... but within the af, af31 is preferred over af33...
it goes both ways...
look at that great dscp table again...
in class selector 3 the af value for the first number is THE class selector...
af31, af32, af33
the second number defines the drop precedence; 1 is low, 2 is medium and 3 is high...
the drop precedence is lower or better, which means the lower number 1 has a low drop probability compared with 3 (high drop probability), and 2 is medium...
most likely the consideration will be made in favor of af31 for traffic defined by class selector 3...
notice these granular choices are not available for cs5, 6 and 7...
one last point... the higher the class selector, the higher the priority, so cs4 beats cs3, etc... but within the af, af31 is preferred over af33...
it goes both ways...
Monday, June 11, 2012
dscp/ip precedence...
even easier still... thanks to this guy http://www.dasblinkenlichten.com/?p=376
just great... ordered so well.... barely have to remember afxy(8x + 2y)
the class selector and the ip precedence follow each other... binary and decimal at cs1 (8) always increment by two, until voice... sheer genius...
thank you dasblinkerlicker... he did what i was shooting for yesterday...
the class selector and the ip precedence follow each other... binary and decimal at cs1 (8) always increment by two, until voice... sheer genius...
thank you dasblinkerlicker... he did what i was shooting for yesterday...
Sunday, June 10, 2012
yet more dscp...
cribbed from ine, by scott morris http://ieoc.com/forums/p/5257/17674.aspx
AF11 is not a hex value... So the calculator won't help you much. :)
It means Class 1 Threshold 1.
Now, the class value = IP Prec value where is where we start with the backwards compatibility.
IP Prec 0 = DSCP 0 (000 vs 000000)
IP Prec 1 = DSCP 8 (001 vs 001000)
IP Prec 2 = DSCP 16 (010 vs 010000)
IP Prec 3 = DSCP 24 (011 vs 011000)
IP Prec 4 = DSCP 32 (100 vs 100000)
IP Prec 5 = DSCP 40 (101 vs 101000)
IP Prec 6 = DSCP 48 (110 vs 110000)
IP Prec 7 = DSCP 56 (111 vs 111000)
Now, the thresholds use the "2-bit" and "4-bit" positions for values (00 being the default class)
01 = Threshold 1 (therefore 001010 is AF 11 or DSCP 10)
10 = Threshold 2 (therefore 001100 is AF 12 or DSCP 12 (the ONLY overlap in numbers))
11 = Threshold 3 (therefore 001110 is AF 13 or DSCP 14)
Just change the first three bits for the remainder of the classes 1 through 4.
AF11 is not a hex value... So the calculator won't help you much. :)
It means Class 1 Threshold 1.
Now, the class value = IP Prec value where is where we start with the backwards compatibility.
IP Prec 0 = DSCP 0 (000 vs 000000)
IP Prec 1 = DSCP 8 (001 vs 001000)
IP Prec 2 = DSCP 16 (010 vs 010000)
IP Prec 3 = DSCP 24 (011 vs 011000)
IP Prec 4 = DSCP 32 (100 vs 100000)
IP Prec 5 = DSCP 40 (101 vs 101000)
IP Prec 6 = DSCP 48 (110 vs 110000)
IP Prec 7 = DSCP 56 (111 vs 111000)
Now, the thresholds use the "2-bit" and "4-bit" positions for values (00 being the default class)
01 = Threshold 1 (therefore 001010 is AF 11 or DSCP 10)
10 = Threshold 2 (therefore 001100 is AF 12 or DSCP 12 (the ONLY overlap in numbers))
11 = Threshold 3 (therefore 001110 is AF 13 or DSCP 14)
Just change the first three bits for the remainder of the classes 1 through 4.
dscp and ip precedence cont...
look again...
notice that the af numbers follow the cs numbers and increase by 1, hence cs3 contains af's 31, 32 and 33.. for assured forwarding in class 3, 31 is the lowest priority for the class, 33 is the highest... that still prevails, but the ds field values don't... tough shit... life isn't fair...
notice af22's ds field value equals 20 decimal or binary 010100, but also notice the ds field values are a constant increment of 2... some compensation there...
if you remember the class selector, ie, cs4 is decimal 4 x 8 or 32, the corresponding af values beyond the cs increase by 1, and the decimal value increases by 2 each time giving af41 (4x8) + 2 or 34, af42 is then plus two or 36 decimal... kinda clunky but it works for me...
there is this formula as well... afxy = 8x + 2y = decimal value or
af32 = 3 times 8 + 2 times 2 = 24 + 4 = 28
and in a pinch there is also this...
dls1(config)#access-list 101 permit ip any any dscp ?
<0-63> Differentiated services codepoint value
af11 Match packets with AF11 dscp (001010)
af12 Match packets with AF12 dscp (001100)
af13 Match packets with AF13 dscp (001110)
af21 Match packets with AF21 dscp (010010)
af22 Match packets with AF22 dscp (010100)
af23 Match packets with AF23 dscp (010110)
af31 Match packets with AF31 dscp (011010)
af32 Match packets with AF32 dscp (011100)
af33 Match packets with AF33 dscp (011110)
af41 Match packets with AF41 dscp (100010)
af42 Match packets with AF42 dscp (100100)
af43 Match packets with AF43 dscp (100110)
cs1 Match packets with CS1(precedence 1) dscp (001000)
cs2 Match packets with CS2(precedence 2) dscp (010000)
cs3 Match packets with CS3(precedence 3) dscp (011000)
cs4 Match packets with CS4(precedence 4) dscp (100000)
cs5 Match packets with CS5(precedence 5) dscp (101000)
cs6 Match packets with CS6(precedence 6) dscp (110000)
cs7 Match packets with CS7(precedence 7) dscp (111000)
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)
again, af11 is cs1 plus 1, af12 is cs1 plus 2, af11 = af(8x1 + 2x1) or 10 or 001010
af21 is cs2 plus 1 or 8x2 + 2x1 or 16 plus 2 or 18
although cs5 is 8x5 or 40 expedited forwarding for voice has a ds field value of 46... you'll have to memorize that... or convert binary to decimal from the above output...
| ef Match packets with EF dscp (101110) = 46 | |||||
dscp and ip precedence...
i am only scratching the surface of this, and i'm finding it's mostly not that complicated...
ip precedence is fairly simple, 0 to 7, with 0 being the lowest priority or best effort, and increasing the numbers the higher the priority (i do like the numbers, but i also like logic with the numbers, you'll see what i mean as we move along)
the class selector follows this logic...
cs0 is binary 000000 which translates to decimal 0 and has ip precedence 0
beautiful
cs1 increases to binary 001000 which translates to decimal 8 and has an ip precedence of 1
there are only 6 place holders, imagine the two leading zeros
if you are shaky on binary to decimal remember 128 64 32 16 8 4 2 1
0 0 0 0 1 0 0 0
so the ip precedence increases by 1 and follows the class selector...
hence, cs2 has an ip precedence of 2, cs3 has an ip precedence of 3, and so on up to cs7
also as the class selector increases by one, it's decimal value increases by 8 and is followed by the binary value
again cs0 is zero across the board
cs1 has increased by 1 from zero and it's ds value has increased to decimal 8 or binary 001000
cs2 is academic... ip precedence is now 2, and it has increased by 8 so the decimal value (it's ds field value) is now 16, binary 010000
cs3, ip precedence 3, increase another 8 to decimal 24 with the binary translation 011000
cs4, 5, 6 and 7 all follow the same logic which gives cs7 an ip precedence of 7, and ds field value decimal 56 or 111000
7 times 8 is 56 or 32 + 16 + 8 + 0 + 0 + 0 = 56
see chart below... thanks to http://bogpeople.com/networking/dscp.shtml
ip precedence is fairly simple, 0 to 7, with 0 being the lowest priority or best effort, and increasing the numbers the higher the priority (i do like the numbers, but i also like logic with the numbers, you'll see what i mean as we move along)
the class selector follows this logic...
cs0 is binary 000000 which translates to decimal 0 and has ip precedence 0
beautiful
cs1 increases to binary 001000 which translates to decimal 8 and has an ip precedence of 1
there are only 6 place holders, imagine the two leading zeros
if you are shaky on binary to decimal remember 128 64 32 16 8 4 2 1
0 0 0 0 1 0 0 0
so the ip precedence increases by 1 and follows the class selector...
hence, cs2 has an ip precedence of 2, cs3 has an ip precedence of 3, and so on up to cs7
also as the class selector increases by one, it's decimal value increases by 8 and is followed by the binary value
again cs0 is zero across the board
cs1 has increased by 1 from zero and it's ds value has increased to decimal 8 or binary 001000
cs2 is academic... ip precedence is now 2, and it has increased by 8 so the decimal value (it's ds field value) is now 16, binary 010000
cs3, ip precedence 3, increase another 8 to decimal 24 with the binary translation 011000
cs4, 5, 6 and 7 all follow the same logic which gives cs7 an ip precedence of 7, and ds field value decimal 56 or 111000
7 times 8 is 56 or 32 + 16 + 8 + 0 + 0 + 0 = 56
see chart below... thanks to http://bogpeople.com/networking/dscp.shtml
DSCP <=> IP Precedence Conversion Table
| DSCP Name | DS Field Value | IP Precedence | |
|---|---|---|---|
| Binary | Decimal | ||
| CS0 | 000 000 | 0 | 0 |
| CS1 | 001 000 | 8 | 1 |
| AF11 | 001 010 | 10 | 1 |
| AF12 | 001 100 | 12 | 1 |
| AF13 | 001 110 | 14 | 1 |
| CS2 | 010 000 | 16 | 2 |
| AF21 | 010 010 | 18 | 2 |
| AF22 | 010 100 | 20 | 2 |
| AF23 | 010 110 | 22 | 2 |
| CS3 | 011 000 | 24 | 3 |
| AF31 | 011 010 | 26 | 3 |
| AF32 | 011 100 | 28 | 3 |
| AF33 | 011 110 | 30 | 3 |
| CS4 | 100 000 | 32 | 4 |
| AF41 | 100 010 | 34 | 4 |
| AF42 | 100 100 | 36 | 4 |
| AF43 | 100 110 | 38 | 4 |
| CS5 | 101 000 | 40 | 5 |
| EF | 101 110 | 46 | 5 |
| CS6 | 110 000 | 48 | 6 |
| CS7 | 111 000 | 56 | 7 |
| CS | Class Selector (RFC 2474) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AFxy | Assured Forwarding (x=class, y=drop precedence) (RFC2597) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| EF | Expedited Forwarding (RFC 3246) |
Subscribe to:
Posts (Atom)