nerdexam
Cisco

352-001 · Question #52

You are designing a Group Encrypted Transport virtual private network solution for an existing branch network. The existing network has the following characteristics: - 50 remote sites (with an…

The correct answer is C. No additional protocol is necessary. GETVPN preserves original IP headers, so existing routing protocols function without modification and no additional overlay routing protocol is required.

Designing Security

Question

You are designing a Group Encrypted Transport virtual private network solution for an existing branch network. The existing network has the following characteristics:

  • 50 remote sites (with an additional 30 remote sites expected over the next 3 years)
  • Connectivity between all sites is via Multiprotocol Label Switching Layer 3 virtual private network service

from a single provider

  • Open Shortest Path First is the routing protocol used between provider edge and customer edge routers
  • The customer edge routers will become group members performing the encryption between sites

Which additional routing protocol would you use for the overlay routing between the group members?

Options

  • AOpen Shortest Path First (with a different process ID)
  • BEnhanced Interior Gateway Routing Protocol
  • CNo additional protocol is necessary.
  • DExternal Border Gateway Protocol
  • ERouting Information Protocol Version 2
  • FNext Hop Resolution Protocol

How the community answered

(30 responses)
  • A
    7% (2)
  • B
    3% (1)
  • C
    70% (21)
  • D
    3% (1)
  • F
    17% (5)

Why each option

GETVPN preserves original IP headers, so existing routing protocols function without modification and no additional overlay routing protocol is required.

AOpen Shortest Path First (with a different process ID)

Running a separate OSPF process would create unnecessary routing complexity; GETVPN's header-preserving design makes an additional process entirely redundant.

BEnhanced Interior Gateway Routing Protocol

EIGRP would introduce an additional routing process with no benefit, since existing routing already handles path selection and GETVPN does not disrupt it.

CNo additional protocol is necessary.Correct

Unlike traditional tunnel-based VPNs, GETVPN is a tunnel-less architecture that encrypts the payload while keeping the original IP source and destination addresses intact in the outer header. Because the routing information is preserved end-to-end, the existing OSPF sessions between PE and CE routers continue to operate normally without any additional overlay routing protocol needed between group members.

DExternal Border Gateway Protocol

eBGP is used for inter-autonomous system routing and is not appropriate or necessary as an overlay in this single-provider MPLS L3 VPN scenario.

ERouting Information Protocol Version 2

RIPv2 offers poor scalability and slow convergence, making it unsuitable even if an additional protocol were needed.

FNext Hop Resolution Protocol

NHRP is specific to DMVPN for dynamic spoke-to-spoke tunnel resolution and has no role in GETVPN architecture.

Concept tested: GETVPN tunnel-less header preservation eliminating overlay routing

Source: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_getvpn/configuration/xe-16-12/sec-conn-getvpn-xe-16-12-book/sec-get-vpn.html

Topics

#GETVPN#MPLS L3VPN#group member routing#OSPF CE-PE

Community Discussion

No community discussion yet for this question.

Full 352-001 Practice