> Of Sander Steffann > Sent: Wednesday, May 30, 2018 9:36 AM > > Hi, > > > But in this scenario, a client will send an update both to RR1 and > > RR2, and RR1 will reflect this update to RR2, and RR2 will reflect it > > to RR1, and voila! We have a routing loop. > > The moment it loops back to an RR that it has already been through it will see > its own cluster-id in the list and ignore it. So RR1 and RR2 learn from each > other, but the update won't loop. > The example suggested RR1 and RR2 with different Cluster-IDs -so it would loop* -but will be dropped by the originating PE based on the Originator-ID.
That's why if you should not be connecting RR1 and RR2s (maybe with the exception where BGP sessions = physical links, between all nodes involved) *it will loop only in absence of PE1 route sent directly to RR2 -in which case RR2 will be comparing PE1's route received via RR1 and route received directly from PE1, the direct route will be selected based on the shorter cluster-list and as such will not be looped/advertised back to PE1 based on the split horizon rule. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
