SD Access inter fabric transit

[KevinR99]

Hi

I am lab testing multiple SD Access fabrics using one Catalyst Center deployment.  At the moment I am deploying an IP transit between each fabric's Borders because I have no requirement to extend SGT's between fabrics.

I connect the Borders for each fabric site together and configure the L3 hand off as usual on each Border mirroring the neighbor statements and BGP AS number at each end.  Fabric 1 has AS xxxxx and Fabric 2 has AS yyyyy.  So with BGP built in loop avoidance each Border would reject routes with their own AS number in the AS path.  However, Catalyst Centre pushes out a community list to each Border both setting fabric routes with the same community and then dropping routes it sees with that community.  So each Border drops any routes from the other Border in the other fabric.  There are descriptions against this config effectively saying it is to drop looped fabric routes.  I don't want this to be done otherwise I have no communication between subnets in different fabrics.  As I said, BGP will handle looped routes with the AS path check.

So my question is, am I ok to remove the neighbor x.x.x.x route-map DENY_xxxxx commands to ensure each Border accepts routes from the other fabric?

I would have expected Catalyst Center to have assigned a different community to each fabric.  In that case the route-map to drop routes would only apply to the fabrics own routes.

Any help appreciated, Kev.

[KevinR99]

As an update to this issue.

I have 2 fabrics each with their own Border.  I do an IP transit between the Borders.  When I deploy an Anycast gateway in one fabric in the BGP commands DNAC deploys the following command under BGP

aggregate-address x.x.x.0 255.255.255.0 summary-only attribute-map SET_FABRIC_SUBNET_COMMUNITY

If I look at the attribute map/route map it is setting a community value as follows

route-map SET_FABRIC_SUBNET_COMMUNITY, permit, sequence 5
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
community 955999

However, when I look at the BGP peering statement on the other Border it applies a filter against the neighbor

neighbor x.x.x.x route-map DROP_FABRIC_ROUTES in

And that associated route-map matches on community 955999 too.  So any routes coming from my other fabric's Border are dropped.

If I remove the neighbor filter it all works but why woud it apply a filter that drops routes from another attached fabric?

Thanks, Kev.

[willwetherman]

Hi @KevinR99,

I wouldnt recommend changing any configuraiton that is automated by Catalyst Center as there is a risk that the configuration will changed back.

The configuration that you highlighed above is an additional mechanism to prevent loops in the event that an overlay prefix originating from the local fabric site is received over the IP transit from a remote fabric site, which is possible when you configure SDA Transit with IP transit enabled at another site.

Typically you wouldnt connect the border nodes of two seperate fabric sites directly togther with IP transit as described above. Instead, the border nodes for the different fabric sites would connect to a central core switch/firewall, with the core switch/firewall only advertising a default route down to the borders (if using external borders).

Amending the route maps isnt an issue if this is for just lab testing, but I would avoid this in a production enviroment. Also just to note that you dont need to configure BGP for the border handoff to your IP transit, static routes and other routing protocols will also work but will need to be configured manually.

[KevinR99]

Thank you for your reply.

By using BGP itself it has a built in loop avoidance method by dropping any prefixes that have the receiving router's AS number in it.  So I don't understand the need for this additional prefix list/route-map method.  I could understand it if DNAC pushed out a different community string per fabric but it doesn't.  With a community string per fabric the prefix list would then only drop routes seen that were originated from within that fabric.

Since each fabric uses a different BGP AS then AS-PATH would seem a sufficient method of loop avoidance.

Regarding the central core switches, my Borders on each fabric site are the central Core switches.  The only way between the fabric sites are via the Borders.

Kev.