Juniper JN0-664 Service Provider Routing and Switching, Professional Exam JNCIP-SP Exam Practice Test

Answer : A, C

In PIM-SM (Protocol Independent Multicast - Sparse Mode), the Designated Router (DR) plays a crucial role in multicast forwarding. The DR is responsible for various tasks depending on whether it is connected to the source or the receiver. Let's analyze each statement regarding the PIM DR in a PIM-SM domain.

1. **Statement A: The source DR sends PIM register messages from the source network to the RP.**

- Correct. In PIM-SM, the DR on the source's local network is responsible for encapsulating multicast packets in PIM Register messages and sending them to the Rendezvous Point (RP). This process ensures that the RP is aware of active sources.

2. **Statement B: If the DR priorities match, the router with the lowest IP address is selected as the DR.**

- Incorrect. The correct rule is that if the DR priorities match, the router with the **highest** IP address is selected as the DR. The election process first compares priorities; if priorities are equal, the IP addresses are compared to select the DR.

3. **Statement C: The receiver DR sends PIM join and PIM prune messages from the receiver network toward the RP.**

- Correct. In PIM-SM, the DR on the receiver's local network sends PIM Join messages toward the RP to join the multicast distribution tree. Similarly, it sends PIM Prune messages to leave the tree when there are no interested receivers.

4. **Statement D: By default, PIM DR election is performed on point-to-point links.**

- Incorrect. By default, PIM DR election is performed on multi-access networks (e.g., Ethernet). On point-to-point links, there is no need for a DR election as there are only two routers involved.

**Conclusion**:

The correct statements regarding the PIM DR in a PIM-SM domain are:

**A. The source DR sends PIM register messages from the source network to the RP.**

**C. The receiver DR sends PIM join and PIM prune messages from the receiver network toward the RP.**

**Reference**:

- Juniper Networks Documentation on PIM-SM: [PIM-SM Overview](https://www.juniper.net/documentation/en_US/junos/topics/concept/pim-sparse-mode-overview.html)

- RFC 7761, Protocol Independent Multicast - Sparse Mode (PIM-SM): [RFC 7761](https://tools.ietf.org/html/rfc7761) which details the PIM-SM protocol, including DR roles and election procedures.

Answer : A

This configuration applies to IGMP (Internet Group Management Protocol) and is designed to control multicast group memberships on the interface ge-0/0/0.0.

Breaking Down the Configuration

1 Policy-Statement: block-igmp

policy-statement block-igmp {

term 1 {

from {

route-filter 224.7.7.7/32 exact;

source-address-filter 192.168.100.10/32 exact;

}

then reject;

}

}

This policy blocks IGMP joins for group 224.7.7.7 only if the source IP is 192.168.100.10.

If both conditions match, the request is rejected.

2 IGMP Configuration on Interface ge-0/0/0.0

[edit protocols igmp]

user@router# show

interface ge-0/0/0.0 {

group-policy block-igmp;

group-limit 25;

}

group-policy block-igmp applies the policy statement block-igmp, meaning IGMP join requests are evaluated based on this policy.

group-limit 25 means the interface allows up to 25 multicast groups.

Evaluating the Answer Choices

A. Joins for group 224.7.7.7 are rejected if the source address is 192.168.100.10.

Correct, because:

The policy specifically matches group 224.7.7.7 and source IP 192.168.100.10.

If both conditions are met, the join is rejected.

B. Joins for any group are accepted if the group count value is less than 25.

Incorrect, because:

The group-limit (25) applies to the total number of IGMP groups but does not override explicit policy rules.

Even if there are fewer than 25 groups, a join request can still be rejected by the policy statement.

C. Joins for group 224.7.7.7 are always rejected, regardless of the group count.

Incorrect, because:

The policy only blocks joins from the specific source 192.168.100.10.

Joins from other sources to 224.7.7.7 are allowed.

D. Joins for group 224.7.7.7 are accepted if the group count is less than 25.

Incorrect, because:

Joins for 224.7.7.7 from source 192.168.100.10 will always be rejected, even if the group count is below 25.

The group-limit does not override the rejection policy.

'Joins for group 224.7.7.7 are rejected if the source address is 192.168.100.10.'

Official Juniper Documentation Reference: Junos IGMP Policy Configuration Guide

'A group-policy statement allows filtering IGMP joins based on multicast group address and source IP.'

Answer : C

Analyzing the Exhibit and Understanding the Issue

The exhibit shows BGP configurations on CE-1 and PE-1, which are connected via EBGP.

CE-1 (Customer Edge)

Uses AS 64511 and establishes an EBGP session with PE-1 (AS 65550).

Configured to export 10 static routes (192.168.1.0/24 - 192.168.10.0/24) using the static-to-bgp policy.

PE-1 (Provider Edge)

Uses AS 65550 and is peering with CE-1 (AS 64511).

Configured with a prefix-limit of 5 on received routes from CE-1.

Teardown enabled, meaning if more than 5 prefixes are received, the BGP session is shut down.

Identifying the Problem

CE-1 is correctly configured with peer AS 65550, so Option B ('CE-1 is configured with an incorrect peer AS') is incorrect .

CE-1 is advertising exactly 10 static routes (as per policy).

PE-1 has a prefix-limit maximum 5 with teardown enabled.

This means that when CE-1 advertises more than 5 prefixes, PE-1 shuts down the BGP session.

BGP moves to the 'Active' state, indicating that the session has been disrupted and PE-1 is trying to re-establish the connection.

CE-1 is reachable since the session was initially established before the limit was exceeded, so Option D ('CE-1 is unreachable') is incorrect .

CE-1 is not advertising its entire routing table, only the static prefixes listed in the policy, so Option A ('CE-1 is advertising its entire routing table') is incorrect .

Correct Answer

C. The prefix limit has been reached on PE-1

Verification from Juniper Documentation

Juniper BGP Prefix Limit Documentation confirms that exceeding the prefix limit with teardown causes the BGP session to go into 'Active' state.

Juniper Troubleshooting Guide for BGP Peering Issues states that when a BGP session reaches the prefix limit and has teardown enabled, the session is terminated.

Answer : A, B

The output is from the show l2vpn connections command on a Juniper router. This command is used to verify the status of Layer 2 VPN (L2VPN) pseudowires between Provider Edge (PE) routers.

Breakdown of Key Information:

Instance: vpn-A

This is the L2VPN instance being monitored.

Connection Status (St)

The connection status is 'Up', meaning the pseudowire is operational.

Local Site: CE1-2 (2)

The PE router is attached to a single local site (CE1-2).

Uptime & Connection Flaps

The output shows the last time the connection was up:

Time last up: Apr 11 14:35:27 2020

The '# Up trans' value is 1, meaning this connection has been established once and has not flapped since it was initiated.

VLAN ID Mismatch Check

The legend includes 'VM -- VLAN ID mismatch', but this status is not present in the connection output.

This means there is NO VLAN ID mismatch.

Flow Labels

The Flow Label Transmit is No, and the Flow Label Receive is No.

This means the PE router does NOT have the capability to pop flow labels.

Answer : C

AToM (Any Transport over MPLS) is a framework that supports various Layer 2 transport types over an MPLS network core. One of the transport types supported by AToM is LDP Layer 2 circuit, which is a point-to-point Layer 2 connection that uses LDP for signaling and MPLS for forwarding. LDP Layer 2 circuit can support Layer 2 connectivity without using BGP and can be scalable and efficient by using a single MPLS LSP for multiple VPN connections. The customer can maintain all routing for their private network by using their own CE switches.

Answer : A

BGP route reflectors are BGP routers that are allowed to ignore the IBGP loop avoidance rule and advertise IBGP learned routes to other IBGP peers under specific conditions. BGP route reflectors can reduce the number of IBGP sessions and updates in a network by eliminating the need for a full mesh of IBGP peers. BGP route reflectors can have three types of peerings:

EBGP neighbor: A BGP router that belongs to a different autonomous system (AS) than the route reflector.

IBGP client neighbor: An IBGP router that receives reflected routes from the route reflector. A client does not need to peer with other clients or non-clients.

IBGP non-client neighbor: An IBGP router that does not receive reflected routes from the route reflector. A non-client needs to peer with other non-clients and the route reflector.

In the exhibit, we can see that RR1 and RR2 are route reflectors in the same AS with reachability redundancy. They have two types of peerings: EBGP neighbors (R1 and R4) and IBGP client neighbors (Client1, Client2, and Client3). RR1 and RR2 are also peered with each other as IBGP non-client neighbors.

Answer : A, C

A sham link is a logical link between two PE routers that belong to the same OSPF area but are connected through an L3VPN. A sham link makes the PE routers appear as if they are directly connected, and prevents OSPF from preferring an intra-area back door link over the VPN backbone. A sham link creates an OSPF multihop neighborship between the PE routers using TCP port 646.The PEs exchange Type 1 OSPF LSAs instead of Type 3 OSPF LSAs for the L3VPN routes, which allows OSPF to use the correct metric for route selection1.