Juniper Fast Track Program

Fast Track Program Details

The Juniper Networks Certification Fast Track program is specifically designed for experienced networking professionals to become certified in Juniper Networks JUNOS software-at substantial savings!

Networking professionals who achieve multiple certifications are in great demand, commanding higher salaries and adding more value to high-end enterprises. Because of this increased need, we are pleased to provide you with this fast tracked way to become JUNOS certified. Normally, these certifications would cost you several thousand dollars, so we encourage you to take advantage of this opportunity now. Access the Juniper Networks Certification Fast Track Program web site for details.

Fast Track Program participants now have quick and easy access to the Juniper Networks Communities, JNet. The J-Net Forum is dedicated to sharing information and best practices, and entertains questions about Juniper products, technologies and solutions. Access http://forums.juniper.net/jnet/ to preview our online forums and message boards by selecting the community of interest.

Linux find the memory used by a program / process

You can find the memory used by a program (process) by looking into /proc directory or using standard command such as ps or top. However, you must calculate all memory usage by hand i.e. add Shared Memory + mapped file + total virtual memory size of the process + Resident Set Size + non-swapped physical memory used by process.

So how do you find the memory used by a process or program under Linux? Use a tool called pmap. It reports the memory map of a process or processes.

pmap examples

To display process mappings, type
$ pmap pid
$ pmap 3724
Output:

3724:   /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
0000000000400000    164K r-x--  /usr/sbin/lighttpd
0000000000629000     12K rw---  /usr/sbin/lighttpd
000000000bb6b000   4240K rw---    [ anon ]
00000035ee600000    104K r-x--  /lib64/ld-2.5.so
00000035ee819000      4K r----  /lib64/ld-2.5.so
00000035ee81a000      4K rw---  /lib64/ld-2.5.so
00000035eea00000   1304K r-x--  /lib64/libc-2.5.so
00000035eeb46000   2048K -----  /lib64/libc-2.5.so
00000035eed46000     16K r----  /lib64/libc-2.5.so
00000035eed4a000      4K rw---  /lib64/libc-2.5.so
00000035eed4b000     20K rw---    [ anon ]
00000035eee00000      8K r-x--  /lib64/libdl-2.5.so
00000035eee02000   2048K -----  /lib64/libdl-2.5.so
.....
....
00002aaaac51e000      4K r----  /lib64/libnss_files-2.5.so
00002aaaac51f000      4K rw---  /lib64/libnss_files-2.5.so
00007fff7143b000     84K rw---    [ stack ]
ffffffffff600000   8192K -----    [ anon ]
 total            75180K

The -x option can be used to provide information about the memory allocation and mapping types per mapping. The amount of resident, non-shared anonymous, and locked memory is shown for each mapping:
pmap -x 3526
Output:

3526:   -bash
Address           Kbytes     RSS    Anon  Locked Mode   Mapping
0000000000400000     700       -       -       - r-x--  bash
00000000006ae000      40       -       -       - rw---  bash
00000000006b8000      20       -       -       - rw---    [ anon ]
00000000008b7000      32       -       -       - rw---  bash
00000000098de000     536       -       -       - rw---    [ anon ]
00000035ee600000     104       -       -       - r-x--  ld-2.5.so
00000035ee819000       4       -       -       - r----  ld-2.5.so
00000035ee81a000       4       -       -       - rw---  ld-2.5.so
00000035eea00000    1304       -       -       - r-x--  libc-2.5.so
00000035eeb46000    2048       -       -       - -----  libc-2.5.so
00000035eed46000      16       -       -       - r----  libc-2.5.so
00000035eed4a000       4       -       -       - rw---  libc-2.5.so
00000035eed4b000      20       -       -       - rw---    [ anon ]
00000035eee00000       8       -       -       - r-x--  libdl-2.5.so
00000035eee02000    2048       -       -       - -----  libdl-2.5.so
00000035ef002000       4       -       -       - r----  libdl-2.5.so
00000035ef003000       4       -       -       - rw---  libdl-2.5.so
00000035ef600000      12       -       -       - r-x--  libtermcap.so.2.0.8
00000035ef603000    2044       -       -       - -----  libtermcap.so.2.0.8
00000035ef802000       4       -       -       - rw---  libtermcap.so.2.0.8
00002aaaaaaab000       4       -       -       - rw---    [ anon ]
00002aaaaaaba000      12       -       -       - rw---    [ anon ]
00002aaaaaabd000      40       -       -       - r-x--  libnss_files-2.5.so
00002aaaaaac7000    2044       -       -       - -----  libnss_files-2.5.so
00002aaaaacc6000       4       -       -       - r----  libnss_files-2.5.so
00002aaaaacc7000       4       -       -       - rw---  libnss_files-2.5.so
00002aaaaacc8000   55112       -       -       - r----  locale-archive
00002aaaae29a000      28       -       -       - r--s-  gconv-modules.cache
00002aaaae2a1000       8       -       -       - rw---    [ anon ]
00007fff9bff4000      92       -       -       - rw---    [ stack ]
ffffffffff600000    8192       -       -       - -----    [ anon ]
----------------  ------  ------  ------  ------
total kB           74496       -       -       -

DNS Caching

All records in DNS have a Time to Live (TTL) value. This value dictates how long a record should be stored locally before a new copy of the record must be retrieved from DNS. The record storage is known as the DNS cache, and the act of storing records is called caching.

There are many different places where DNS caches exist: on your local computer, with your ISP's recursive DNS servers, and even the root servers at the core of the Domain Name System. These caches reduce the number of queries that need to be resolved by nameservers.

Sometimes the information in DNS changes, but the old information is still stored in the DNS caches at varying levels. When the cached record is different from the newest information in DNS, it is called a caching error.

How do I fix a caching error?

Depending on your operating system, there are different methods of clearing your local DNS cache. Removing all of your stored DNS information is known as cache flushing. Please see the following list for instructions on how to flush your DNS cache in most common operating systems. (Before flushing the DNS cache, clear out your web browser's temporary files and close all browser windows.)

Windows

In Windows 98/2000/ME/XP, open a command prompt and type the following to clear the Windows DNS Resolver:

ipconfig /flushdns

Unix

In most *nix operating systems (Unix, Linux, FreeBSD, etc.), type the following to restart the nscd daemon:

/etc/rc.d/init.d/nscd restart

Mac OSX

In Mac OSX, open a command prompt and type the following to clear the DNS resolver cache:

dscacheutil -flushcache

In older versions, the command is:

lookupd -flushcache

Some records are cached by your ISP's recursive DNS servers, which are servers that do the 'legwork' of lookups on behalf of subscribers. If a caching error occurs at this level, clearing your local cache will not solve the issue, as your ISP will keep returning the old, incorrect records to your queries. If this happens, you will need to wait for the records to expire naturally.

Common TTL Values

The default or recommended value for the DNS record types in our Dynamic DNS and Custom DNS services are:

Type	TTL Value (seconds)
A (Host), Super Dynamic	20 (20 seconds)
A (Host), Dynamic	60 (1 minute)
A (Host), Pseudo-Static	600 (10 minutes)
A (Host), Static	14400 (four hours)
A (Host), Static	21600 (six hours)
AAAA (IPv6), Super Dynamic*	20
AAAA (IPv6), Dynamic*	60
AAAA (IPv6), Pseudo-Static*	600
AAAA (IPv6), Static*	14400
AAAA (IPv6), Static*	21600
CNAME	43200 (12 hours)
LOC*	86400 (24 hours)
MX	43200
NS*	86400
PTR*	86400
SRV*	86400
TXT	43200

* indicated record type only available in Custom DNS Expert interface

In the Expert interface, you can modify the TTL value for any record type. If you do change the default TTLs, values lower than 20 have no noticeable impact on propagation time, and TTL values higher than 86400 (twenty four hours) are likewise unnecessary and can lead to problems if the record needs to be changed.

Caching Issues

When a client attempts to access a domain before it exists, a "does not exist" record will be saved. The TTL for these records varies from server to server, but the average TTL is about 2 hours. During this time period, domain name resolution may not be possible.

Why do some records have such high TTLs?

As discussed earlier, the TTL values of records exist to ease the query load on nameservers. Many records, such as MX or CNAME records, are expected to change very rarely, so they are usually given high TTL to prevent unnecessary extra lookups. Other records, such as hosts assigned to dynamic IP addresses, are given very low TTLs, as they are expected to change at a moment's notice. Unnecessarily low TTLs will also slow clients as they will be forced to perform extra DNS queries.

Full reverse (IN-ADDR.ARPA) zones

Reverse DNS records (PTR) are generally served out of a reverse zone. For instance, if you have been assigned the block of addresses 192.168.5/24 (the 256 IP addresses from 192.168.5.0 to 192.168.5.255), the reverse DNS for this zone would be served out of a zone named

    5.168.192.in-addr.arpa

In such a case, you would setup Custom DNS for that zone, selecting the Expert interface option (PTR records can only be added in this interface). Once the zone is created, you'll be able to create PTR entries within this zone for each individual IP address. As an example, to map the IP address 192.168.5.12 to mail.example.com, you would enter:

Host:	12
TTL:	86400
Type:	PTR
Data:	mail.example.com

Note that is you have multiple /24 blocks, you will need a separate zone for each block.

Once you have setup the Custom DNS zone for this block, you need to have the block delegated to us. Contact your ISP (or whomever is assigning this block of addresses to you) and have them create NS records for the zone:

   5.168.192.in-addr.arpa.   86400  IN      NS      ns1.mydyndns.org.
   5.168.192.in-addr.arpa.   86400  IN      NS      ns2.mydyndns.org.
   5.168.192.in-addr.arpa.   86400  IN      NS      ns3.mydyndns.org.
   5.168.192.in-addr.arpa.   86400  IN      NS      ns4.mydyndns.org.
   5.168.192.in-addr.arpa.   86400  IN      NS      ns5.mydyndns.org.

Until that delegation is made, DNS queries for those IP addresses won't come to us, so it is not enough to simply create the zone. You MUST get it delegated to us in order for the DNS to function.

PTR records within a forward zone

In some cases your ISP may not want to create NS records for your allocation, especially if the ISP has assigned a large number of very small blocks to individual customers. In such a case, they can still allow you to control the reverse by using the method discussed in section 5.2 "Alternative naming conventions" of RFC 2317.

Let's say, for example that your ISP has provided you with 4 IP addresses, 192.168.5.27 - 192.168.5.30. Not only is this a very small block, but it doesn't fall on an octet boundary. Thus it is actually not possible to use the above described method.

In such a case, instead of having the ISP create NS records for Classless delegation, you would have them create CNAME records within the 5.168.192.in-addr.arpa zone like this:

   27.5.168.192.in-addr.arpa   86400  IN      CNAME      27.rev.example.com
  28.5.168.192.in-addr.arpa   86400  IN      CNAME      28.rev.example.com
  29.5.168.192.in-addr.arpa   86400  IN      CNAME      29.rev.example.com
  30.5.168.192.in-addr.arpa   86400  IN      CNAME      30.rev.example.com

Then, in the Custom DNS zone for example.com you would create PTR records like this:

Host:	27.rev
TTL:	86400
Type:	PTR
Data:	mail.example.com

Important: Just as with the earlier example, unless your ISP does their part and create the necessary CNAME records, DNS queries to resolve the IP addresses won't come to us and those PTR records will be useless. Not all ISPs are willing to do this, even for customers who have static IP addresses (if you have a dynamic IP address, they almost certainly won't create these for you).

What is Reverse DNS?

Reverse DNS provide mappings from IP addresses to host names. For more info on this, see the Reverse DNS KB article.

Reverse DNS should not be created in Custom DNS. Instead, it is usually best to contact your ISP and request DNS records to be created for your IP. Also, only in rare circumstances is it necessary to delegate individual or few amounts of IP addresses to DynDNS.com.

Cisco Completes Acquisition of Pure Networks

SAN JOSE, Calif. - August 12, 2008 - Cisco today announced that it has completed the purchase of Seattle-based Pure Networks, a leader in home-networking-management software and tools. Pure Networks’ solutions allow users to easily set up and manage a home network and connect a range of devices, applications and services.

The acquisition of Pure Networks provides Cisco with a fully integrated line of home-networking-management solutions that will also serve as the foundation for the development of new multimedia-enabled applications, tools and capabilities for consumers to use in an increasingly “connected life” at home, at work and on the go. The acquisition further advances Cisco’s consumer strategy by enhancing the development of the existing Linksys® Easy Link Advisor (LELA) platform, which enables a consumer to more easily set up, organize, manage, secure and use a home network.

With the close of the transaction, Pure Networks will be integrated into Linksys, a division of Cisco.

For more information, visit: http://newsroom.cisco.com/dlls/2008/corp_081208.html

Cisco’s Acquisition Summary: http://www.cisco.com/web/about/ac49/ac0/ac1/about_cisco_acquisition_years_list.html