Dynamic NAT-PT Configuration

Dynamic NAT-PT is a Cisco method to implement NAT-PT.
This configuration guide is a part of our ongoing CCIE Study Guide Series.

Please click on the images, to get a larger view.

Also checkout our study notes on configuring Static NAT-PT.


We wish to come up with more of configurations and study notes. Meanwhile, please checkout the earlier editions of our CCIE study notes.

• EIGRP
• OSPF
• IPV 6
• BGP

First RHCSA & RHCE 6 exams at IPSR

The very first RHCSA & RHCE 6 exams (EX 200 & RH 302) at IPSR were conducted at IPSR North (Edappally), on 28^th March 2011.
The results are not much different. It is again a 100% pass. Every candidate who appeared for the RHCSA and RHCE have passed with good scores.

The student community seems to be slightly hesitant over wetting their legs in the new RHEL 6 waters. But we have always been positive about the new changes and our faculty were trained in RHEL 6 during December 2010 itself. Some of faculty team members had also certified themselves as RHCE in RHEL 6.

Following are the students who were certified as RHCSA

1. Mahesh.S
2. Sreejith.G.Pillai
3. Anu Prem
4. Abdul Raheem Chalil
5. Kurian Mathew Thayil
6. Sreekumar.K.R
7. Jayamohan.G

Since pass in EX 200 (RHCSA) is not a must for appearing in RH 302 (RHCE), most of the above students appeared for RHCE and it again was a 100% pass. (But pass in RHCSA is a must for obtaining the RHCE certification. Please check out our RHEL6 FAQs)
Following students were certified as RHCE

1. Mahesh.S
2. Sreejith.G.Pillai
3. Anu Prem
4. Abdul Raheem Chalil
5. Kurian Mathew Thayil

We wish them all success in their careers.
 

Static NAT-PT Configuration

Static NAT-PT is one among the 4 ways to implement Cisco NAT-PT.
We are bringing this configuration guide to you, as part of our ongoing CCIE Study Guide Series.

Please click on the images, to get a larger view.

While we are working on the configuration of Dynamic NAT-PT, please checkout the earlier editions of our CCIE study notes.

• EIGRP
• OSPF
• IPV 6
• BGP

31st RHCSS Batch Commencing

IPSR Kochi North (Edappally) shall be hosting the 31^st RHCSS batch, from 4^th April 2011. The batch commences with RH 423, followed by RHS 429 and RHS 333 modules. Each module shall be followed by the certification exams EX 423, EX 429 and EX 333. Details are available on the RHCSS Course Schedule page.

This batch has students from various parts of 'Incredible India'. From Pune, Maharashtra, which is also called Punya-Nagari, and has close relationship to Chhatrapati Shivaji, Nikhil Shinde and Amol Arun Mustare are participating. Amol Arun Mustare was previously a System Engineer at 3i infotech, Pune and was a student in our second RHCE 6 Boot Camp.

Jyothi Ranjan Nanda is from Bhubaneswar, a Temple City of India and the capital city of Odisha (Orissa). Mr. Nanda has been doing RHCVA at our Trivandrum Branch and was also student in our second RHCE 6 Boot Camp.

Antony Pradeep is coming down from Bengaluru (Banglore, Karnataka) the Garden City and Silicon Valley of India. Vinay Mishra is from Kanpur (Uttar Pradesh), one of the oldest industrial township in India.

We wish the very best to all participants and keenly await our 40^th Red Hat Security Specialist.

RHCSA/RHCE Exam Offer: Hop, Step or Jump

Red Hat has already launched RHEL 6 and IPSR was an early starter to offer RHCE on RHEL 6. We have even prepared the RHEL 6 FAQs page, to help you with the nuances related to RHEL 6 Certifications.

With every change comes hesitation and to ease you with certifications on the RHEL 6 platform, we are happy to announce the 'hop, step or jump' scheme offered by Red Hat. This is a special exam offer for RHCSA & RHCE (RHEL 6.0), which comes with 2 options.

'RHCSA + RHCE' @ Rs.16,000 with free second attempt on RHCSA *

 OR

RHCSA at Rs.10,000 with free second attempt *

* Terms and Conditions

1. This scheme is applicable only for candidates who have undergone training on the official curriculum of Red Hat (RHEL 5 or 6)
2. This scheme is applicable only for candidates who register for RHCSA or RHCE exam between Mar 25, 2011 & May 20, 2011.
3. The last date to register for the exam is May 20, 2011.
4. The last date to appear for any attempt (including all re-attempts) of the exam is May 25, 2011

The fee and offer are as followed:

Particulars	Exam Fee	Offer
RHCSA + RHCE	Rs. 16000	Free 2nd attempt on RHCSA
Only RHCSA	Rs. 10000	Free 2nd attempt on RHCSA

For more details on this offer, please get in touch with us.

NAT-PT - CCIE Study Guide

We are starting another phase of our CCIE Study Guide Series, with some documentation and configuration instructions on NAT-PT.

NAT-PT stands for "Network Address Translation - Protocol Translation" it is an IPv6-IPv4 translation mechanism, which was designed (created) to allow IPv6-only devices communicate with IPv4-only devices and vice versa.

Cisco's basic operation of the NAT-PT consists of three items:

• The IPv6 only device (node) that is located on a IPv6 only network
• The IPv4 only device (node) that is located on a IPv4 only network
• And, the Cisco NAT-PT router that is located in between both network only devices and is doing the protocol translating.

NAT-PT is mainly used by organizations (companies) as a short-term fix; until they are completely ready to migrate to IPv6.

The best advantage of using Cisco's version of NAT-PT is that only the Cisco NAT-PT router needs to configured; the IPv4 and IPv6 network only devices involved are totally clueless that NAT-PT is happening between them. Cisco recommends that you never allow a Cisco NAT-PT router perform NAT-PT between Dual Stack devices.

The major downfall of using Cisco's version of NAT-PT is that you have a single point of failure, the Cisco NAT-PT router itself. This is why Cisco recommends that the NAT-PT solution only be used for a short amount of time, until a long term solution can be achieved.

Currently, Cisco NAT-PT can be implemented in four ways:

1. Static NAT-PT
2. Dynamic NAT-PT
3. Port Address Translation (PAT) a.k.a. Overload
4. IPv4-Mapped Operation

While we prepare some detailed configuration instructions on the above methods, please do not forget to checkout the earlier study notes that we have prepared for CCIE.

• EIGRP
• OSPF
• IPV 6
• BGP

CCNP & MCITP starts at Trivandrum Branch

The recently started Thiruvananthapuram branch of IPSR is having great success. We had already conducted RHCE, RHCVA and CCNA batches at Trivandrum, during the previous months.

This week, the first CCNP (Cisco Certified Network Professional) & MCITP (Microsoft Certifications for IT Professionals) batches are also starting. Mr. Aneesh PV is handling the CCNP batch and Mr. Gain Swaroop is handling the MCITP batch.

Best wishes to the students and faculty!

CCIE Study Guide: BGP Notes

This is the fourth part of our CCIE Study Guide Series and provides useful notes about BGP.

1. BGP uses TCP port 179 for transport. Router with the higher BGP router-id initiates BGP session from a random port.
2. The interface from which the BGP router ID is taken does not have to be running BGP. Any valid IP address can be used as BGP router-id, even an address that is not locally configured on the router.
3. The BGP router-id must be the same as the OSPF router-id for redistributing the routes from OSPF to BGP or vice versa.
4. If the ‘network …‘ command is configured with the ‘mask’ option under the BGP process, then an exact match (network/mask) must exist in the IP routing table in order to advertise this route into BGP regardless of ‘auto-summary‘ / ‘no auto-summary‘ command. But the ‘network …‘ command configured without the ‘mask’ assumes the default classful mask and if ‘auto-summary‘ is configured then BGP will advertise a classful network only if any subnets of the classful network exist in the IP routing table. Again if the ‘network …‘ command is configured without the ‘mask’ option and if ‘no auto-summary‘ is configured, then that router must have the exact classful network in the IP routing table in order to advertise it in BGP.
5. To accept and attempt BGP connections to the external peers residing on networks that are not directly connected, we need to use either ‘neighbor ebgp-multihop …‘ or ‘neighbor ttl-security …‘ command. These two commands are mutually exclusive. We can use another command ‘neighbor disable-connected-check‘ to accomplish the same task if the BGP neighbor is one-hop away.
6. The synchronization rule states that an iBGP learned prefix cannot be considered best unless there is a matching IGP route for that BGP prefix. BGP only advertises what it considers the best path. This issue can be resolved by
   
   • redistributing BGP routes into the IGP
   • creating a full-mesh of IBGP routers and disabling the synchronization, or
   • creating a GRE tunnel. 
   When BGP is synchronizing with OSPF, the router ID must match in both protocols in order to make it work.
   
7. When a prefix is received from an eBGP neighbor, it is advertised to both eBGP & iBGP neighbors. When a prefix is received from an iBGP neighbor, it is advertised ONLY to eBGP neighbors and not to any iBGP neighbors. To advertise iBGP leaned routes to other iBGP peers requires the use of route-reflectors or confederations or a full-mesh of iBGP peers.
8. While sending BGP updates, EBGP peers modify the next-hop value to its own IP address. But iBGP peers do not modify it.
9. The ‘default-information originate’ command, however, requires explicit redistribution of the route 0.0.0.0. .
   Default routes can be injected into BGP in one of three ways:
   
   • using the ‘network …‘ command (default route must exist in the local routing table),
   • using the ‘default-information originate‘ command (a redistribution statement must also be configured to redistribute the default route from the local routing table to the BGP table), and
   • using the ‘neighbor … default-originate [route-map route-map-name]‘ command (this method does not even check for the existence of a default route in the IP routing table).
   The ‘default-information originate‘ command should not be configured with the ‘neighbor … default-originate‘ command on the same router.
   
10. ‘weight’ and ‘local-preference’ are set inbound and they affect outbound traffic. But ‘as-path’ and ‘med’ are set outbound and they affect inbound traffic.
11. The weights assigned with the ‘set weight …’ route-map command overrides the weights assigned using the ‘neighbor… weight …‘ command.
12. Origin code ‘i’ is default on the BGP routes advertised by ‘network …‘, ‘aggregate-address …‘ (if all subnet has ‘i’), and ‘neighbor … default-originate‘ commands. And origin code ‘?’ is default on the BGP routes advertised by ‘redistribute …‘, ‘aggregate-address …‘ (if any single subnet has ‘?’, but can be changed using ‘attribute-map’ option), ‘default-information originate‘, and ‘bgp inject-map …‘ commands.
    
13. When BGP originates a route with the ‘network …’ command, MED is copied from the metric of the original route.
14. BGP MED values are not passed beyond the receiving (neighbor) AS.
15. Enabling the ‘bgp deterministic-med’ command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the ‘bgp always-compare-med’ command ensures the comparison of the MED for paths from neighbors in different autonomous systems.
16. The default behavior of BGP routers that run Cisco IOS software is to treat routes without the MED attribute as having a MED of 0, making the route that lacks the MED variable the most preferred. The ‘bgp bestpath med missing-as-worst‘ command can be configured to treat the route that missing MED as the least preferred one.
17. 'bgp bestpath as-path ignore' is a hidden command in Cisco IOS which allows BGP to not consider the AS path during best path route selection.
18. There are two ways to create an aggregate address under BGP. The first is to create a static route to null interface in the routing table for the aggregate address and then advertise it with the 'network …' command. The second way is to use the 'aggregate-address …' command.
19. By default when aggregation is configured in BGP, the 'atomic-aggregate' attribute is attached to the aggregate address if the 'as-set' argument is not used in the 'aggregate-address …' command. The 'as-set' argument reveals the AS numbers which can prevent a routing loop, and once 'as-set' is configured along with the 'aggregate-address …' command, the 'atomic-aggregate' attribute is automatically removed.
20. A router reflector and its clients are known collectively as a cluster. If the cluster contains a single route reflector, the cluster ID is the router ID of the route reflector. If the cluster contains multiple route reflectors, each RR must be manually configured with a cluster ID.
21. A client router in a route reflection cluster can peer with external neighbors, but the only internal neighbor it can peer with is a route reflector in its cluster or other clients in the cluster. Clients cannot peer with routers outside of their own cluster. However, the RR itself can peer with both internal and external neighbors outside of the cluster and can reflect their routes to its clients.
22. In case of route reflection, (1) routes from EBGP are advertised to EBGP, client, non-client (2) routes from client are advertised to EBGP, client, non-client (3) routes from non-client are advertised to EBGP, client.
23. When the 'no bgp client-to-client reflection' command is configured the RR does not reflect routes from one client to another. It does, however, continue to reflect routes from clients to peers outside of the cluster, and from peers outside of the cluster to clients.
24. Standard and extended BGP communities are removed from the reflected routes unless the 'neighbor … send-community [both]' is configured on the route reflector. The link bandwidth community is removed from reflected route if the route-reflector performs IBGP multipath load-sharing for that route.
25. The “neighbor … nexthop-self” on router reflectors only affects the next hop of eBGP learned routes because the next hop of reflected routes should not be changed. To avoid a common configuration error for reflected routes, the “set ip next-hop” command should not be used in a route map to BGP route reflector clients. 
26. Unlike route reflector environments in which only the route reflector itself has to support route reflection, all routers within a confederation must support the confederation functionality.
27. EBGP routes external to the confederation are preferred over EBGP routes to member autonomous systems, which are preferred over iBGP routes.
28. AS_PATH types are AS_SEQUENCE, AS_CONFED_SEQUENCE, AS_SET, and AS_CONFED_SET. AS_SEQUENCE is an ordered set of AS numbers, and AS_SET is an unordered set of AS numbers. AS_CONFED_SEQUENCE and AS_CONFED_SET are the same as AS_SEQUENCE and AS_SET but are used only within BGP confederations.
29. When 'bgp bestpath med confed' command is configured, the router picks the confederation-internal path with the lowest MED and ignores the path with the external AS number.
30. BGP private autonomous system numbers are from 64,512 to 65,535
31. BGP prefixes can be filtered using
    
    1. 'distribute-list',
    2. 'prefix-list',
    3. 'filter-list',
    4. 'policy-list',
    5. community/extended community lists,
    6. 'route-map'
32. For BGP, the 'distance …' command sets the administrative distance of the External BGP (eBGP) route. This command only affects the routing table and not the BGP table.
33. The 'network … backdoor' command has the same effect as the 'network …' command. The EBGP route is treated as a local BGP route, and the administrative distance is changed to 200. The difference is that the address specified by the network backdoor command is not advertised to EBGP peers.
34. iBGP routes are not redistributed into an IGP unless you use "bgp redistribute-internal" command under BGP routing process.
35. 'bgp inject-map … exist-map …' command injects prefixes in the local BGP RIB when a valid parent route exists. Only prefixes that are equal to or more specific than the aggregate route (existing prefix) can be injected. exist-map (route-map) must contain a 'match ip address prefix-list …' command statement to specify the aggregate prefix and a 'match ip route-source prefix-list …' command statement to specify the route source. If the parent route is a default route, we can inject any route out of it.
36. A BGP neighbor cannot be configured to work with both peer groups and peer templates. BGP peer templates and BGP peer groups are mutually exclusive.
37. Peer session template can inherit only one session template directly, but peer policy template can inherit multiple policy templates.
38. When the maximum number (as set by the 'neighbor … maximum-prefix …' command) of prefixes are reached, the string "PfxRcd" appears in the entry, the neighbor goes to shutdown  state, and the connection becomes idle.
39. No penalty is applied to a BGP peer reset when route dampening is enabled. Although the reset withdraws the route, no penalty is applied in this instance.
40. In case of iBGP multipath load sharing, when multiple iBGP paths installed in a routing table, a route reflector will advertise only one of the paths (one next hop).
41. For multiple paths to the same destination to be considered as multipaths, all attributes including weight, local preference, autonomous system path (entire attribute and not just length), origin code, MED, and IGP distance must be same. But if 'bgp bestpath as-path multipath-relax' command is configured, the AS paths still have to be the same length, but don't have to be identical.
42. Though BGP Multipath allows the installation of multiple BGP paths (for load sharing purpose) into the IP routing table for the same prefix, it does not affect the bestpath selection. A router still designates one of the paths as the best path and advertises this best path to its neighbors.
43. 'neighbor … dmzlink-bw' command can be used with eBGP and iBGP multipath features to enable unequal cost load balancing over multiple links. BGP can originate the link bandwidth community only for directly connected links to eBGP neighbors.
44. The 'bgp update-delay …' command is used to tune the maximum time the software will wait after the first neighbor is established until it starts calculating best paths and sending out advertisements.
45. The "neighbor … local-as …" command is valid only if the peer is a true eBGP peer. It does not work for two peers in different sub-ASs in a confederation.
46. In a route-map, a continue clause can be executed, without a successful match, if a route map entry does not contain a match clause. But if a match clause exists, the continue clause is executed only if a match occurs. If no successful matches occur, the continue clause is ignored. The continue statement proceeds to the specified route map entry only after configured set actions (if any) are performed.
47. When multiple values are configured in the same community list statement, a logical AND condition is created. All community values must match to satisfy an AND condition. When multiple values are configured in separate community list statements, a logical OR condition is created. The first list that matches a condition is processed.
48. While redistributing OSPF into BGP, by default only OSPF intra-area and inter-area routes are redistributed into BGP.
49. When a BGP router with synchronization enabled has also a OSPF route (redistributed from BGP) for a iBGP-learned route, then the OSPF ASBR router-id must match the originating BGP router-id in order to synchronize BGP route with OSPF route.
50. An "update group" is a group of peers with a common outbound policy which will be converged as if they are in a peer-group.

Previous posts in our CCIE Study Guide Series are:

• EIGRP
• OSPF
• IPV 6

Testimonials from our recent Red Hat Security Specialists

The last week saw IPSR producing 3 more Security Specialists certified by Red Hat. We were happy to see them achieve the crowns and they were also really happy to be at IPSR.

Chetan Singh, our 37th RHCSS, is from Rewa, Mdadhya Pradesh and he is just doing his B Com graduation through correspondence. This is no small feat, because even professionals look at Red Hat Certifications with some scare, since it is a practice based exam in the presence of an examiner. But IPSR has even produced the youngest RHCSS in the world and we have always known that genuine Linux enthusiasts, come out the victors.

Chetan is ecstatic but short in his words:

It is really India's No.1 institute. I am very happy to complete my RHCSS.

Renjith Raju, our 38th RHCSS, is a native of Kottarakkara in Kerala. He is an electronics diploma holder. He is very thankful to IPSR and lauds the training.

It was a very good traning experience from IPSR; lab infrastructure is truly excellent; and faculties are helped a lot for the training sessions. They are very co-operative. It was my pleasure to study @ IPSR. Mymy heartful thanks to all my friends and Benila madam also...

Himesh Madhusoodanan, our 39th RHCSS, is a native of Trivandrum, Kerala. He was working in Spectrum Softech Solutions, Cochin and had resigned his job with higher certification plans. He also does not mince his words, while commenting about IPSR.

The training for RHCSS has been splendid, the faculty very cooperative. The state of the art lab best suited for red hat status, has all helped me to achieve the mile stone of RHCSS. All Thanks to team IPSR, keep up the good work.

Dear friends, thanks for your words. You inspire us to outperform ourselves.

EX429 - RHCSS Results: 11th March 2011

We are elated with the results of the recent EX429 exam (SE Linux Policy Administration Expertise Exam) held on 11th March 2011 at our Kochi North branch at Edappally. 3 students from our 25th batch of RHS 429 and one student from a previous batch came out with flying colours.

Mr.Himesh Madhusudhanan made a 100% score to become the 39th RHCSS from IPSR.

Mr. Kurian Mathew Thayil also made a 100% score. Mr. Ritesh Kumar (Asst. Director -Systems, Petroleum Federation of India, Delhi) and Roshith L S (Desktop Support Engineer, Focus MT India Pvt ltd, Bangalore) also cleared EX429 with high scores. This also makes our RHCSS module-wise passes to 170.

Congratulations to all those cleared the exam and we await the 40th RHCSS.

Second RHCE 6 Boot Camp commencing

We are happy to announce that the second RHCE 6 Boot Camp shall be starting at IPSR, Edappally from 14^th March 2011. There are 5 participants for this RHEL 6 Training.

• Sreekumar K R, Unix admin at IBM, Banglore
• Jyothi Ranjan Nanda, from Bhubaneswar, who is also doing RHCVA at our Trivandrum Branch
• Abdul Raheem Challil, Software Support, Leylaty Ballrooms, Saudi Arabia
• Amol Arun Mustare, Previously System Engineer at 3i infotech, Pune
• Sushil Parmar from Mumbai, who is a Working Engineer - Server Manangement, at Wipro Infotech Ltd

We welcome you onboard and wish you a great training.

EX333 - RHCSS Results: 8th March 2011

We are excited to announce that IPSR has produced two more RHCSS, with the EX333  exam (Security: Network Services Exam) held on 8th March 2011 at IPSR, Edappally.

Chetan Singh from Madhya Pradesh and Renjith Raju from Kerala completed all three of their Security Specialist modules, to claim the coveted RHCSS certification.

This raises the RHCSS count from IPSR to 38. We have 166 module passes relevant for RHCSS and we expect more certifications soon.

On 8th March 2011, Himesh Madhusudhanan and Ritesh Kumar also cleared the EX333  exam.

We congratulate each of them and wish all the very best for their careers.

RHCE Results Roundup: February 2011

IPSR has had yet another eventful month of certifications. While we had covered individual batches of higher certifications, we thought it would be an overkill, to feature each of the RHCE batches. So here is a monthly roundup of our RHCE certifications.

We had RHCE exams on 14 days in February 2011, at various branches of IPSR.

We are really happy about our all new Thiruvananthapuram Branch starting off with 2 RHCE Batches. Another important achievement is about RHCE training in RHEL 6 starting across all branches of IPSR. We had already been offering a dual platform training, with RHEL 5 training and the required additional inputs for RHEL 6, but now completely switched over to RHEL 6.

We had a total number of 93 RHCEs during this month, with 28 of them scoring 100%. We also had another 13 students certifying RHCT, in the final month of this certification, as Red Hat stopped offering RHEL 5 based certifications, by 25^th February 2011. RHCT is being replaced by RHCSA in the RHEL 6 platform. Also, check out the RHEL 6 FAQs, that we have prepared, to clarify students’ doubts about certifications in the new platform.

Among the smaller milestones, the total number of RHCEs from IPSR has crossed 3500 and we completed our 580^th  RHCE batch during the last month.

Altogether, we had 100-plus Red Hat certifications this month, with more than 25% of them achieving 100% scores. And in the short month of February, a Red Hat examiner was present at IPSR every other day. While we are proud, this is just the right quality and opportunity that we provide our students. We provide the best Red Hat training in the world, that can even get you the full score. We frequently have exams for basic and higher certifications and our exam dates are rarely canceled.

We would be happy to welcome you to IPSR and we are confident that you would be happy that you found us.
 

RHCE at Trivandrum – the IPSR saga continues

It has just been about 2 months, since we started operations at Thiruvananthapuram, the capital city of Kerala. We are overwhelmed by the great response that we are receiving, from students, professionals and corporates at Trivandrum, which is also the first IT hub of Kerala.

We have already had 2 batches under RHEL 5 and the third batch of RHCE in RHEL 6 is underway. The Trivandrum branch has produced 22 RHCEs, with 7 of them scoring 100%. On top of this, we have also conducted multiple batches of RHCVA, the coveted certification in Enterprise Linux Virtualization, which could be of great demand in the near future.

While we thank our well wishers and congratulate our students & team members, we pledge to strive hard and provide the quality of training in all our divisions.

RHEL 6 Training Commences at IPSR

By 25th February 2011, Red Hat has officially stopped offering exams on the RHEL 5 platform. Now on, students shall be able to appear for exams only under RHEL 6.

At IPSR, we were already equipped for RHEL 6 Certifications and the first RHCE batch under RHEL 6 shall begin at our Kochi branch, on 3rd March, 2011. Kottayam, Thiruvananthapuram and Kozhikkode branches are following suit, with RHEL 6 based RHCE batches in the upcoming weeks.

The RHCE curriculum under RHEL 6 consists of three modules:

• RH124 - Red Hat System Administration I
• RH134 - Red Hat System Administration II
• RH254 - Red Hat System Administration III

A team from IPSR had attended the faculty training camp on RHEL 6, organised by Red Hat India in Bangalore, during December 2010, and few of our faculty members have already been certified as RHCEs under RHEL 6.

For more information about our upcoming RHEL 6 Training & Certification programmes, please visit our course schedule pages and exam schedule pages.

Also check out our FAQs about certifying in and upgrading to RHEL 6.