Training and Certification

 View Only
last person joined: 2 days ago 

How to get the most from Juniper's education services and get advice on your certification journey.
Expand all | Collapse all

JNCIE-DC topics and documentation - need more detail

  • 1.  JNCIE-DC topics and documentation - need more detail

    Posted 08-01-2022 16:14
    Hi all,

    I'm currently working through the new JNCIE-DC self-stufy bundle via the AAP. I'm finding many of the technologies in chapter 2 are poorly described in the workbook. Many of them are basically just "turn on this feature X because it solves Y".

    This is not what I need to learn. I want to understand why I'm turning on a feature, what problem it solves, how it solves it, and what is happening on the device FIB/RIB to make that happen. Most of the Juniper documentation on EVPN-VXLAN and QFX say even less than the workbook. I've found SOME clarity via the RFCs at times, but even that is not really enough to help me truly understand some of the configuration knobs.

    Has anyone else ran into this with JNCIE? This is making my impostor syndrome flare up super hard because I think I'm going to be a terrible JNCIE even if I pass because I won't be able to explain some of these knobs or why someone would use them.

    ------------------------------
    Dakota McGee
    ------------------------------


  • 2.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-02-2022 05:52
    Hi all,
    I see the different between current JNCIE-DC Self study Bundle book and from high level view of new format JNCIE-DC ( refer this link JNCIE-DC Certification | Juniper Networks US), especially is Apstra  software in Underlay. 
    So When does Juniper update the new book? Or anyone know where to got the new resource? 

    Thanks,
    Henry - Vietnam


  • 3.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-02-2022 12:34
    Henry,

    The new JNCIE-DC Self Study Bundle has been updated and released to cover the new topics in the updated JNCIE-DC exam. This update is free for those who have already purchased the JNCIE-DC SSB and all you will need to do is update your eVantage library.

    The process to update the eVantage library:
    1. Go to the top right corner, next to the Search field, and click on the first icon

    Update eVantage library

    2. Click on Update Library.

    Regards,
    Josh Verhaal

    ------------------------------
    Josh Verhaal
    ------------------------------



  • 4.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-05-2022 00:33
    Many thanks to Josh,
    I have got the new SSB now, but how to got the new initial configuration for all devices and Apstra server? The time to access Lab was over. 
    Appreciate!
    Henry


  • 5.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-08-2022 15:53
    Henry,

    Does that mean that you used up all the sessions that came with the self study bundle?

    ------------------------------
    Josh Verhaal
    ------------------------------



  • 6.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-02-2022 12:34
    Dakota,

    The JNCIE Self Study Bundles were not designed to provide you with the detailed learning of the underlying technologies. To learn that level of information you should take/review the courses that contribute to the other JNCIx level prerequisite exams. I suspect the part that you may be missing is the Apstra component since you are JNCIP-DC certified. For the Juniper Apstra knowledge I would recommend taking the Juniper Apstra course. This course provides the detailed explanations of the components that were included in the JNCIE-DC exam and SSB. For more information about EVPN/VXLAN I would recommend the ADCX course.

    I hope this helps point you in the right direction

    Regards,
    Josh Verhaal

    ------------------------------
    Josh Verhaal
    ------------------------------



  • 7.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-02-2022 15:44
    Hi Josh,

    Nice to speak with you again :)

    Surprisingly, Apstra is the EASY part here. The JNCIE workbook is more than enough to get a good understanding of the tech. I've taken the on-demand version of ADCX and didn't really feel prepared for JNCIP at all. I barely passed. So I'm not sure I would agree that course is sufficient in explaining these confusing topics at all.

    Here's my current confusion. All taken from the solutions sections of the JNCIE-DC workbook.

    #1
    set routing-options forwarding-table chained-composite-next-hop evpn ingress
    • I understand what this does from a EVPN-MPLS perspective thanks to the book "MPLS In The SDN Era", but I can find NOTHING on Google that explains exactly what this does in EVPN-VXLAN. Every Juniper doc recommends enabling it on the leaf but not on the spine. Best they say is "allows the device to process greater amount of traffic".
    • That's fantastic...how? Why would an engineer enable this? What is the use case? What problem does it solve? I know what composite-next-hops are and what they do in MPLS. What is this doing in VXLAN?

    #2
    mac-vrf
    • My understanding here is that this instance-type is simply a "virtual-switch" that works in tandem with an IP-VRF (i.e. "virtual router"). Enables complete isolation at L2.
    • Why would anyone enable this? VLANs are already "isolated" at L2. If the IRB doesn't route the traffic then the two VLANs can't talk anyway. Why does this instance-type need it's own RD/RT that is unique from the IP-VRF RD/RT if they work together? Just seems like over-complicating config for no real benefit.

    #3
    EVPN Type 5/IP Prefix routes
    • I'm failing to understand why this is a thing. RFC-7432 doesn't really explain this well either imo. EVPN is mainly used for L2VPN (it's even in the AFI L2VPN in MP-BGP). If we are going to enable Type 5 routes, why are we even using EVPN vs standard MP-BGP in the context of a data center network?

    #4
    RD/RT under both "protcols evpn" and "switch-options"
    • I'm seeing RD/RT needing to be configured under both of these hierarchies, but both are unique. Why is there so many different places that need "unique" RD/RT? What is this accomplishing?

    #5
    set routing-instances tenant1 vrf-table-label
    • Totally understand what this does in MPLS and why someone would want to enable it. What does this do for VXLAN? I find no mention anywhere in my Juniper docs search how a "label" has an effect on VXLAN.


    I think this is everything that I'm super confused on at the moment. I'm 100% sure there will be more in this journey. Thanks again for taking the time out to offer help and guidance - I can really use it.


    ------------------------------
    Dakota McGee
    ------------------------------



  • 8.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-02-2022 19:22
    Hi Dakota,

    #1 In relation to a data center built on QFXs, if you need to use pure Type 5 routes, you must configure CNH or the PFE will not program the tunnel next hop (See KB32854 below). I'm not too sure about the Leaf vs Spine issue that you mention.

    https://supportportal.juniper.net/s/article/QFX-EVPN-VXLAN-configuration-knobs-and-caveats?language=en_US


    #2 My guess is that going forward, MAC-VRF will be the preferred way to configure EVPN/VXLAN. Before MAC-VRF, a QFX could only have a one-to-one mapping between VNI and VLAN ID. I always thought of this as a bit of a limitation and also didn't really match up to RFC 7432. RFC 7432 defines several "Service Interfaces", many of which, a QFX wasn't able to do before. With MAC-VRF, a QFX can support VLAN-based (similar to non-MAC-VRF behavior), VLAN-aware, and VLAN-bundle service interfaces.


    #3 Type 5 routes solve EVPN routing problems both inside a single data center and also between two data centers. The easiest one to think about is the DCI case. Assume we have two overlay VLANs, VLAN 100 (DC1) and VLAN 200 (DC2), that we want to route between. Lets also assume that each VLAN currently has 1000 learned MACs. Without type 5 routes, the border router for DC1 would have to advertise 1000 Type 2 routes to the remote DC. With type 5 routes, the border router for DC1 will only have to advertise a single Type 5 to the remote DC. If multiply the number of VLANs by any number, we can easily see how Type 5's helps our DCs scale.

    The harder one to explain is how Type 5's can help a single DC scale. Assume we have two leaf nodes that are acting as both L2 and L3 EVPN/VXLAN gateways. Assume we have two overlay VLANs, VLAN 100 (on Leaf1 only) and VLAN 200 (on Leaf2 only), that we want to route between. Lets also assume that each VLAN currently has 1000 learned MACs (not sure how realistic that it but just go with it.) Without type 5 routes, Leaf1 would have to advertise 1000 Type 2 routes (for VLAN 100) to Leaf2. Why does Leaf2 need these Type 2 advertisements? Leaf2 needs the Type 2 advertisement to populate its own VLAN 100 bridge domain which has no directly attached hosts for VLAN 100. Thats right, Leaf2 only has attached hosts that belong to VLAN 200 but it still needs to populate a second bridge domain for VLAN 100. Doesn't this seem to be a waste of resources? If you said yes, you would be right. By using type 5 routes only, Leaf1 will only have to advertise a single Type 5 to Leaf2 and Leaf2 does not have to maintain a bridge domain for VLAN 100 at all. Again, if you multiply the number of VLANs by any number, we can easily see how Type 5's helps our DCs scale.

    #4 Honestly, I think it relates back to pre-MAC-VRF vs MAC-VRF. The reason for so many RDs and RTs makes much more sense in the MAC-VRF scenario where each EVPN gets its own routing-instance configuration. From RFC 7432, "The policy attributes of EVPN are very similar to those of IP-VPN. An EVPN instance requires a Route Distinguisher (RD) that is unique per MAC-VRF and one or more globally unique Route Targets (RTs)." Again, I would focus on MAC-VRF configuration going forward.

    #5 I do not know if vrf-table-label is needed or not. I lean towards not.  The classic purpose of vrf-table-label was to allow a M/T/MX series device to perform an MPLS lookup, pop, and IP lookup in one pass through the PFE (egress PE of an MPLS VPN tunnel). It was only needed in the case that the device did not have a tunnel services pic installed. I see that the self-study bundle and the day-one book (https://www.juniper.net/documentation/en_US/day-one-books/TW_DCDeployment.v2.pdf) has it configured everywhere. I can also tell you that we don't teach it at all in the ADCX course and I can see an example of pure type 5 here, https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/solutions/evpn-type5-configuring.pdf, that also does not show it configured. My gut feeling is that it doesn't hurt to have it configured but I don't think it is really doing anything. I'm happy to have anyone else enlighten us. ;)

    Hope that helps.

    ------------------------------
    William Pincek
    ------------------------------



  • 9.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-02-2022 20:10
    William,

    Dude, thank you very much for the detail. I'm less confused now than before I read this! I haven't had time to ingest all of this yet, but this did help point me a little bit further down the MAC-VRF rabbit hole.

    My understanding here is that a MAC-VRF cannot exist without an IP-VRF (if my understanding of RFC 9135 is correct). This means two routing-instances for one tenant, which seems....a bit much. That's two unique loopbacks, at least two unique RT / RD each, and BOTH instances have EVPN config in them. Am I alone in thinking this is a ton of config just for one tenant? Am I misunderstanding the use-case?

    For the Type 5 routes - if an engineer configures set protocols evpn ip-prefix-routes​ + options, would that not just advertise Type 5 routes to all neighbors in the EVI, even if they need Type 2/3?

    Perhaps this is answered in one or more RFCs that I haven't fully digested yet. I've currently got 7432, 7348, 8365, 9135, and 9136 open for reading.

    ------------------------------
    Dakota McGee
    ------------------------------



  • 10.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-03-2022 09:54
    Hi Dakota,

    No problem.  I'm glad to help.

    In regards to MAC-VRF, a MAC-VRF has no problem existing without an IP-VRF.  An IP-VRF is only necessary is you need traffic to be routed between VLANs (the device is to act as a L3 gateway).  If you only need L2 Gateway functionality, no need for a VRF just like in the non-MAC-VRF case.

    As far as there being lots of routing-instances to configure...well, unfortunately, that is exactly how it is spelled out in all of the RFCs that you mention. Luckily, especially now with MAC-VRF, the flow of the configuration matches right up to way the RFC describe.

    Just by turning on Type 5's doesn't necessarily stop the advertisement of the rest of the EVPN routes.  It comes down to how your policies are written.  All of the EVPN route types can all happily coexist in a DC. 

    Will

    ------------------------------
    William Pincek
    ------------------------------



  • 11.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-03-2022 09:54
    Edited by Jodi Meier 08-03-2022 18:08

    #4 I never really understood why in the QFX config you seem to have to reference the route target more than once

    I have just tested removing this from my QFX config and lab keeps working perfectly. :-/




    root@vQFX6# del protocols evpn vni-options    
    
    {master:0}[edit]
    root@vQFX6# show | compare 
    [edit protocols evpn]
    -    vni-options {
    -        vni 100 {
    -            vrf-target target:65000:100;
    -        }
    -        vni 200 {
    -            vrf-target target:65000:100;
    -        }
    -    }
    
    {master:0}[edit]
    root@vQFX6# commit 
    
    
    root@vQFX6# run restart routing  # do not do this in production
    Routing protocols process started, pid 4454
    
    ###################
    after 1 mins 
    
    Host1>ping 192.168.200.4
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.200.4, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 119/187/211 ms
    Host1>
    




    MX

    QFX

    all config is within a virtual switch routing instance

    config is is different stanzas ( switch-options, vlans , protocols )

    Config under VIRTUAL SWITCH
     

    [edit routing-instances VS1]


    vtep-source-interface lo0.0;;

    route-distinguisher 10.0.255.3:100;

    vrf-target target:65000:100

     

     

    Config under SWITCH-OPTIONS
     

    {master:0}[edit switch-options]


    vtep-source-interface lo0.0;

    route-distinguisher 10.0.255.6:100;

    vrf-target target:65000:100;

    [edit routing-instances VS1]

     

    bridge-domains {

        bd100 {

            vlan-id none;

            interface ge-0/0/0.100;

            routing-interface irb.100;

            vxlan {

                vni 100;

            }

        }

        bd200 {

            vlan-id none;

            interface ge-0/0/0.200;

            routing-interface irb.200;

            vxlan {                        

                vni 200;

            }

        }

    }

     

     

     

     

    {master:0}[edit vlans]

     

    root@vQFX6# show

    v100 {

        vlan-id 100;

        vxlan {

            vni 100;

        }

    }

    v200 {

        vlan-id 200;

        vxlan {

            vni 200;

        }

    }

     

    [edit routing-instances VS1]


    protocols {

        evpn {

            encapsulation vxlan;

            extended-vni-list [ 100 200 ];

        }

    }



     


    [edit protocols]

    evpn {

        vni-options {

            vni 100 {

                vrf-target target:65000:100;

            }

            vni 200 {

                vrf-target target:65000:100;

            }

        }

        encapsulation vxlan;

        extended-vni-list [ 100 200 ];

    }

    root@vQFX6# del protocols evpn vni-options    
    
    {master:0}[edit]
    root@vQFX6# show | compare 
    [edit protocols evpn]
    -    vni-options {
    -        vni 100 {
    -            vrf-target target:65000:100;
    -        }
    -        vni 200 {
    -            vrf-target target:65000:100;
    -        }
    -    }
    
    {master:0}[edit]
    root@vQFX6# commit 
    
    
    root@vQFX6# run restart routing  # do not do this in production
    Routing protocols process started, pid 4454
    
    ###################
    
    Host1>ping 192.168.200.4
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.200.4, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 119/187/211 ms
    Host1>
    


    ------------------------------
    Simon Bingham
    ------------------------------



  • 12.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-03-2022 10:15
    Edited by Simon Bingham (technical debt collector) 08-03-2022 10:24

    #4 I have an answer for !!

    So I thought this was a difference between the MX and the QFX but it is not, they are the same apart from the location of the "switch options " and "protocols stanza.

    The config under switch options is for Type 1 evpn routes 
     this is the gotca ........

    The Route Target under protocols evpn vni-options is for non type 1 routes and if this is missing the config defaults to the target used under switch options !!! this is why I could remove this in my lab to no effect. 

     in the example below I defined 2 targets !!

    root@mx3# show 
    vtep-source-interface lo0.0;
    instance-type virtual-switch;
    route-distinguisher 10.0.255.3:100;
    vrf-target target:65000:100;
    protocols {
        evpn {
            encapsulation vxlan;
            extended-vni-list [ 100 200 ];
            vni-options {
                vni 100 {
                    vrf-target target:65000:123;
                }
            }
        }
    }

    {master:0}[edit]
    root@vQFX6# show switch-options 
    
    vtep-source-interface lo0.0;
    route-distinguisher 10.0.255.6:100;
    vrf-target target:65000:100;
    
    {master:0}[edit]
    root@vQFX6# show protocols 
    
    evpn {
        vni-options {
            vni 100 {
                vrf-target target:65000:123;
            }
        }
        encapsulation vxlan;
        extended-vni-list [ 100 200 ];
    }
    

    See how the the type 1 and type 2 are advertised with different targets 

    root@mx3# run show route advertising-protocol bgp 10.0.255.6 extensive 
    
    
    * 1:10.0.255.3:0::0500000000000000c800::FFFF:FFFF/192 AD/ESI (1 entry, 1 announced)
     BGP group overlay type Internal
         Route Distinguisher: 10.0.255.3:0
         Route Label: 1
         Nexthop: Self
         Localpref: 100
         AS path: [65200] I 
         Communities: target:65000:100 encapsulation:vxlan(0x8) esi-label:0x0:all-active (label 0)
                                            
    
    * 2:10.0.255.3:100::100::aa:bb:cc:11:11:11/304 MAC/IP (1 entry, 1 announced)
     BGP group overlay type Internal
         Route Distinguisher: 10.0.255.3:100
         Route Label: 100
         ESI: 00:00:00:00:00:00:00:00:00:00
         Nexthop: Self
         Localpref: 100
         AS path: [65200] I 
         Communities: target:65000:123 encapsulation:vxlan(0x8)

    I have no idea of the use case for this. 



    ------------------------------
    Simon Bingham
    ------------------------------



  • 13.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-04-2022 14:31
    Simon,

    This is a very good find! Thanks for sharing!

    Like you, I have zero idea for the use case. I'm finding that with many of the tasks in the JNCIE workbook so far. Cool to know that we can do such things I guess, but how realistic is it?

    ------------------------------
    Dakota McGee
    ------------------------------



  • 14.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-04-2022 13:58
    Dakota,

    I did a bit of research on number 5 and found that this (vrf-table-label) configuration is not needed with EVPN-VXLAN. It is only needed when doing type 5 routes with EVPN-MPLS. I agree with Will, that it should not hurt anything to have it configured but it is not needed in these scenarios.


    ------------------------------
    Josh Verhaal
    ------------------------------



  • 15.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-04-2022 14:33
    Josh,

    Thanks very much for the follow-up.

    This jives with what I found about the knob too. Probably shouldn't be in the solutions section of the JNCIE-DC workbook if it's not needed. For people like me that want to understand everything it is that I'm doing, this leads us down unnecessary rabbit holes that don't really contribute much to growth as an engineer.

    ------------------------------
    Dakota McGee
    ------------------------------



  • 16.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-05-2022 04:19
    Edited by Simon Bingham (technical debt collector) 08-05-2022 04:19

    on #2 mac VRF, this is a 20.4 feature, 

    Additionally  the JNCIE-DC blue print mentions

    • vQFX Virtual Switch: 21.3
    • vSRX Virtual Firewall: 20.2
    • vMX Virtual Router: 20.4

    the vQFX beyond 20.2 is not available for download​.  does anyone know how we obtain this for the JNCIE-DC exam ?

    ------------------------------
    Simon Bingham
    ------------------------------



  • 17.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-08-2022 15:51
    I don't know where you can get a copy of the vQFX image for a personal lab, but you do have access to that versions through the Self Study Bundle.

    ------------------------------
    Josh Verhaal
    ------------------------------



  • 18.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-09-2022 09:46
    Hi,


    Yes i'm also search how to get vQFX Virtual Switch: 21.3.

    Thanks


  • 19.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-09-2022 14:55

    RE vQFX image Thanks but that does not really fly for most engineers, finding 12 hour blocks to study is not really feasible, I myself use early morning before work. 

    and most people build their own representations of the SSB LAB allowing us to use time more effectively.  Why can juniper just not make this available for the engineering community.



    ------------------------------
    Simon Bingham
    ------------------------------



  • 20.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-09-2022 19:24
    Hi,


    Yes, I'm agreed. I hope juniper can put the latest version vQFX image same as JNCIE-DC Bundle lab (21.3) into public download page like the old version.


    Thanks


  • 21.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-09-2022 22:48
    #2
    Not sure if that was mentioned, but MAC-VRF allows overlapping VLANs, which is very important for multi-tenant environments. EVPN has its own route tables, which requires their own RD/RT.
     
    #4 
    Here are some notes I took after testing and observing:
    Sets VRF target for all EVPN NLRIs (if no other setting is set)

    set switch-options vrf-target target:XXX:XX

     

    Possible to set different target per VNI

    set protocols evpn vni-options XXXXX vrf-target XXXX:XX

     

    If set, type 2-3 vrf target is automatically derived from AS (set routing-options autonomous-system) and VNI

    set switch-options vrf-target auto

     

    If vrf-target auto is set AND AS is different on all VTEP enabled nodes, it won't work. Have to set same AS and modify local-as in BGP groups

    set routing-optons autonomous-system 65027

    delete protocols bgp group OVERLAY local-as

    set protocols bgp group UNDERLAY local-as 65025

     

    Other solution: if AS must not be changed under routing-options, other option is to specify the import AS number for auto-derived route-targets

    set switch-options vrf-target auto import-as 65026 vni-list all

    set switch-options vrf-target auto import-as 65023 vni-list all


    Auto-derived vrf-targets is described in https://www.rfc-editor.org/rfc/rfc8365.html

    I believe all these options is for interoperability with other vendors/implemetation methods.


    ​​

    ------------------------------
    FELIX FAFARD
    ------------------------------



  • 22.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-12-2022 03:51
    Hi all,

    Any one here know why in the latest/updated JNCIE-DC bundle self study (Super Lab 2) have bgp not establish? As per i'm understand supposedly when we load the final config all should working properly.


    {master:0}
    jncie@DC3-LEAF1> show bgp summary
    Threading mode: BGP I/O
    Default eBGP mode: advertise - accept, receive - accept
    Groups: 2 Peers: 4 Down peers: 1
    Table Tot Paths Act Paths Suppressed History Damp State Pending
    inet.0
    60 40 0 0 0 0
    bgp.evpn.0
    175 175 0 0 0 0
    Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    10.254.3.4 65031 78 58 0 0 15:25 Establ
    inet.0: 15/32/32/0
    10.254.3.6 65032 77 59 0 0 15:32 Establ
    inet.0: 25/28/28/0
    172.31.1.5 65015 0 0 0 0 16:49 Active
    172.31.2.5 65025 140 50 0 0 14:00 Establ
    bgp.evpn.0: 175/175/175/0
    tenant1.evpn.0: 12/12/12/0
    tenant2.evpn.0: 12/12/12/0
    tenant4.evpn.0: 0/0/0/0
    default-switch.evpn.0: 102/102/102/0
    __default_evpn__.evpn.0: 0/0/0/0


    Thanks and appreciate any feedback


  • 23.  RE: JNCIE-DC topics and documentation - need more detail

    Posted 08-12-2022 11:50
    Felix,

    Apologies for the late reply. I've been sick for a couple of weeks and unable to muster the strength to study.

    Thank you for posting your notes here on the #4 and clarification on #2. Both of these pieces of information I find highly valuable. I didn't know that MAC-VRF allowed for overlapping of VIDs, but that makes sense. I've not yet had the opportunity to work on a network large enough to have a use-case for that, but I can see service providers needing it.
    ​Thanks again.

    ------------------------------
    Dakota McGee
    ------------------------------