There are many ways a Cisco Type-7 password could be decrypted. Look at the following encoded passwords.
It could be decoded using any of the following methods:
Now that the hard work is behind me, the awesome holiday has past, I can finally get back to all the outstanding fun stuff. That said I have some good half completed posts are on the way :)
I came across the following command browsing the DOC-CD a couple months back, and I have used it ever since.
sh run vrf [vrf-name]
The show running vrf feature provides the option to display a subset of the running configuration on a router that is linked to a VRF instance. It can be used to display the configuration of a specific VRF or of all VRFs configured on a router. The command is unfortunately only available on the more recent IOS versions, but if available makes life easy.
Often knowing the necessary show commands is not enough, you need to understand the output.
Here is a good example and breakdown of each of the fields with the command:
show traffic-shape
VC = 'DLCI's' Access List = 'Used to shape traffic of common type for separation' Target Rate = 'CIR in bits' Byte-Limit = 'Bc+Be ie the size the token bucket, express in BYTES' Sustain bits/int = 'Bc value per Tc, (int is short for interval or Tc)' Excess bits/int = 'Be value' Interval (ms) = 'Tc value' Increment (bytes) = 'How many bytes of token replenished each Tc, ie Bc value in bytes' Adapt Active = 'Shows Adaptive shaping has been enabled. If a BECN is received, the flow is throttled back'
What else can be set about the configuration here?
The interface have 3 DLCI’s defined.
DLCI’s 413 and 405 have a CIR of 56k. This was not configured. This is default behaviour. When ‘frame-relay traffic-shaping’ is enabled each DLCI on that interface will be allocated a 56k CIR unless changed. Here it is clear that DLCI 403 has a map-class policy applied.
Oh and Merry Christmas guys :D
When BGP peers set up their session between them, they send an OPEN message possibly containing optional parameters.
One optional parameter is capabilities. Possible capabilities are Multiprotocol extensions, route refresh, outbound route filtering (ORF), and so on. When the BGP peers exchange the Multiprotocol extension capability, they exchange AFI and SAFI numbers and thus identify what the other BGP speaker is capable of.
IPv6 in BGP is implementated via Multi-Protocol BGP (MPBGP) (RFC 2283), as is MPLS and VPN’s through two new attributes: MP_UNREACH_NLRI and MP_REACH_NLRI. The first two values in these two attributes contain the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).
| AFI | Meaning |
| 1 | IPv4 |
| 2 | IPv6 |
.
| SAFI | Meaning |
| 1 | Unicast |
| 2 | Multicast |
| 3 | Unicast and multicast |
| 4 | MPLS Label |
| 128 | MPLS-labeled VPN |
Knowing the difference in telnet responses could easily point you in the right direction when a telnet to a host on a particular port in unsuccessful.
There are a distinct differences in getting ‘refused’ or ‘timeout’ responses.
You will get a connection refused message for one of the following reasons:
Example output from a linux box:
Sometimes it is necessary to go back to the basics that we have already forgotten. You can identify six possible states in the interface status line of the show interfaces serial output:
In the previous article I showed how useful Netflow can be, but that is only the beginning. The “verbose” output provides even more useful information, specifically the TOS-Byte. That field is necessary when you want to verify if QOS marking is correctly applied to traffic classes.
But first you have to understand a little about QOS (Quality of Service) and the TOS-byte/DS-Field in the IP header.
The IP header is defined in RFC 791, includes a 1-byte field called the Type of Service (ToS) byte. The ToS byte was intended to be used as a field to mark a packet for treatment with QoS tools. The ToS byte itself was initially further subdivided, with the high-order 3 bits defined as the IP Precedence (IPP) field. Bits 3 through 6 were not used very often, and bit 7 was never defined, so over time the entire ToS byte’s purpose was to hold the 3-bit IPP field. 3 bits (23 = 8 ) allowed 8 possible markings.
Ever needed to track specific flow of information or find out what ports a application is using, or verify if your QOS is working correctly? Cisco Netflow is the answer.
NetFlow is a Cisco IOS application that provides a rich set of traffic statistics on packets flowing through the router, both ingress and egress. A NetFlow network flow is defined as a unidirectional stream of packets between a given source and destination. These key fields/statistics define a unique flow:
If a packet has one key field different from another packet, it is considered to belong to another flow. Flows are stored in the NetFlow cache and does does consumes additional memory, but generally this is not to much of a problem. Netflow data could be exported, but here I’ll show how to use it on CLI and how to interpret it.
Error: The image in the archive which would be used to upgrade
Error: system number 1 does not support the same feature set.
Cisco it seems included this sanity check,as of 12.2(35), to prevent you from accidentally changing the feature set during a IOS upgrade, not a nice thing to happen on a production switch, when things go belly up.
You will get the above error when upgrading the IOS and changing the feature set. IE if you upgrade the image from IPBASE 12.2(35)SE5 to ADVIPSERVICESK9 12.2(25)SEE4.
So to bypass this, you can add the /allow-feature-upgrade parameter, to the archive download-sw command.
Example :
#archive download-sw /overwrite /allow-feature-upgrade tftp:10.1.1.1/c3560-advipservicesk9-tar.122-25.SEE4.tar
If you need more info on how to upgrade the IOS on a Cisco 3560, visit Cisco.
Error log:
%BGP-3-NOTIFICATION:received from neighbor 196.7.8.9 2/2 (peer in wrong as) 2 bytes 0064
Explanation:
The Obvious is true, a wrong ASN is configured, but there is more detail here. “2 bytes 0064” : the 0064 is the received ASN in HEX, ie 0x0064 in HEX = 100 decimal.
The local router is expecting Neighbor 196.7.8.9 to come from a specific ASN, not ASN 100. Have a look at the “neighbor {IP} remote-as” command to confirm it is set correctly. If confederations are used, make sure your confederation-id is correct between the two EBGP peers.
Routing-Bits 