Ip Address is not returning on rquesting cdpCacheAddress in snmp, instead showing c0:a8:0a:xX - snmp

i did a snmpwalk code in java , to retrieve data associated with cdp cache. except cdpCacheAddress, every thing is showing as expected. cdpCacheAddress is expected as IP but shows as c0:a8:0a:xX . the oid i requested is begins with .1.3.6.1.4.1.9.9.23.1.2.1.1.4. how can i find the ip address of the neighbor with this data. is there any other way to find the neighbor's IP address with cdp .
please help.

That is an IP address.
It's four octets, each shown in hex, delimited by colons. It could also be rendered as "192.168.10.xX".
The syntax is defined to be a CiscoNetworkAddress (whose definition includes the DISPLAY-HINT that results in the default rendering you see), so you should interpret it as such.
You can transform & display it however you like!
How to do that depends entirely on your language/environment.

Related

What is the syntax for IPv6 with both a zone and a range/prefix length

I see an IPv6 address can have a range or prefix length specifier, e.g. /64.
I also see it can have a zone index, e.g. %1.
So what is the syntax when you want both? Is it {addr}%1/64 or {addr}/64%1 or does it not matter (or can you not have both)? Did not find any examples or explanation in wikipedia - they only discuss them separately.
The prefix/mask length is just like for an IPv4 prefix/mask length, but IPv6 does not use explicit masks the way IPv4 can. For example, an IPv4 address of 10.11.12.13/24 is usually used as 10.11.12.13 255.255.255.0, but the IPv6 address of 2001:db8::1/64 does not have a representation with an explicit mask (the mask is implied from the mask length).
A Zone ID is only used for IPv6 Link-Local addressing, which will always be in the fe80::/64 range on each interface, and that is why you need a Zone ID to tell which interface is meant since they all use the same Link-Local network.
There would not really be a case where you combine those the way you have.

Why is the content of QNAME field NOT the original domain in a DNS message?

Why is the content of QNAME field NOT the original domain in a DNS message?
For example, if I want to get the IP of domain www.mydomain.com, I will send a DNS lookup package to the network, and the package's question section contains the domain.
But actually the content of QNAME in the package is 3www8mydomain3com0 instead of www.mydomain.com.
3www8mydomain3com0 means every label begin with the length of this part and then content, end with length of 0.
So, Why do we use length+data pattern to describe a domain rather than original domain?
Have a look at this section 4.1.2. Question section formatdescribes how we define the domain record on RFC1035 (Please search to see this section).
(Domain names changed to get Stack Overflow to shut up about the domain that cannot be named.)
For example, if I want to get the IP of domain www.qqqqsovr.com, I will send a DNS lookup package to the network, and the package's question section contains this url.
That's not a URL, it's a domain name. A domain name is part of a URL, but a URL would be something like http://www.qqqqsovr.com/homepage.html.
But actually the content of QNAME in the package is 3www8qqqqsovr3com0 instead of www.qqqqsovr.com.
That is www.qqqqsovr.com. As Calle Dybedahl said, it's because the names are encoded in a somewhat complicated form. Section 3.1 "Name space definitions" of RFC 1035 says:
Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less.
and those individual bits of the name can be pointed to by other names, so, for example, if you had both www.qqqqsovr.com and www.abcdefgh.com in a DNS message, the second domain name could point to the .com of the first domain name; this is described in section 4.1.4 "Message compression" of RFC 1035.
Simply putting the domain string into the messages as a text string wouldn't allow compression; you'd need some way to express pointers. You'd probably have to ask Paul Mockapetris why he (and Jon Postel) chose to use that particular encoding.
And even there the string length has to be indicated somehow, either by a count or by null-termination. In 1987, whilst UNIX machines were common on the Internet, they weren't, as far as I know, so common that null-termination was an "obvious" choice.
1) DNS knows nothing of URLs. DNS is older than the concept of a URL.
2) Because that's how DNS's wire format works. What you see is the domain name www.mydomain.com, encoded in the DNS binary format. Length+data is a very common way of storing strings in general.

Capture Filter with Wildcard in IP Address

I am trying to customize Wireshark capture such that is captures all IP addresses (both source and destination) with the IP address format xxx.xxx.xxx.100.
I used the following Capture Filter
ip matches /.*/.*/.*/.100
but the text box remains red'
These are not IP addresses in a particular range, just the fourth octet is 100
Your regex is a little off, as you need to use a backslash to escape the periods. Try this:
ip.host matches "\.100$"
That should match .100 at the end of the string.
Source: http://ask.wireshark.org/questions/22230/filter-for-partial-ip-address
Edit: Try using the Display Filter (Analyze->Display Filters..), not the Capture Filter

Only pull IP Address from a line of text

I've got a script that searches through a logfile for a specific trigger, and then pulls out the line when it's found. For example, this is a line I'm looking for:
7/2/10 9:24:12 AM puppetmasterd[63092] Could not resolve 10.13.1.190: no name for 10.13.1.190
It saves this line into a variable "line", but I'd like to be able to extract only the IP Address.
Our IP Addresses all start with 10.13 - is there an easy way to search for that in this variable and then isolate ONLY the IP address into a variable?
matches = line.scan(/10\.13\.[12]?[0-9]?[0-9]\.[12]?[0-9]?[0-9]/);
You want to read about regular expressions on Ruby. Your specific problem is fairly easy, so it would be a good learning exercise. (Try the tutorial if the first link is too advanced!)

What is the actual minimum length of an email address as defined by the IETF?

I'm specifically looking for the minimum length of the prefix and domain.
I've seen conflicting information and nothing that looks authoritative.
For reference, I found this page which claims that a one character email address is functional:
http://www.cjvandyk.com/blog/Lists/Posts/Post.aspx?ID=176
I tried validating email addresses at Gmail and they expect prefix greater than or equal to 6.
These are obviously way off.
My web framework expects prefix greater than or equal to 2.
The shortest valid email address may consist of only two parts: name and domain.
name#domain
Since both the name and domain may have the length of 1 character, the minimal total length resolves to 3 characters.
well the problem is really the question.. email depends on if it is sent over the internet, or within a closed system (eg intranet). over the internet, I believe x#y.zz is the shortest email possible (e.g. google's G.CN for china would result in the shortest email adress possible, e.g. i#g.cn, which is 6 characters long). on the intranet however, it is an entirely different thing, and i#y would be possible, which is just 3 characters long.
I believe the standard you are looking for is RFC 2822 - Internet Message Format
More specific info on email address restrictions in RFC 3696 - Section 3
To quote the spec:
Contemporary email addresses consist of a "local part" separated from a "domain part" (a fully-qualified domain name) by an at-sign ("#").
So three characters is the shortest.
I originally got this info from Phil Haack's blog post.
Many mail-servers will not accept the email-address if there aren't at least 2 characters before the #.
That doesn't make it an invalid address, but if the servers don't know that, it sure can lead to a lot of problems.

Resources