Extending connectivity to IaaS

[visasman]

Dear all

I see that some vendor solutions recommend advertising HQ summary routes 10.1.0.0/16 to IaaS R30 (see config below). Is it really necessary? Or has anyone done so in their exam? Please share your thoughts.

This is the hidden content, please

• Sign In
• or
• Sign Up

 

[Siscco]

I have not done that in my Real LAB.

[visasman]

I too did not do it in my last attempt. But in the latest workbook, the main task asks to make HQ FABD2 site mutual visibility with the IaaS site for both IPv4 and IPv6 routes. This can only be configured in R3 & R4 by using an additional route target value 10000:3681.

I understand IPv6, but the mutual visibility of IPv4 is unclear. When R4 sends HQ summary routes 10.1.0.0/16, which giosk IPv4 routes will advertise to R3?

 

My Solution: 

• IaaS has already configured route-target 10000:414 (IPv6: 2001:db8:14::1/128).
• We need to use route-target 10000:3681 for HQ routes (IPv4: 10.1.0.0/16, IPv6: 2001:db8:1:xxx::/64)
• In R3, set route-target export/import for vrf 'fabd2':

              vrf definition fabd2
                   route-target export 10000:3681
                   route-target import 10000:414
    

• In R4, set route-target export/import for vrf 'giosk':

            vrf definition giosk
                 route-target import 10000:3681
                 route-target export 10000:414 (this is preconfigured)

   

[johnnyboy]

Are you sure we're it doesn't mean we advertise the summarized subnet in the form of an aggregate address?

[ShoIProute]

On 2/20/2023 at 3:36 AM, visasman said:

Dear all

I see that some vendor solutions recommend advertising HQ summary routes 10.1.0.0/16 to IaaS R30 (see config below). Is it really necessary? Or has anyone done so in their exam? Please share your thoughts.

This is the hidden content, please

• Sign In
• or
• Sign Up

 

I think this makes sense in a way. Because if r3 is importing RT 10000:414 (giosk vrf routes), then wouldn't that give all of the fabd2 sites reachability to the IPv4 prefixes from the IaaS site? And I think r4 is importing IPv4 and IPv6 prefixes from all of the Fabd2 sites by using the "route-target import 10000:3681" since it's not specifying an address-family.

Can anyone confirm if any of the other fabd2 sites receive the IaaS prefixes and vice versa? I'm not where I can test this out right now at the moment.

 

If they do receive the prefixes, then I guess there needs to be some way to filter them from getting to the IaaS site in order to fulfil the requirement:

"Prevent the IaaS site from possibly learning about the routes on any other FABD2 site"

 

And it still has to meet the requirement:

"Use the minimum number of commands necessary to accomplish this requirements. Do not remove any existing configuration."

 

With that solution, if r4 advertises only prefixes from HQ's IPv4 space (10.1.0.0/16), then the IaaS site would never learn about any other FABD2 sites (except for HQ), fulfilling the requirement. If I'm thinking about this right. 

[ShoIProute]

4 hours ago, visasman said:

I too did not do it in my last attempt. But in the latest workbook, the main task asks to make HQ FABD2 site mutual visibility with the IaaS site for both IPv4 and IPv6 routes. This can only be configured in R3 & R4 by using an additional route target value 10000:3681.

I understand IPv6, but the mutual visibility of IPv4 is unclear. When R4 sends HQ summary routes 10.1.0.0/16, which giosk IPv4 routes will advertise to R3?

 

My Solution: 

• IaaS has already configured route-target 10000:414 (IPv6: 2001:db8:14::1/128).
• We need to use route-target 10000:3681 for HQ routes (IPv4: 10.1.0.0/16, IPv6: 2001:db8:1:xxx::/64)
• In R3, set route-target export/import for vrf 'fabd2':

              vrf definition fabd2
                   route-target export 10000:3681
                   route-target import 10000:414
    

• In R4, set route-target export/import for vrf 'giosk':

            vrf definition giosk
                 route-target import 10000:3681
                 route-target export 10000:414 (this is preconfigured)

   

^^^^ This is exactly how I configure the route-targets on r3 and r4 as well.

Be careful not to simply use "route-target (both) 10000:3681" on r3 and r4, because u will end up with 4 commands instead of 3.

It would look like this in the running-config:

 

(On r3):

vrf definition fabd2
                   route-target export 10000:3681
                   route-target import 10000:3681

 

(On r4):

vrf definition fabd2
                   route-target export 10000:3681
                   route-target import 10000:3681

 

U want to use the minimum number of commands for this solution