DOO 1.15

[jeytop]

What is the configuration that you think s proper for this point ? i mean vrf fabd2 is in use for DC and HQ:

By configuring r3 and r4 only, ensure that the HQ FABD2 site will have mutual visibility with the IaaS site for all IPv6 and IPv4 prefixes received from these sites while preventing :

* Any other FABD2 site from possibly learning about the routes on the IaaS site 

* The IaaS site from possibly learning about the routes on any other FABD2 site

[there]

Hello

You need to export the vrf fabd2 address-family ipv6 with the route-target 10000:3681 on R3 and import this route-target in vrf Giosk address-family ipv6 on r 4

Also import the route-target from vrf giosk 10000:414 on R3

 

[jeytop]

yes, that is my solution but, are we preventing other fabd2 sites from learning iass prefixes? if r21 and 3 establish ipv6 bgp peering r21 will start to receive prefiex from iaas site.

[CCIEstudent]

Global SP#1 running ISP setup, R3, R4, R5, R6 has VRF's , it's  "PE" and R1 & R2 are "P", if R3 & R21 build IPv6 peering defiantly DC will have reachability to IaaS from R21. 
 

Understand MPLS label and Label will be assigned on /32,  " show mpls ldp bindings " Also " show ip cef" to understand the behavior and  verify lablel , loopback must be /32 in SP#1 to distribute the labels.

[visasman]

Folks, I have an issue with this section. My configs are shown below. R11/R3 BGP learned routes are not becoming best routes, it not getting installed in the RIB which resulting host11/12 in HQ unable to ping R30 IaaS. Can someone shed light where the mistake is.

 

This is the hidden content, please

• Sign In
• or
• Sign Up

 

[caohieu089]

43 minutes ago, visasman said:

Folks, I have an issue with this section. My configs are shown below. R11/R3 BGP learned routes are not becoming best routes, it not getting installed in the RIB which resulting host11/12 in HQ unable to ping R30 IaaS. Can someone shed light where the mistake is.

 

Hidden Content

• Give reaction or reply to this topic to see the hidden content.

 

This route learned from unavailable next-hop in your BGP ASN. Try to next-hop-self on PE Router connect to different ASN in your BGP ASN Topology

[Jim]

38 minutes ago, caohieu089 said:

This route learned from unavailable next-hop in your BGP ASN. Try to next-hop-self on PE Router connect to different ASN in your BGP ASN Topology

I think the export from giosk vrf is missing

route-export 10000:414

 

[caohieu089]

23 minutes ago, Jim said:

I think the export from giosk vrf is missing

route-export 10000:414

 

I don't think so, because he's showing from global RIB/Routing Table, not showing on VRF Routing Table.

[visasman]

Folks, thanks sharing your comments.

The IPv6 next-hop address 2001:2710:311::/64 is a directly connected network in R11 & R4 eth0/0 interface. Moreover, we use a route-map in the inbound direction to use this address as IPv6 next-hop. So I don't think the unavailability of the next-hop can be the problem. 

Could something be the cause of it?

 

FYI - I have scheduled my EI lab exam  this end of the month. I appreciate all your guidance and support here.

[visasman]

8 hours ago, visasman said:

Folks, thanks sharing your comments.

The IPv6 next-hop address 2001:2710:311::/64 is a directly connected network in R11 & R4 eth0/0 interface. Moreover, we use a route-map in the inbound direction to use this address as IPv6 next-hop. So I don't think the unavailability of the next-hop can be the problem. 

Could something be the cause of it?

 

FYI - I have scheduled my EI lab exam  this end of the month. I appreciate all your guidance and support here.

Well, I also tried adding next-hop-self command on both R11 & R3, no good happened. 

[Siscco]

6 hours ago, visasman said:

Well, I also tried adding next-hop-self command on both R11 & R3, no good happened. 

Try Adding eBGP Multihop <2> , Happened with me while practicing. However never happened in real exam.

[snowblack]

14 hours ago, visasman said:

Well, I also tried adding next-hop-self command on both R11 & R3, no good happened. 

Try remove next-hop-self. You shouldn't use it. Next-hop-seft just use for peer with same AS.

[visasman]

14 hours ago, Siscco said:

Try Adding eBGP Multihop <2> , Happened with me while practicing. However never happened in real exam.

This solution solved the problem, thank you very much 🙂

[Jim]

On 1/19/2023 at 11:06 AM, visasman said:

This solution solved the problem, thank you very much 🙂

In the real exam, I got it working with route-map on R3 and R11 and the vrf import and export between R3 and R4. Be careful not to use some long route-map name in real exam,  you want to keep it short as possible.. i.e instead of "NEXTHOP-IPV6" why not "NH6". 

[visasman]

17 hours ago, Jim said:

In the real exam, I got it working with route-map on R3 and R11 and the vrf import and export between R3 and R4. Be careful not to use some long route-map name in real exam,  you want to keep it short as possible.. i.e instead of "NEXTHOP-IPV6" why not "NH6". 

Yeah, will keep the naming short. Thanks!

In the real lab, the solution you said works.. During the lab practice, it needs additional command 'ebgp multihop'. 

[LazerFokus]

Can I ask why we want to keep the naming short in the real lab? Does this apply for all naming conventions, for example templates in SD-WAN and SDA?

[visasman]

On 1/26/2023 at 2:01 AM, LazerFokus said:

Can I ask why we want to keep the naming short in the real lab? Does this apply for all naming conventions, for example templates in SD-WAN and SDA?

The matter of saving time and keeping it simple. Long name may lead to typo.

[mindset]

thx