When it comes to Computer Networks, what is a logical address and physical address

Why can't I see MAC addresses of the attached PCs on polling the OID for the above switch?

When you poll 1.3.6.1.2.1.4.22.1.2, you're polling ipNetToMediaPhysAddress, which is the ARP table of the switch. Pure Layer2 switches do not have a large ARP table because they are merely switching instead of routing. Switching does not require an ARP table.

Also can someone throw light on the fine differences between the MAC addresses learned from dot1qTpFdbPort and ipNetToMediaPhysAddress?

• dot1qTpFdbPort maps the Layer2 mac-address recently learned by the switch to a physical port on the switch.
• ipNetToMediaPhysAddress polls the ARP table of something. The only things that show up in the ARP table are things which had recent, direct IP-layer communication with the thing being polled. IP-layer communication occurs when packets are routed, or for instance if you ssh directly to a Layer2 switch's management IP.

If you poll ipNetToMediaPhysAddress on a router attached to the Brocade / DLink Layer2 switches, you will see the same dot1qTpFdbPort mac-addresses from the Layer2 switches in that router's ARP table (assuming you did a recent ping sweep of the relevant subnets through the router in question). Also note that if VRRP / HSRP / GLBP are used on the subnet, you should poll ipNetToMediaPhysAddress both FHRP peers, due to potential asymmetric routing.

ARP / Mac Polling Technique

I have to do a lot of polling like this where I map mac addresses / ports found in dot1qTpFdbPort to IP addresses from ipNetToMediaPhysAddress. I always ping sweep (with a tool like nmap... nmap -sP 192.0.2.0/24) through the subnet just before I poll the router / downstream switches with snmp.

[Edit Questions in Comments]

So polling the dot1qTpFdbPort on an L2 switch guarantees that the resulting MAC addresses/ports are the ones directly connected to the L2 switch?

Not quite true... polling dot1qTpFdbPort guarantees that these are the mac addresses learned by the switch, or statically configured on the switch. A few notable exceptions to your statement:

• If you chain Layer2 switches together (including most FHRP topologies), you'll see mac addresses learned from downstream switches. By definition, macs learned from downstream switches are not directly connected. If you have Cisco switces, cdpCacheTable is very useful for untangling relationships between switches.
• Some mac-addresses in dot1qTpFdbPort could be owned by the switch itself, instead of being directly connected to it.
• If you have LACP aggregates in your topology, the vendor might do things like associate mac-addresses with a physical port in that LACP aggregate, instead of learning the mac through the LACP aggregate. Somewhere in the standards I saw discussion about this, but I can't remember where offhand.
• Some switches have vendor-specific features (often they are security features) which completely remove visibility of mac-addresses from dot1qTpFdbPort. YMMV

All the above means you cannot 100% guarantee that the mac returned by dot1qTpFdbPort is directly connected to the switch. If you take care of these kind of issues in your code, then you shouldn't have problems.

PS: I haven't tried ICMP sweep (ping sweep).Is it really necessary to do ping sweep so as to obtain the complete topology of the network?

Ping sweeps mitigate these two issues:

• Switch mac-table aging timers vary, but they can be quite low (i.e. 5 minutes). It's not uncommon to see mismatched router ARP and switch mac table timers in a network. Sometimes the ARP and switch mac tables get out of sync. You stand the best chance of matching switch mac table to router ARP table if you ping sweep just before your polls.
• Some end-points may only receive unidirectional traffic (i.e. a multicast stream). If someone is passively watching or listening to a unidirectional stream, their PC might not refresh the switch mac-address table very often.

This restriction on CIDR was created to forbid that an arbitrary block could be created, let's see an example:

Suppose that we have the full block 192.168.1.0/24 and we want to subnet it with /27

/27 means that from the 32 bits of the address, 27 are network, and 5 are host, then we have 2^5 addresses per subnet.

The subnets are:

First Address    Last Octet  Last Octet 
                             in decimal /32

192.168.1.0      000 00000       0
192.168.1.32     001 00000       1
192.168.1.64     010 00000       2
192.168.1.96     011 00000       3
192.168.1.128    100 00000       4
192.168.1.160    101 00000       5
192.168.1.192    110 00000       6
192.168.1.224    111 00000       7

The first address divided by the number of addresses per subnet is always an integer without decimals, and that is possible because the last k bits are 0.

It makes impossible to have a block starting on 192.168.1.133, for example, because 133/32 = 4.15625