First of all, let’s take a look at the testbed network we can use for this situation.

In this scenario, routers R2 and R5 represent the two ISPs. Routers R6 and R9 represent our internal network, with two subnets we need to route differently represented by Loopback interfaces Loopback9 (9.9.9.0/24 subnet) and Loopback99 (from a 99.99.99.0/24 subnet) on R9. Router R4 represents a host “somewhere” on the Internet we’ll be using for testing. We’ll pretend to have no access to change any configurations on Internet routers, so only routers R6 and R9 are available to us. Let’s see the initial configurations and clarify few things there.

Initial Network Configuration

R2:

interface GigabitEthernet0/0
 ip address 172.16.24.2 255.255.255.0
!
interface GigabitEthernet0/1
 ip address 172.16.26.2 255.255.255.0
!
router bgp 65002
 neighbor 172.16.24.4 remote-as 65004
 neighbor 172.16.26.6 remote-as 65069
 address-family ipv4
  neighbor 172.16.24.4 activate
  neighbor 172.16.24.4 send-community
  neighbor 172.16.26.6 activate
  neighbor 172.16.26.6 send-community
!

Router R4 is a dual-homed, just like our AS is. We’re using a simple configuration to prevent transit. We will apply a very similar configuration in our AS later.

R4:

interface Loopback4
 ip address 10.0.0.4 255.255.255.255
!
interface FastEthernet0/0
 ip address 172.16.24.4 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.45.4 255.255.255.0
!
router bgp 65004
 neighbor 172.16.24.2 remote-as 65002
 neighbor 172.16.45.5 remote-as 65005
 address-family ipv4
  neighbor 172.16.24.2 activate
  neighbor 172.16.24.2 send-community
  neighbor 172.16.24.2 route-map NO-TRANSIT in
  neighbor 172.16.45.5 activate
  neighbor 172.16.45.5 send-community
  neighbor 172.16.45.5 route-map NO-TRANSIT in
  network 10.0.0.4 mask 255.255.255.255
!
route-map NO-TRANSIT permit 10
 set community no-advertise
!

R5:

interface FastEthernet0/0
 ip address 172.16.56.5 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.45.5 255.255.255.0
!
router bgp 65005
 neighbor 172.16.45.4 remote-as 65004
 neighbor 172.16.56.6 remote-as 65069
 address-family ipv4
  neighbor 172.16.45.4 activate
  neighbor 172.16.45.4 send-community
  neighbor 172.16.56.6 activate
  neighbor 172.16.56.6 send-community
!

Similarly to the configuration on R4, we need to prevent the transit between our ISPs. However, we can’t use the “no-advertise” community here, since we need to advertise the received route(s) to R9. This is easily fixed using “no-export” community instead.

R6:

interface FastEthernet0/0
 ip address 172.16.56.6 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.26.6 255.255.255.0
!
interface Serial0/2/0
 ip address 192.168.69.6 255.255.255.0
!
router bgp 65069
 neighbor 172.16.26.2 remote-as 65002
 neighbor 172.16.56.5 remote-as 65005
 neighbor 192.168.69.9 remote-as 65069
 address-family ipv4
  neighbor 172.16.26.2 activate
  neighbor 172.16.26.2 send-community
  neighbor 172.16.26.2 route-map NO-TRANSIT in
  neighbor 172.16.56.5 activate
  neighbor 172.16.56.5 send-community
  neighbor 172.16.56.5 route-map NO-TRANSIT in
  neighbor 192.168.69.9 activate
  neighbor 192.168.69.9 send-community
  neighbor 192.168.69.9 next-hop-self
!
route-map NO-TRANSIT permit 10
 set community no-export
!

R9:

interface Loopback9
 ip address 9.9.9.9 255.255.255.255
!
interface Loopback99
 ip address 99.99.99.99 255.255.255.255
!
interface Serial0/2/0
 ip address 192.168.69.9 255.255.255.0
!
router bgp 65069
 neighbor 192.168.69.6 remote-as 65069
 address-family ipv4
  neighbor 192.168.69.6 activate
  neighbor 192.168.69.6 send-community
  network 9.9.9.0 mask 255.255.255.0
  network 99.99.99.0 mask 255.255.255.0
!

At this point, router R9 should be able to reach Loopback4 interface advertised by R4 from its Loopback9 and Loopback99 interfaces. Let’s give it a go.

R9:

R9#ping 10.0.0.4 source Loopback9

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
Packet sent with a source address of 9.9.9.9
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R9#ping 10.0.0.4 source Loopback99

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
Packet sent with a source address of 99.99.99.99
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

This works as expected. Now, lets’ work on our “traffic engineering”.

Chosing Different Paths from R9

Let’s say that our goal is to make the traffic between 9.9.9.0/24 and 10.0.0.0/24 take the path R9->R6->R2->R4, while the traffic between 99.99.99.0/24 needs to take the R9->R6->R5->R4 path. We can easily fix this issue using a simple policy-based routing (PBR) configuration on R6.

All we need is to match the source of traffic when it enters R6 from R9 and force it down the specific path. For example, a policy like this may do the trick.

ip access-list standard Network-9
 permit 9.9.9.0 0.0.0.255
!
ip access-list standard Network-99
 permit 99.99.99.0 0.0.0.255
!
route-map Force-Path permit 10
 match ip address Network-9
 set ip next-hop 172.16.26.2
!
route-map Force-Path permit 20
 match ip address Network-99
 set ip next-hop 172.16.56.5
!
interface Serial0/2/0
 ip policy route-map Force-Path
!

We could apply this policy and be done with it. However, there are couple of problems with this. What if the next-hop is not reachable? For example, the remote router crashes, the switch between R6 and R2/R5 drops the packets, etc? We would be black-holing the traffic. This is not a good thing in any kind of a production environment. Is there a way to solve this? As it turns out, there is. We can actually monitor the exit interface, next-hop route, as well as the next-hop itself, using object tracking. We can then have a conditional policy that will be taken into account only when all of these parameters are in place and operational. So, the policy I’m going to apply is a little bit more involved:

R6:

ip access-list standard Network-9
 permit 9.9.9.0 0.0.0.255
!
ip access-list standard Network-99
 permit 99.99.99.0 0.0.0.255
!
track 2 list boolean and
 object 21
 object 22
 object 23
!
track 5 list boolean and
 object 51
 object 52
 object 53
!
track 21 interface FastEthernet0/1 ip routing
track 22 ip route 172.16.26.0 255.255.255.0 reachability
track 23 ip sla 2
track 51 interface FastEthernet0/0 ip routing
track 52 ip route 172.16.56.0 255.255.255.0 reachability
track 53 ip sla 2
!
ip sla 2
 icmp-echo 172.16.26.2 source-ip 172.16.26.6
ip sla schedule 2 life forever start-time now
!
ip sla 5
 icmp-echo 172.16.56.5 source-ip 172.16.56.6
ip sla schedule 5 life forever start-time now
!
route-map Force-Path permit 10
 match ip address Network-9
 set ip next-hop verify-availability 172.16.26.2 10 track 2
!
route-map Force-Path permit 20
 match ip address Network-99
 set ip next-hop verify-availability 172.16.56.5 10 track 5
!
interface Serial0/2/0
 ip policy route-map Force-Path
!

That’s a lot to handle in one go. Let’s break it down a little bit. First off, I start by defining track lists. Track lists are simply multiple tracking objects that will be compared using a single boolean logic. In this case, I have three sub-objects I’m tracking and I’m combining them using “and” logic. In plain English, this means the track list will be “up” if all monitored sub-objects are “up”. The three objects are exit interface’s routing status, next-hop route and the next-hop reachability, which we monitor using IP SLA ICMP-Echo (ping) probe. Finally, it all comes together in a route-map, which uses “verify-availability” keyword to track the next-hop. Let’s see if it all works.

R6:

R6#show track 2
Track 2
  List boolean and
  Boolean AND is Up
    2 changes, last change 00:03:34
    object 21 Up
    object 22 Up
    object 23 Up
  Tracked by:
    ROUTE-MAP 0

R6#show track 5
Track 5
  List boolean and
  Boolean AND is Up
    2 changes, last change 00:03:36
    object 51 Up
    object 52 Up
    object 53 Up
  Tracked by:
    ROUTE-MAP 0

R6#show ip policy
Interface      Route map
Serial0/2/0    Force-Path

R9:

R9#traceroute 10.0.0.4 source Loopback9 

Type escape sequence to abort.
Tracing the route to 10.0.0.4

  1 192.168.69.6 0 msec 4 msec 0 msec
  2 172.16.26.2 4 msec 0 msec 0 msec
  3 172.16.24.4 4 msec *  0 msec

R9#traceroute 10.0.0.4 source Loopback99

Type escape sequence to abort.
Tracing the route to 10.0.0.4

  1 192.168.69.6 4 msec 0 msec 0 msec
  2 172.16.56.5 4 msec 0 msec 4 msec
  3 172.16.45.4 0 msec *  0 msec

This seems to be working, as we expected. What about the return traffic?

R4:

R4#traceroute 9.9.9.9 source Loopback4

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 0 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec
R4#traceroute 99.99.99.99 source Loopback4

Type escape sequence to abort.
Tracing the route to 99.99.99.99

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 4 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec

We can clearly see that R4 is preferring the path R4->R2->R6-?R9 for both destinations. This means that the traffic between 10.0.0.0/24 and 99.99.99.0/24 networks is taking the asymmetric route, which was one of the things we needed to avoid. Let’s handle that part now.

Chosing Different Paths from R4

Let’s not be misguided by the subtitle. Remember that R4 is just another Internet host. We can’t modify any configuration on it, yet we need to influence the decisions it makes.

Possibly the simplest solution in this case would be to take the 9.9.9.0/24 network and prepend our AS when advertising it to R5 and do the same for 99.99.99.0/24 when advertising to R2. In the lab environment, this works like a charm. In real life, all our prepending can be easily overridden with a higher local preference or a similar thing. We can only hint our preference for the incoming traffic – we cannot decide it. It would also be a very simple thing to do. I don’t like simple things, so let’s complicate our solution a little bit.

There is one thing in IP routing that trumps all weights, local preferences and as-paths of this world. It’s a rule that “more specific route always wins”. How about we use that solution for our return traffic? Let’s inject 9.9.9.0/25 and 9.9.9.128/25 towards R2, and 99.99.99.0/25 and 99.99.99.128/25 towards R5. That way, R2 will advertise more specific 9.0.0.0/24 subnets and R5 will do the same for 99.0.0.0/24. To prevent black-holing, we’ll keep advertising both original /24 routes to both R2 and R5. Let’s take a look at that solution.

R6:

ip prefix-list Network-Inject-9 seq 10 permit 9.9.9.0/25
ip prefix-list Network-Inject-9 seq 20 permit 9.9.9.128/25
!
ip prefix-list Network-Inject-99 seq 10 permit 99.99.99.0/25
ip prefix-list Network-Inject-99 seq 20 permit 99.99.99.128/25
!
ip prefix-list Network-Match-9 seq 10 permit 9.9.9.0/24
!
ip prefix-list Network-Match-99 seq 10 permit 99.99.99.0/24
!
ip prefix-list R9 seq 5 permit 192.168.69.9/32
!
route-map Inject permit 10
 set ip address prefix-list Network-Inject-9
!
route-map Inject permit 20
 set ip address prefix-list Network-Inject-99
!
route-map Match permit 10
 match ip address prefix-list Network-Match-9
 match ip route-source prefix-list R9
!
route-map Match permit 20
 match ip address prefix-list Network-Match-99
 match ip route-source prefix-list R9
!
route-map Filter-Specific-R2 deny 10
 match ip address prefix-list Network-Inject-99
!
route-map Filter-Specific-R2 permit 20
!
route-map Filter-Specific-R5 deny 10
 match ip address prefix-list Network-Inject-9
!
route-map Filter-Specific-R5 permit 20
!
router bgp 65069
 address-family ipv4
  bgp inject-map Inject exist-map Match copy-attributes
  neighbor 172.16.26.2 route-map Filter-Specific-R2 out
  neighbor 172.16.56.5 route-map Filter-Specific-R5 out
!

Again, quite a long configuration is in front of us. To solve the problem at hand, I’m using a BGP feature called “inject-map”. This feature works by referencing two route-maps, one to specify the routes to be injected and the other one to specify when these routes should be injected. In this case, my injection map is called “Inject” and the selection route-map is called “Match”. This is where simplicity ends and “IOS mind tricks” begin.

BGP inject-map feature is a tricky one. The “match” route-map must use two prefix-lists; one to match the source of the route (in our case a prefix-list called R9) and the second one to specify the routes to be considered as a condition for injection. We’re using two separate routes as triggers and for some odd reason, we must use two route-map entries to solve this problem. Each of these entries specifies a different prefix-list for the trigger route (Network-Match-9 and Network-Match-99).

The “injection” route-map works in a similar fashion. We have two-entry route-map, which uses two separate prefix-lists to inject more specific routes. These prefix-lists are Network-Inject-9 and Network-Inject-99. At this point, we should have all those more-specific routes in the BGP table on R6.

R6:

R6#show ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*>i9.9.9.0/25       192.168.69.9             0    100      0 i
*>i9.9.9.0/24       192.168.69.9             0    100      0 i
*>i9.9.9.128/25     192.168.69.9             0    100      0 i
*> 10.0.0.4/32      172.16.26.2                            0 65002 65004 i
*                   172.16.56.5                            0 65005 65004 i
*>i99.99.99.0/25    192.168.69.9             0    100      0 i
*>i99.99.99.0/24    192.168.69.9             0    100      0 i
*>i99.99.99.128/25  192.168.69.9             0    100      0 i

The very last bit is to make sure the injected routes are advertised only to those neighbors we want them advertised to. For this purpose, I used Filter-Specific-R2 and Filter-Specific-R5 route-maps. If we examine routes received from R6 on R2 and R5, we should see a different picture on each.

R2:

R2#show ip bgp neighbors 172.16.26.6 routes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 9.9.9.0/25       172.16.26.6                            0 65069 i
*> 9.9.9.0/24       172.16.26.6                            0 65069 i
*> 9.9.9.128/25     172.16.26.6                            0 65069 i
*> 99.99.99.0/24    172.16.26.6                            0 65069 i

Total number of prefixes 4

R5:

R5#show ip bgp neighbors 172.16.56.6 routes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 9.9.9.0/24       172.16.56.6                            0 65069 i
*> 99.99.99.0/25    172.16.56.6                            0 65069 i
*> 99.99.99.0/24    172.16.56.6                            0 65069 i
*> 99.99.99.128/25  172.16.56.6                            0 65069 i

Total number of prefixes 4

This is exactly what I wanted to see. Last, but not the least, the routing table on R4 should also tell us that our solution worked. We’ll also confirm all this with two tracroutes.

R4:

R4#show ip route bgp
     99.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B       99.99.99.0/25 [20/0] via 172.16.45.5, 00:09:26
B       99.99.99.0/24 [20/0] via 172.16.45.5, 00:09:26
B       99.99.99.128/25 [20/0] via 172.16.45.5, 00:09:26
     9.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B       9.9.9.0/25 [20/0] via 172.16.24.2, 00:09:25
B       9.9.9.0/24 [20/0] via 172.16.45.5, 00:09:26
B       9.9.9.128/25 [20/0] via 172.16.24.2, 00:09:25

R4#traceroute 9.9.9.9 source Loopback4    

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 0 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec

R4#traceroute 99.99.99.99 source Loopback4

Type escape sequence to abort.
Tracing the route to 99.99.99.99

  1 172.16.45.5 0 msec 0 msec 0 msec
  2 172.16.56.6 4 msec 0 msec 0 msec
  3 192.168.69.9 4 msec *  0 msec

There we go, a perfect solution, for a very real problem. Do you have an alternative solution to this? If you do, please post it in the comments below!

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List

Print Friendly

Question 1:

What IP protocol number is used by GRE?

a. 41
b. 47
c. 51
d. 57

Question 2:

What is the size of a P2P GRE header?

a. 2 bytes
b. 1 byte
c. 3 bytes
d. 4 bytes

Question 3:

If you add a tunnel key to your P2P GRE encapsulation approach, how much overhead are you adding?

a. 2 bytes
b. 1 byte
c. 3 bytes
d. 4 bytes

Question 4:

If you configure a P2P GRE interface without using the tunnel key, how much total overhead does GRE add?

a. 24 bytes
b. 20 bytes
c. 28 bytes
d. 32 bytes

Question 5:

Which statements are true regarding the configuration shown below? Choose two.

a. The configuration is missing a required tunnel destination
b. The configuration demonstrates a P2P GRE
c. The configuration demonstrates a mGRE
d. A name resolution method is typically required for the configuration shown

interface tunnel 0
 ip address 209.165.200.224 255.255.255.0
 tunnel source fastethernet 0/0
 tunnel mode gre multipoint
 tunnel key 1
interface fastethernet 0/0
 ip address 10.0.0.1 255.0.0.0

Question 1 Answer:

1. b

Question 2 Answer:

2. d

Question 3 Answer:

3. d

Question 4 Answer:

4. a

Question 5 Answer:

4. c, d

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

Application

This layer interacts with software applications that implement a communicating component

• HTTP
• SHTTP
• SMTP
• FTP
• DNS
• Telnet
• SNMP

Presentation

Establishes context between application-layer entities, in which the higher-layer entities may use different syntax and semantics if the presentation service provides a mapping between them

• EBCDIC
• ASCII

Session

Controls the dialogues (connections) between computers; it establishes, manages and terminates the connections between the local and remote application

• ISAKMP/IKE
• NetBIOS

Transport

Provides transparent transfer of data between end users, providing reliable data transfer services to the upper layers

• TLS
• TCP
• UDP

Network

Provides the functional and procedural means of transferring variable length data sequences from a source host on one network to a destination host on a different network, while maintaining the quality of service requested by the transport layer

• AH
• ESP
• ICMP
• IGMP
• OSPF

Data Link

Provides the functional and procedural means to transfer data between network entities and to detect and possibly correct errors that may occur in the physical layer

• PPTP
• L2TP
• ARP/RARP
• Frame Relay

Physical

Defines electrical and physical specifications for devices

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

about the Next Hop Resolution Protocol (NHRP), we examined the theory and functionality of NHRP. In this post, we will examine the configuration commands that make NHRP possible. This will conclude the information required about this important protocol for the written exam. NOTE: This does not conclude information that should be known about the main use of NHRP – the Dynamic Multi-point VPN (DMVPN). That is a topic for other blog posts.

The first thing you do for configuration with NHRP is that you go to a multipoint GRE (mGRE) interface and you assign a NHRP network ID. You configure this with the command:

ip nhrp network-id number

What does this command do? That is a great question, both here and in the Certification exam environment!!! The NHRP network ID is used to define the NHRP domain for an NHRP interface. You need to be able to differentiate between multiple NHRP networks when two or more mGRE tunnel interfaces are available on the same router. Cisco relies upon the NHRP network ID to keep two NHRP networks separate from each other when both are configured on the same router.

It is extremely important to realize that the NHRP network ID is a locally significant parameter. This network ID is not transmitted in NHRP packets to other NHRP nodes. Because of this, the actual value of the NHRP network ID configured on a router need not match the same NHRP network ID on another router. As NHRP packets arrive on a GRE interface, they are assigned to the local NHRP domain in the NHRP network ID that is configured on that interface. You should note how similar this functionality is to the OSPF process ID.

NHRP network IDs can be unique on each mGRE tunnel interface on a router. This is required when running DMVPN Phase 1 or Phase 2 or when using a tunnel key on the mGRE interfaces as you will see in a later post. Also, realize that NHRP domains can span across mGRE tunnel interfaces on a route. This option is available when running DMVPN Phase 3 and not using a tunnel key on the GRE tunnel interfaces. In this case, the effect of using the same NHRP network ID on the mGRE tunnel interfaces is to mesh the two mGRE interfaces into a single DMVPN network.

To participate in NHRP process, a router connected to the NBMA network must be configured with the IP and NBMA addresses of its Net Hop Server (NHS). To configure static IP-to-NBMA address mapping on a router, we use the following command:

ip nhrp map ip-address nbma-address

To enable IP multicast and broadcast packets to be sent to the statically configured station, use the command:

ip nhrp map multicast nbma-address

This step is required on multipoint GRE tunnels and not required on point-point GRE tunnels, so obviously, it is typically required in our DMVPN implementations that utilize mGRE.

Finally, a Next Hop Server normally uses the routing table to determine where to forward NHRP packets and to find the egress point from an NBMA network. You may also statically configure the NHS with a set of IP address prefixes that correspond to the IP addresses of the stations it serves. You make this configuration using the logical NBMA network identifiers (IP addresses). You can configure these static mappings with the command:

ip nhrp nhs nhs-address [net-address [netmask]]

To bring this all together, recall the sample configuration provided in the previous blog post on the subject of NHRP. Note that this example emphasizes NHRP itself and does not yet focus on DMVPNs:

R1

interface tunnel 0
 no ip redirects
 ip address 209.165.200.224 255.255.255.0
 ip nhrp map 209.165.200.225 10.0.0.2
 ip nhrp network-id 1
 ip nhrp nhs 209.165.200.225
 tunnel source fastethernet 0/0
 tunnel mode gre multipoint
 tunnel key 1
interface fastethernet 0/0
 ip address 10.0.0.1 255.0.0.0

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

This code is not valid for the following products:

Any Instructor Led Bootcamp Course (Live or Online)
Online Learning Subscription
Blended Learning Solution – Use Coupon Code BLSCCFEB  to save $1500.

• CCIE R&S  Blended Learning Solution
• CCIE Voice Blended Learning Solution
• CCIE Security Blended Learning Solution

Note:

Offer ends Monday, February 6th, 2012 at 8:00 AM EST
Valid for all new orders only, and orders must be placed through website
(not called in or ordered via telephone).
Cannot be combined with any other promotion or discount.
NOTICE: These products will be issued to your account Monday morning.

Print Friendly

• Yash Joshi CCIE #31109 (Voice)

Are you a CCIE TOP GUN? If your name isn’t on THIS LIST yet, you can become a CCIE Top Gun. Simply, send us your name, CCIE#, and you can be the proud owner of the IPexpert’s CCIE Top Gun shirt shown below. Email us at ccie@ipexpert.com.

IPexpert is proud to boast the industry’s most complete and updated self-study portfolio for the CCIE Routing & Switching, CCIE Voice, CCIE Security, and CCIE Wireless Lab exams. Have you also used IPexpert or Proctor Labs to help you pass the CCIE lab exam? If so, we want to hear your story! Please email us at success@ipexpert.com.

Print Friendly

Question 1:

Which of these statements regarding NHRP are true? Choose two.

a. NHRP is typically used with P2P GRE interfaces
b. The NHRP network ID must match on all routers in the hub and spoke NBMA cloud
c. NHRP provides functionality similar to ARP
d. NHRP is a key ingredient in the DMVPN from Cisco Systems

Question 2:

NHRP can be broken down into two operational functions. What are these two? Choose two.

a. NHRP resolution
b. NHRP broadcasting
c. NHRP querying
d. NHRP registration

Question 1 Answer:

1. c, d

Question 2 Answer:

2. a, d

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

Obviously, the official announcement is coming soon. The RSA conference mentioned in the article, and  Cisco Live in San Diego, are certainly candidates for the official announcement.

Here is the relevant information from the post:

“The Real Life of an Expert: Introducing the New CCIE Security

CCIE Security 4.0 is unusual among security certificates for its up-to-date, real-world content. It emphasizes security competency and efficient problem solving in networks that use cloud services, carry voice and multimedia traffic, and are accessed by a variety of wireless devices.

The content, currently in development, may include real-world applications that involve:

• Securing both wireless and wired networks, including managing security policy by device and service
• Extending application awareness to security devices, moving security up to Layer 7 from the stateless packets of Layers 3 and 4, and applying policy on a per-identity basis
• Applying security policy in a network that has voice and video traffic
• Securing networks that use managed services, dual ISPs, IPv6, or IP multicast

Cisco will soon announce the blueprints for the CCIE Security 4.0 written and lab exams; the first exam will take place approximately six months later.

Although there are no prerequisites for registration, Cisco offers a preparation path through its CCNA and/or CCNP Security levels, and recommends that candidates have at least three years of hands-on network security experience.”

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly

While you may consider NHRP as a simple name resolution protocol like Address Resolution Protocol (ARP), NHRP operates in a much more efficient manner. NHRP operates in a client/server type fashion. In a typical implementation, hub routers in a hub and spoke topology operate as next-hop servers (NHS). Spoke routers in the topology act as next-hop clients (NHC). It is the job of the hub router next-hop server to maintain a next-hop resolution protocol database of public interface addresses of each spoke. The hub router builds this database by accepting registrations of each spoke device’s physical IP address as each spoke boots on the network. Spoke routers also query the NHRP database for the physical addresses of the destination spokes.

Possessing the physical addresses of remote spokes allows these spoke devices to build direct tunnels with these remote spokes. This is the beauty of the next hop resolution protocol. Remote spoke routers now possess the ability to communicate directly without requiring traffic to use an intermediate hop (the hub router).

Notice that you can segment the operation of NHRP into two distinct phases. There is the registration process and the resolution process. The overall result of NHRP is the decreases the overhead placed on the hub device and spoke devices communicate directly with other spoke devices.

The example configuration below demonstrates the simplicity that makes this powerful protocol function. This blog will detail the protocol and its configuration in more depth in future posts.

R1

interface tunnel 0
 no ip redirects
 ip address 209.165.200.224 255.255.255.0
 ip nhrp map 209.165.200.225 10.0.0.2
 ip nhrp network-id 1
 ip nhrp nhs 209.165.200.225
 tunnel source fastethernet 0/0
 tunnel mode gre multipoint
 tunnel key 1
interface fastethernet 0/0
 ip address 10.0.0.1 255.0.0.0

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Print Friendly