Training and Certification

 View Only
last person joined: yesterday 

How to get the most from Juniper's education services and get advice on your certification journey.
  • 1.  JNCIE-SP/VPNs/Layer 3 VPNs/6PE

    Posted 01-25-2020 10:36

    https://www.juniper.net/documentation/en_US/junos/topics/topic-map/l3-vpns-ipv6-traffic.html#id-example-tunneling-layer-3-vpn-ipv6-islands-over-an-ipv4-core-using-ibgp-and-independent

     

    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.


    #VPNs
    #Layer3VPNs
    #JNCIE-SP
    #6VPE
    #6PE


  • 2.  RE: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

     
    Posted 01-25-2020 12:53

    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

     

     



  • 3.  RE: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

    Posted 01-26-2020 08:18

    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-addresses-processing-enabling.html

     

     


    @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



  • 4.  RE: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

    Posted 01-26-2020 12:45

    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?



  • 5.  RE: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

     
    Posted 01-26-2020 19:13

    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

     



  • 6.  RE: JNCIE-SP/VPNs/Layer 3 VPNs/6PE
    Best Answer

    Posted 01-26-2020 19:25

    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



  • 7.  RE: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

    Posted 01-27-2020 05:27

    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.



  • 8.  RE: JNCIE-SP/VPNs/Layer 3 VPNs/6PE

    This message was posted by a user wishing to remain anonymous
    Posted 2 days ago
    This message was posted by a user wishing to remain anonymous

    Hi, I am trying to do this example as well and am unable to ping CE1 from CE2 and vice versa.I am able to ping PE1 from CE1 but would like some help in figuring out how to debug this.

    My result from PE1:

    regress@VMX_PE1_re> show route table red.inet6.0 ::192.0.2.5/24

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

    ::10.1.1.0/126     *[Direct/0] 15:10:55
                        >  via ge-0/0/0.0
                        [BGP/170] 15:09:36, localpref 100
                          AS path: 64510 I, validation-state: unverified
                        >  to ::10.1.1.1 via ge-0/0/0.0
    ::10.1.1.2/128     *[Local/0] 15:10:55
                           Local via ge-0/0/0.0
    ::192.0.2.1/128    *[BGP/170] 00:06:20, localpref 100
                          AS path: 64510 I, validation-state: unverified
                        >  to ::10.1.1.1 via ge-0/0/0.0

    It appears that from PE1 I am unable to see ::192.0.2.5/128 and I'm not fully sure why