I am implementing a component that receives IP addresses and port ranges from command line or configuration files. For IP addresses, I use the CIDR notation. However I'm unable to find out if there is a similar standard for specifying network ports or network port ranges.
I currently envision a simple comma-separated list of dash-separated ranges (e.g., "3999,5001-9999") but I'd like to refer to some specification (RFC or otherwise) that defines it. I'm even willing to switch to a different notation as long as there is some standard to back it.
Related
Frameworks like Genie Parser or TextFSM parse the output of the configuration. That is what the device answers when you ask it about some part of the configuration, like show ip route or show access-lists.
For example, this is the output of ACLs and it can be parsed by the aforementioned frameworks:
switch1#show access-lists
Standard IP access list acl-snmp-4
10 permit 10.0.0.1
20 permit 10.0.0.2
30 permit 192.168.0.1
40 permit 192.168.0.2
What I'm looking for is parsing the input - the text people need to type in when configuring the device. This is useful when one wants to programatically verify that the configuration standard is correct.
For example, verify that the following snippet has the correct IPs:
ip access-list standard ACL1
remark Server1
permit host 10.0.0.1
permit host 10.0.0.2
remark Server2
permit host 192.0.0.3
permit 54.101.80.0 0.0.0.63
I'm using some for loops and regex at the moment, but it gets messy when you get dozens of device types, OS types, config styles.
With show access-list you can see the operational data and not directly the configuration and yes, Genie or TextFSM are solutions to convert operational text output into structured data.
For configuration data, I would recommend to take a look at ttp.
I'm not quite sure what use case you are trying to solve. If you want to generate configuration, why not use a templating engine? For example, jinja2
The CLI is not really designed for automation, so check if your devices have proper APIs like netconf-yang.
I have a language monitor that I am trying to query the printer from.
First let me apologize for the possible confusion since "port" means 2 things in this description. There is the one use that refers to the port that the printer is configured to use, which could be TCP, USB, etc. And then there is the use of port that refers to the port address to send data to when communicating with the printer's IP address.
I need to be able to specify different port addresses to send different custom queries to a printer over the same IP that are specific to it's firmware. I can't find any examples or documentation on what the standard way is to do this communication... I can extract the IP address and open a net socket, but I am not sure if this is the appropriate way to handle this communication. It's not uncommon for printers to send status over one port, and print data over another. If i want to write to the Default port I can use pfnWritePort and pfnReadPort, but these don't allow me to specify the actual port.. it uses whatever the driver is configured as.
Can anyone provide some guidance or examples of how I should do this from my language monitor?
EDIT: As an example for clarification, all commands are sent to the same IP, but depending on the command/query I need to send, the TCP port needs to change. The way I am handling it now is opening up a net socket with the same IP and different port numbers for data and status channels).
You should be required to write an app that would be able to reconfigure driver. Ideology of OS is that EACH real device would corresponds to instance of driver and\or interface. Which might be an elevated action, because it requires to create new printer interface("port" in Windows GUI terms) and change driver settings.
On my package 1, under the info it says (source)54841 > 80(destination). May I know what are these terms mean and why these particular ports are being used. i know that for tcp, they uses 80 for destination port. but is there a particular reason? Thank you
In fact, there are two questions with two different answers.
Firstly, you have to be exact: The port definition is part of the Internet Proctocol (commonly called TCP/IP) application layer. The tcp protocol is a protocol of the underlying transport layer, so the definition / use of port 80 is not defined for tcp, but rather for the http application protocol (while the actual port usage takes place in the transport layer).
Regarding the destination port, you nearly gave the answer yourself: For well defined application protocols, there were defined well known ports. The list is maintained by IANA (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml). Usually, the ports were defined in the privileged low number range (up to 1024). When that range became to full, there were also higher port numbers assigned.
The reasoning behind the well defined port numbers is, that services can only listen on specific ports, and if the numbers were known by convention, you had to memorize them along with the server adress. For your example, HTTP, that means, that if you start a request for http://www.example.com, your browser (or other software) knows that http usually uses port 80, connects to that port to get the html page. You can still run http servers on different ports (say, 12345), but than, the user had to enter http://www.example.com:12345 to reach the server. You can see that using well defined ports is helpful here.
For the source port, it is a completely different story. As transport layer connections usually use ports for multiplexing/demultiplexing on both source and destination, every connection must also have a source port. The lower port numbers can not be used for this purpose, as on one hand, they are often used for listening services, and on the other hand, their usage is privileged on some operating systems, so normal users cannot use them at all. For this reasons, IANA assigned the port range from 49152 to 65535 (2^15+2^14 to 2^(16−1)) for that purpose. Most operating systems will select one of this ports for outgoing connections source port. The selection is, however, short lived - when the connection is closed, the port is released, and the next connection can use an other port.
Here is a wireshark capture of an ARP request PNG image, I contains the sender MAC inside the ARP packet. The receiving station can derive the MAC from the Ethernet frame. It seems to be redundant. Is there any particular use of separately including the sender MAC address in ARP Request too ?.
The "redundancy" was by design (RFC 826), and can be useful in targeting different layers. In RFC 3927 there's what is known as Gratuitous Address Resolution Protocol (GARP), and in certain circumstances the redundancy, or lack of, plays an important role, especially in troubleshooting and monitoring networking stacks.
Actually it's not rendunancy at all, the MAC (physical, layer 2) and IP (logical, layer 3) addresses are not the same thing. They serve different purposes on different network layers.
On large scale networks it's quite common to observe changes in the MAC/ARP/Source/Dest information, and at times can seem almost incorrect. For example, you might see a host send an ARP request with its own address as the target address. Depending on the exact situation, it might be telling us it's a link up/down event, maybe it's trying update other devices ARP tables, or possibly detecting an ip conflict and moving the ip to another NIC.
I could get into clustering, failovers — the list goes on, although I would end up writing a book trying to explain it all. Hopefully this gives you a bit of insight about the "redundancy" you were questioning. ;-)
More Info:
RFC 826 /
RFC 3927
/ Wireshark Gratuitous ARP
Although often used in conjunction with Ethernet, ARP by itself is an independent protocol. Imagine other link layer protocols that do not expose MAC addresses. ARP would not work in such circumstances if the sender field was not provided.
There is no rule that the ARP protocol field sender mac address to be same as ethernet source mac address. Eg: Its possible in few applications where multiple interfaces of same host are on network, but one only interface sends arp responses for all interfaces.
When setting the IP for where the client should connect,do I need to make distinguish between and IP like 208.56.123.1 and one like "www.domain.com" ?
IP is only the number.
So, 208.56.123.1 is IP, but www.domain.com is not - it's a symbolic name. Both are addresses, but only the number is IP.
Symbolic name will usually resolve to an actual IP using DNS server.
As to your question, will both work the same, the answer is - it only depends on how your client is implemented.
Both addresses should refer to the same location, though it might be better to target the symbolic name, because IP is more likely to change.
Depends on the use case. Most programming languages / network libraries come with built-in support for name resolution.
Low-level system calls like bind() or connect() do not support name resolution and require you to get the IP.