Juniper Open Learning
Highlighted
Juniper Open Learning

JNCIE-SP/VPNs/Layer 3 VPNs/6PE

[ Edited ]
‎01-25-2020 10:36 AM

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/l3-vpns-ipv6-traffic.html#id-exam...

 

My vMX version: 17.4R1.16

 

Greetings, I have configured the example above exactly as given, except I used ge interfaces specific to my home lab. I am unable to ping CE2 @ ::192.0.1.5 from CE1 ::192.0.1.1. Can somebody please answer the following questions?

 

1) Is there an error in the example where I would not be able to ping without corrective configuration?

2) Is this example useful as prep for the 6PE topic on the JNICE-SP exam?

3) What show commands on what devices would be best for me to post in order to troubleshoot this issue?

 

Thanks.

6 REPLIES 6
Highlighted
Juniper Open Learning

Re: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

‎01-25-2020 12:53 PM

Hello,

The config in example is 6VPE (not 6PE). Please refer following link for bful explanation.

 

https://www.inetzero.com/6pe-and-6vpe/

Above link is good start for IE preparation.

Please check route for CE's loopback address on both the CE and PE. 

 

show route loopback-address  table inet6.0 < on CE

show route loopback-address  table red.inet6.0 < on PE

If you can't see the route for both the loopback on each CE and PE. Please check the hidden routes.

 

show route loopback-address  table inet6.0 hidden extensive

show route loopback-address  table red.inet6.0 hidden extensive


Sometimes an unsuable/unresolvable IPv6 protocol nex-hop can cause hidden route

PS: Please mark my response as solution if it answers your query, kudos are appreciated too!

Thanks
Vishal

 

 

Highlighted
Juniper Open Learning

Re: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

‎01-26-2020 08:18 AM

Hello,

 


@CommitConfirm wrote:

 

1) Is there an error in the example where I would not be able to ping without corrective configuration?

 

There is an omission in this example - You need to add this knob to all Your PE and CE nodes to be able to ping v4-mapped IPv6 address

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/ipv6-ipv4-mapped-address...

 

 


@CommitConfirm wrote:

 

2) Is this example useful as prep for the 6PE topic on the JNICE-SP exam?



Not for 6PE, yes for 6VPE. The difference is that 6PE requires a special BGP address family enabled - "family inet6 labeled-unicast", and does NOT use routing-instances.

 

 


@CommitConfirm wrote:

 

3) What show commands on what devices would be best for me to post in order to troubleshoot this issue?

 

 



Usual commands for JUNOS L3VPN t'shooting would be useful

 

 

show route instance <VRFname> extensive
show route table <VRFname> extensive
show route receive-protocol bgp <neighbor IP> extensive
show route table bgp.l3vpn.0 extensive
show route table inet.3 extensive show route forwarding-table vpn <VRFname> extensive

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Juniper Open Learning

Re: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

[ Edited ]
‎01-26-2020 12:44 PM

Thank you. I have configured both "allow-v4mapped-packets" and "allow-6pe-traceroute" on all of the routers in the topology. Unfortunately, I am still unable to ping CE2 @ ::192.0.2.5/24 from CE1 ::192.0.2.1/24.

 

I am noticing something interesting on PE1. Here is the abbreviated red.inet6.0 table:

root@PE1> show route table red.inet6.0 ::/24

red.inet6.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::/24              *[BGP/170] 00:54:33, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.1 via ge-0/0/0.0
                    [BGP/170] 00:54:14, localpref 100, from 192.0.2.4
                      AS path: I, validation-state: unverified
                    > to 10.1.1.6 via ge-0/0/1.0, Push 25, Push 299856(top)

::/24 is known via both ge-0/0/0 and ge-0/0/1, but the route via ge-0/0/0 is active. Since ge-0/0/0 points back to CE1, wouldn't the active route need to be the one via ge-0/0/1?

Highlighted
Juniper Open Learning

Re: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

‎01-26-2020 07:13 PM

Can you please provide following output from both the PE (PE1 and PE2)

 

show route table red.inet6.0 ::192.0.2.5/24
show route table red.inet6.0 ::192.0.2.1/24

 

Highlighted
Juniper Open Learning
Solution
Accepted by topic author CommitConfirm
‎01-27-2020 05:27 AM

Re: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

[ Edited ]
‎01-26-2020 07:25 PM

Hello,

 


@CommitConfirm wrote:

::/24 is known via both ge-0/0/0 and ge-0/0/1, but the route via ge-0/0/0 is active. Since ge-0/0/0 points back to CE1, wouldn't the active route need to be the one via ge-0/0/1?


 

Well spotted. There is an error in the CE configs where lo0 IPv6 addresses have wrong netmasks:

 

set interfaces lo0 unit 0 family inet6 address ::192.0.2.1/24

 

The correct netmasks are /128. Please add following commands to Your CEs:

 

delete interfaces lo0.0 family inet6
set interfaces lo0 unit 0 family inet6 address ::192.0.2.1/128  ## or .5/128 for CE2

 

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Juniper Open Learning

Re: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

‎01-27-2020 05:27 AM

That was it! I can ping when I change the loopback addresses on the CE routers from /24 to /128. I thought I had tried this before, but I think I had some extra cabling issues at that time. I removed the "allow-v4mapped-packets" and "allow-6pe-traceroute" commands from every device, and I can still ping.

 

Here is the full red.inet6.0 table from both PE1 and PE2 when the CE loopbacks were /24:

 

root@PE1> show route table red.inet6.0

red.inet6.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::/24              *[BGP/170] 00:03:26, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.1 via ge-0/0/0.0
                    [BGP/170] 00:01:02, localpref 100, from 192.0.2.4
                      AS path: I, validation-state: unverified
                    > to 10.1.1.6 via ge-0/0/1.0, Push 28, Push 299888(top)
::10.1.1.0/126     *[Direct/0] 00:19:25
                    > via ge-0/0/0.0
                    [BGP/170] 00:18:18, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.1 via ge-0/0/0.0
::10.1.1.2/128     *[Local/0] 00:19:25
                      Local via ge-0/0/0.0
::10.1.1.12/126    *[BGP/170] 00:16:54, localpref 100, from 192.0.2.4
                      AS path: I, validation-state: unverified
                    > to 10.1.1.6 via ge-0/0/1.0, Push 28, Push 299888(top)
fe80::e36:47ff:fed4:a402/128
                   *[Local/0] 00:19:25
                      Local via ge-0/0/0.0
root@PE2> show route table red.inet6.0

red.inet6.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::/24              *[BGP/170] 00:01:56, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.14 via ge-0/0/0.0
                    [BGP/170] 00:04:18, localpref 100, from 192.0.2.2
                      AS path: I, validation-state: unverified
                    > to 10.1.1.9 via ge-0/0/1.0, Push 300000, Push 299872(top)
::10.1.1.0/126     *[BGP/170] 00:17:47, localpref 100, from 192.0.2.2
                      AS path: I, validation-state: unverified
                    > to 10.1.1.9 via ge-0/0/1.0, Push 300000, Push 299872(top)
::10.1.1.12/126    *[Direct/0] 00:20:16
                    > via ge-0/0/0.0
                    [BGP/170] 00:19:46, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.14 via ge-0/0/0.0
::10.1.1.13/128    *[Local/0] 00:20:16
                      Local via ge-0/0/0.0
fe80::e36:47ff:fef8:cd02/128
                   *[Local/0] 00:20:16
                      Local via ge-0/0/0.0

 

 

And here they are at /128:

root@PE1> show route table red.inet6.0

red.inet6.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::10.1.1.0/126     *[Direct/0] 00:52:33
                    > via ge-0/0/0.0
                    [BGP/170] 00:51:26, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.1 via ge-0/0/0.0
::10.1.1.2/128     *[Local/0] 00:52:33
                      Local via ge-0/0/0.0
::10.1.1.12/126    *[BGP/170] 00:50:02, localpref 100, from 192.0.2.4
                      AS path: I, validation-state: unverified
                    > to 10.1.1.6 via ge-0/0/1.0, Push 28, Push 299888(top)
::192.0.2.1/128    *[BGP/170] 00:01:18, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.1 via ge-0/0/0.0
::192.0.2.5/128    *[BGP/170] 00:01:04, localpref 100, from 192.0.2.4
                      AS path: I, validation-state: unverified
                    > to 10.1.1.6 via ge-0/0/1.0, Push 28, Push 299888(top)
fe80::e36:47ff:fed4:a402/128
                   *[Local/0] 00:52:33
                      Local via ge-0/0/0.0
root@PE2> show route table red.inet6.0

red.inet6.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::10.1.1.0/126     *[BGP/170] 00:50:42, localpref 100, from 192.0.2.2
                      AS path: I, validation-state: unverified
                    > to 10.1.1.9 via ge-0/0/1.0, Push 300000, Push 299872(top)
::10.1.1.12/126    *[Direct/0] 00:53:11
                    > via ge-0/0/0.0
                    [BGP/170] 00:52:41, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.14 via ge-0/0/0.0
::10.1.1.13/128    *[Local/0] 00:53:11
                      Local via ge-0/0/0.0
::192.0.2.1/128    *[BGP/170] 00:01:57, localpref 100, from 192.0.2.2
                      AS path: I, validation-state: unverified
                    > to 10.1.1.9 via ge-0/0/1.0, Push 300000, Push 299872(top)
::192.0.2.5/128    *[BGP/170] 00:01:45, localpref 100
                      AS path: I, validation-state: unverified
                    > to ::10.1.1.14 via ge-0/0/0.0
fe80::e36:47ff:fef8:cd02/128
                   *[Local/0] 00:53:11
                      Local via ge-0/0/0.0

When they were at ::/24, I could see that the next-hop reference count was the main difference between the two ::/24 routes. I think this means that the best path was being selected based on the "Shortest IGP path to BGP next hop" BGP path-selection criteria. Here is the output I looked at to try to determine which BGP path-selection criteria was determining the tie-break between the two ::/24 routes:

root@PE2> show route table red.inet6.0 detail

red.inet6.0: 5 destinations, 7 routes (5 active, 0 holddown, 0 hidden)
::/24 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect, Next hop index: 0
                Address: 0xb6754b0
                Next-hop reference count: 4
                Source: ::10.1.1.14
                Next hop type: Router, Next hop index: 614
                Next hop: ::10.1.1.14 via ge-0/0/0.0, selected
                Session Id: 0x15b
                Protocol next hop: ::10.1.1.14
                Indirect next hop: 0xbdda080 1048574 INH Session ID: 0x15c
                State: <Active Int Ext>
                Local AS: 64510 Peer AS: 64510
                Age: 26:33      Metric2: 0
                Validation State: unverified
                Task: BGP_64510_64510.::10.1.1.14
                Announcement bits (3): 0-KRT 1-BGP_RT_Background 2-Resolve tree 3
                AS path: I
                Accepted
                Localpref: 100
                Router ID: 192.0.2.5
         BGP    Preference: 170/-101
                Route Distinguisher: 64512:1
                Next hop type: Indirect, Next hop index: 0
                Address: 0xb676590
                Next-hop reference count: 5
                Source: 192.0.2.2
                Next hop type: Router, Next hop index: 620
                Next hop: 10.1.1.9 via ge-0/0/1.0, selected
                Label operation: Push 300000, Push 299872(top)
                Label TTL action: prop-ttl, prop-ttl(top)
                Load balance label: Label 300000: None; Label 299872: None;
                Label element ptr: 0xced0080
                Label parent element ptr: 0xb676fa0
                Label element references: 1
                Label element child references: 0
                Label element lsp id: 0
                Session Id: 0x15d
                Protocol next hop: ::ffff:192.0.2.2
                Label operation: Push 300000
                Label TTL action: prop-ttl
                Load balance label: Label 300000: None;
                Indirect next hop: 0xbddae00 1048576 INH Session ID: 0x15f
                State: <Secondary NotBest Int Ext ProtectionCand>
                Inactive reason: Not Best in its group - IGP metric
                Local AS: 64512 Peer AS: 64512
                Age: 28:55      Metric2: 1
                Validation State: unverified
                Task: BGP_64512.192.0.2.2
                AS path: I
                Import Accepted
                VPN Label: 300000
                Localpref: 100
                Router ID: 192.0.2.2
                Primary Routing Table bgp.l3vpn-inet6.0

I am far from 100% sure that IGP metric is what determined which ::/24 to make active.

Feedback