Non-contiguous Netmasks
Posted on: 6 de August de 2012
A long, long time ago (2006), I’ve made a video showing the communication between 2 machines configured with non-contiguous network masks (ie: 255.0.255.255).
At that time, I couldn’t find answers on the Internet regarding the subject, so, as my objective was doing this in NMAP, I’ve started a discussion at the mailing list (http://seclists.org/nmap-dev/2006/q4/50) and ended with a lot of negative answers.
As a student, my mind was thinking “What the hell, this is just mathematic. Why can’t I have non-contiguous netmask?”
THE MATH:
Mathematically, a source host to analyse if a destination host belongs to the same subnet just do a simple AND binary operation, using the destination IP address and its own Network Mask and then compare it to its own network address.
It’s quite simple. Imagine this scenario:
- Host Address: 192.168.1.1
- Network Mask: 255.255.255.0
- Destination Address: 192.168.1.2
Operation for destination IP:
11000000.10101000.00000001.00000010 AND 11111111.11111111.11111111.00000000 ------------------------------------------------------- 192.168.1.0
Which is equal to the host network (192.168.1.0).
What about if we use a netmask with 1 at the final octet?
- Host Address: 192.168.1.1
- Network Mask: 255.255.255.1
- Destination Address: 192.168.1.2
Operation for destination IP:
11000000.10101000.00000001.00000010 AND 11111111.11111111.11111111.00000001 ------------------------------------------------------- 192.168.1.0
Operation for host IP:
11000000.10101000.00000001.00000011 AND 11111111.11111111.11111111.00000001 ------------------------------------------------------- 192.168.1.1
192.168.1.0 != 192.168.1.1. So, with the final 1 in the netmask, the hosts ARE NOT at the same subnet! Why? Because of the AND logical operation.
———————————————————————————
With this configuration we can have a lot of interesting designs. Some of them are listed below:
ODDS AND EVENS SUBNETS (MASK 255.255.255.1):
By inserting the 1 at the final octet we create a network with only ODD or EVEN hosts!
So:
– 192.168.1.1, 192.168.1.3, 192.168.1.5 are in a subnet.
– 192.168.1.2, 192.168.1.4, 192.168.1.6 are in another subnet.
Not only this. The Network Address for the first subnet is 192.168.1.1, and the Broadcast Address for the second subnet is 192.168.1.254.
REVERSE SUBNET (?) (MASK 0.255.255.255. THIS NOT WILDCARD 😉 ):
By modifying the Network Mask in that way the rightmost octets define the network and the first octet define the hosts. Ex.:
192.168.1.1 and 66.168.1.1 are in the same subnet.
Network Address = 0.168.1.1. Broadcast Address = 255.168.1.1.
192.168.1.1 and 192.168.1.66 are in different subnets.
————————————————————————-
REAL IMPLEMENTATION:
This is indeed very interesting, but in a real environment it’s not practical. Why?
– As stated at the NMAP discussion link, this is against the RFCs (2979 and 4623 to begin);
– Almost the majority of Operating Systems does not support this kind of configuration:
Windows 7 (my own translation, since my windows is in portuguese):
--------------------------- Microsoft TCP/IP --------------------------- You entered an invalid subnet mask. The subnet mask must be contiguous. Enter a valid mask. --------------------------- OK ---------------------------
Linux (Ubuntu ~ Debian):
livio@livio-VirtualBox:~$ ifconfig 192.168.1.1 netmask 255.255.0.255 SIOCSIFNETMASK: Invalid Argument
– Routers, MAY NOT support routing to these networks
Cisco 7200 using GNS3:
R1(config-if)#ip address 192.168.1.1 255.255.0.255 Bad mask 0xFFFF00FF for address 192.168.1.1 R1(config-if)#ip route 192.168.1.1 255.255.0.255 192.168.1.1 %Inconsistent address and mask
Conclusion:
So, is it useful? I don’t know. I’ve heard of a friend that configured this kind of scenario in a ISP to make the network less “discoverable”. Take your own conclusion…
If you are curious, watch my Video at YouTube below showing a WORKING SCENARIO with OpenBSD (the only OS that I found to support non contiguous netmasks). SORRY FOR THE POOR QUALITY.
- In: Real Time | SNMP
- Leave a Comment
If you are planning to use the real-time monitor described at my previous post “RRDtool HTTP real time monitor” to poll a Linux machine, You can change the update interval using this “trick”.
Make a SNMP SET request to the following OID with the update interval desired in seconds:
NET-SNMP-AGENT-MIB::nsCacheTimeout.<oid to modify interval>
or
1.3.6.1.4.1.8072.1.5.3.1.2.<oid to modify interval>
EXAMPLE:
Changing the update interval for the IF-MIB OIDs:
snmpset -v 1 -c private 127.0.0.1 NET-SNMP-AGENT-MIB::nsCacheTimeout.1.3.6.1.2.1.2.2 i 1
Remember that you also need to create a read and write (RW) community at snmpd.conf.
EXAMPLE:
com2sec readwrite default private
——————————————–
The trick:
A tricky solution to this is to edit snmpd init script and add this command to be executed after the daemon startup.
EXAMPLE:
In debian after these lines in /etc/init.d/snmpd
start-stop-daemon --quiet --start --oknodo --exec /usr/sbin/snmpd \ -- $SNMPDOPTS echo -n " snmpd"
add
snmpset -v 1 -c private 127.0.0.1 NET-SNMP-AGENT-MIB::nsCacheTimeout.1.3.6.1.2.1.2.2 i 1 echo -n "setting update time to 1 second"
You can always check the update interval making a snmpwalk at the NET-SNMP-AGENT-MIB::nsCacheTimeout OID
NOTE: You are enabling a READ AND WRITE community! Limit the access to this community (preferable only for 127.0.0.1)
Nexus 7000 packet capture
Posted on: 30 de July de 2012
- In: Nexus
- Leave a Comment
As a troubleshooting lover, I always end up trying to figure out a problem depurating packets. In old days it was quite simple using CISCO IOS “debug ip packet”. Nowadays, as almost nothing depends on the equipment processor, the data plane traffic isn’t capturable using this command.
Some options that can be used to help the in-depth troubleshooting in a Nexus 7000 environment are:
- Use port mirroring using SPAN
- Use remote port mirroring using ERSPAN (only after NX-OS release 5.1)
- Make a port-based ACL with the “log” option, so the traffic goes to the Switching Processor, and you can perform Ethereal command. (never tested, saw on this e-mail at C-NSP mailing list)
- Use ELAM (Embedded Logical Analyzer Module), as stated in this and this excellent articles from www.feeny.org.
RRDtool HTTP real time monitor
Posted on: 30 de July de 2012
- In: Real Time | SNMP
- 2 Comments
A long time ago, I’ve worked on a script made in PHP using it’s SNMP functions and PHP “System” function to create, update and graph RRD databases containing interfaces statistics.
Requeriments:
PHP with SNMP support
HTTP Server
SNMP Access to devices
RRDTool (I think that version 1.2.15+ will do it)
I’ve tested it on Debian Etch with Apache 2.2.3, net-snmp 5.2.3(needed for PHP snmp support) and PHP 5.2.0-8+etch7.
To use it, the following must be done:
- Download the file (at the end of the post), rename it to “.php”, and save it in your monitoring server (an HTTP access is needed);
- Create a folder to store the RRD databases and graphs; (must have HTTP access)
- Open it with the editor and edit the “Changeable Variables”, at the beggining of the file:
- Set a default snmp community to query the hosts.
- Specify the temporary directory that the RRD files and graphs will be stored, and the relative path.
- You must set the path for the rrdtool executable (if it’s in PATH, you can leave it as it is).
After this is all set, you can just access the PHP page with your browser, and specify an host IP Address to monitor.
Observations:
-> I’ve noted, that Windows machines only updates it’s OIDs in a 5 seconds interval, so you can’t monitor it in a interval less than this;
-> Some equipment will have different update time on it’s OID. You will need to check the best update value for each equipment;
-> On some CISCO equipment (IOS based) you can change the default update time using the CLI command “ snmp-server hc poll centiseconds ” on global configuration;
-> It’s VERY important that you set a default community, RESTRICT the access to the page to only a few guys and access the page ONLY with SSL encription. If you set a default community, the PHP page does not need to pass the community via HTTP, so you will be at least a little more safer.
-> When the graphs are updating in a 1 second interval, the CPU usage of the server can raise up to 10%.
-> Do not consider this page as a monitoring tool. It’s a problem diagnose tool and a behavior analisys tool, to verify traffics spikes, errors and so on…
# # KNOWNBUGS # #
-> The RRD files are beign re-created without need, but no impact is caused at all (maybe a little).
Download (zipped): real-time.zip
The NET-SNMP snmpwalk command is a really good tool , but it has a really big help output, to simplify things just use one of the below examples and, if needed add the adequate parameters:
SNMP v1:
snmpwalk -v1 -c <community> <ipaddress>[:<dest_port>] <oid>
example:
snmpwalk -v1 -cpublic 127.0.0.1:161 system
SNMP v2:
snmpwalk -v2c -c <community> <ipaddress>[:<dest_port>] [oid]
example:
snmpwalk -v2c -c public 127.0.0.1:161 system
SNMP v3:
snmpwalk -v3 -l <noAuthNoPriv|authNoPriv|authPriv> -u <username> [-a <MD5|SHA>] [-A <authphrase>] [-x DES] [-X <privaphrase>] <ipaddress>[:<dest_port>] [oid]
example:
snmpwalk -v3 -l authPriv -u snmpadmin -a MD5 -A PaSSword -x DES -X PRIvPassWord 127.0.0.1:161 system
VRRP vs ACL
Posted on: 8 de January de 2010
- In: Rede | Roteadores | VRRP
- Leave a Comment
Para a aplicação do VRRP, não esquecer de configurar qualquer ACL aplicada nas interfaces para permitir o tráfego do VRRP (ip protocol 112), caso contrário, mesmo que o VRRP esteja configurado, ele não conseguirá enviar mensagens de Hello, e consequentemente não funcionará.
O VRRP sobe como Initialize e muda para Backup e ao invés de ficar como Backup, ou mudar para Master como normalmente faria, ele retorna para o estado Initialize. Alguns routers indicam o problema como se a interface estivesse down o que é um erro.
FQDN - Random Stuffs 