Hi guys, I apologize for not having followed this thread in detail, but generally we've avoided to allow iBGP route reflectors to manipulate a fair amont of attributes in out policies... Now, this being in an Internet routing context, your VP* needs may be different? For my culture, please let know.
Cheers, mh Le 31/10/2013 21:06, Mihai a écrit : > You are totally right, thank you very much. > > Regards, > > On 10/31/2013 09:50 PM, Harry Reynolds wrote: >> Perhaps when you use set, which strips the existing comm. set as >> mentioned, this includes the "Layer2 Info Extended Community" as per >> rfc 4761, which is needed to signal bgp based vpls. >> >> Seems you go from this: >> >> Communities: target:10:10 Layer2-info: encaps: >> VPLS, control flags:[0x0] , mtu: 0, site preference: 100 >> >> To this: >> >> >> Communities: target:10:10 >> >> I belive that would explain why add, which leaves the existing set >> intact, is working. >> >> Regards >> >> >> >> -----Original Message----- >> From: Mihai [mailto:mihaigabr...@gmail.com] >> Sent: Thursday, October 31, 2013 12:19 PM >> To: Harry Reynolds >> Cc: EXT - ipv6fre...@gmail.com; juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] "community set" vs "community add" >> >> I agree, but I don't think you understand what I am trying to do. >> Let's take it step by step: >> >> - z advertises l2vpn route to RR q >> >> >> z> show route advertising-protocol bgp 20.20.20.3 detail >> >> mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 >> hidden) >> * 20:20:2:1/96 (1 entry, 1 announced) >> BGP group ibgp type Internal >> Route Distinguisher: 20:20 >> Label-base: 800000, range: 8 >> Nexthop: Self >> Flags: Nexthop Change >> Localpref: 100 >> AS path: [65550] I >> Communities: target:20:20 Layer2-info: encaps: VPLS, control >> flags:[0x0] , mtu: 0, site preference: 100 >> >> - the RR should replace the community "target:20:20" advertised by z >> with "target:10:10" and the advertise the prefix to x (RR client) >> >> q# run show route table bgp.l2vpn.0 detail >> >> bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) >> 10:10:1:1/96 (1 entry, 1 announced) >> *BGP Preference: 170/-101 >> Route Distinguisher: 10:10 >> Next hop type: Indirect >> Address: 0x26ec814 >> Next-hop reference count: 1 >> Source: 20.20.20.1 >> Protocol next hop: 20.20.20.1 >> Indirect next hop: 2 no-forward INH Session ID: 0x0 >> State: <Active Int Ext> >> Local AS: 65550 Peer AS: 65550 >> Age: 3:13:27 Metric2: 1 >> Validation State: unverified >> Task: BGP_65550.20.20.20.1+58349 >> Announcement bits (1): 0-BGP_RT_Background >> AS path: I >> Communities: target:10:10 Layer2-info: encaps: >> VPLS, control flags:[0x0] , mtu: 0, site preference: 100 >> Accepted >> Label-base: 800000, range: 8 >> Localpref: 100 >> Router ID: 20.20.20.1 >> >> >> - x accepts the l2vpn route from RR and place it in the vrf-l2vpn table >> >> x> show route receive-protocol bgp 20.20.20.3 table mihai-vpls.l2vpn.0 >> detail >> >> mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 >> hidden) >> * 20:20:2:1/96 (1 entry, 0 announced) >> Import Accepted >> Route Distinguisher: 20:20 >> Label-base: 800000, range: 8, status-vector: 0x0 >> Nexthop: 20.20.20.2 >> Localpref: 100 >> AS path: I (Originator) >> Cluster list: 0.0.0.1 >> Originator ID: 20.20.20.2 >> Communities: target:10:10 >> >> Now, x should have a vpls connection up,but this is not the case when >> the policy used on RR for changing the community target:20:20 to >> target:10:10 is this: >> >> q# show policy-statement from-z >> term 10 { >> from { >> protocol bgp; >> community vpls-z; >> } >> then { >> community set vpls-x; >> accept; >> } >> } >> >> q# top show protocols bgp >> group ibgp { >> type internal; >> local-address 20.20.20.3; >> family l2vpn { >> signaling; >> } >> cluster 0.0.0.1; >> neighbor 20.20.20.1; >> neighbor 20.20.20.2 { >> import from-z; >> export to-z; >> } >> } >> >> >> x> show vpls connections >> >> Legend for interface status >> Up -- operational >> Dn -- down >> >> Instance: mihai-vpls >> Local site: a (1) >> No connections found. >> >> >> >> >> If I change the policy to: >> >> q# show policy-statement from-z >> term 10 { >> from { >> protocol bgp; >> community vpls-z; >> } >> then { >> community delete vpls-z; >> community add vpls-x; >> accept; >> } >> } >> >> then vpls comes up: >> >> Legend for interface status >> Up -- operational >> Dn -- down >> >> Instance: mihai-vpls >> Local site: a (1) >> connection-site Type St Time last up # >> Up trans >> 2 rmt Up Oct 31 21:23:39 >> 2013 1 >> Remote PE: 20.20.20.2, Negotiated control-word: No >> Incoming label: 800001, Outgoing label: 800000 >> Local interface: vt-1/0/10.235929856, Status: Up, >> Encapsulation: VPLS >> Description: Intf - vpls mihai-vpls local site 1 remote site 2 >> >> >> >> >> >> On 10/31/2013 08:58 PM, Harry Reynolds wrote: >>> If memory serves, the add adds to what is there, while set replaces >>> what was there with what you are now adding. One appends, the other >>> replaces, so not the same. >>> >>> Regards >>> >>> >>> >>> -----Original Message----- >>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On >>> Behalf Of Mihai >>> Sent: Thursday, October 31, 2013 11:53 AM >>> To: EXT - ipv6fre...@gmail.com >>> Cc: juniper-nsp@puck.nether.net >>> Subject: Re: [j-nsp] "community set" vs "community add" >>> >>> Aren't these 2 policies the same thing? >>> >>> >>> policy-statement from-z { >>> term 10 { >>> from { >>> protocol bgp; >>> community vpls-z; >>> } >>> then { >>> community delete vpls-z; >>> community add vpls-x; >>> accept; >>> } >>> } >>> } >>> >>> >>> >>> policy-statement from-z { >>> term 10 { >>> from { >>> protocol bgp; >>> community vpls-z; >>> } >>> then { >>> community set vpls-x; >>> accept; >>> } >>> } >>> } >>> >>> >>> >>> On 10/31/2013 08:46 PM, Chris Jones wrote: >>>> set replaces all values with just the one specified. >>>> add adds the specified community to the already existing list >>>> >>>> >>>> On Thu, Oct 31, 2013 at 9:25 AM, Mihai <mihaigabr...@gmail.com >>>> <mailto:mihaigabr...@gmail.com>> wrote: >>>> >>>> Hello, >>>> >>>> Using a simple topology with 2 PE's and one RR I am trying to >>>> establish a vpls connection between PE's using different >>>> route-targets. >>>> I am using the RR to rewrite the communities, but using >>>> "community >>>> set" instead of "community add" results in a "No connections >>>> found" >>>> message on both PE's. >>>> >>>> x and z are PE's, q is RR >>>> >>>> x> show configuration routing-instances mihai-vpls >>>> instance-type vpls; >>>> vlan-id 880; >>>> interface ge-1/1/6.880; >>>> route-distinguisher 10:10; >>>> vrf-target target:10:10; >>>> protocols { >>>> vpls { >>>> site a { >>>> site-identifier 1; >>>> } >>>> } >>>> } >>>> >>>> z> show configuration routing-instances mihai-vpls >>>> instance-type vpls; >>>> vlan-id 880; >>>> interface ge-1/1/7.980; >>>> route-distinguisher 20:20; >>>> vrf-target target:20:20; >>>> protocols { >>>> vpls { >>>> site b { >>>> site-identifier 2; >>>> } >>>> } >>>> } >>>> >>>> q# show policy-options >>>> policy-statement from-z { >>>> term 10 { >>>> from { >>>> protocol bgp; >>>> community vpls-z; >>>> } >>>> then { >>>> community set vpls-x; >>>> accept; >>>> } >>>> } >>>> } >>>> policy-statement to-z { >>>> term 10 { >>>> from { >>>> protocol bgp; >>>> community vpls-x; >>>> } >>>> then { >>>> community set vpls-z; >>>> accept; >>>> } >>>> } >>>> } >>>> community vpls-x members target:10:10; >>>> community vpls-z members target:20:20; >>>> >>>> >>>> ------------------------------__------------------------------__---- >>>> >>>> >>>> x> show vpls connections >>>> Layer-2 VPN connections: >>>> >>>> Legend for connection status (St) >>>> EI -- encapsulation invalid NC -- interface >>>> encapsulation not >>>> CCC/TCC/VPLS >>>> EM -- encapsulation mismatch WE -- interface and instance >>>> encaps >>>> not same >>>> VC-Dn -- Virtual circuit down NP -- interface hardware not >>>> present >>>> CM -- control-word mismatch -> -- only outbound >>>> connection is up >>>> CN -- circuit not provisioned <- -- only inbound >>>> connection is up >>>> OR -- out of range Up -- operational >>>> OL -- no outgoing label Dn -- down >>>> LD -- local site signaled down CF -- call admission control >>>> failure >>>> RD -- remote site signaled down SC -- local and remote site ID >>>> collision >>>> LN -- local site not designated LM -- local site ID not minimum >>>> designated >>>> RN -- remote site not designated RM -- remote site ID not >>>> minimum >>>> designated >>>> XX -- unknown connection status IL -- no incoming label >>>> MM -- MTU mismatch MI -- Mesh-Group ID not >>>> available >>>> BK -- Backup connection ST -- Standby connection >>>> PF -- Profile parse failure PB -- Profile busy >>>> RS -- remote site standby SN -- Static Neighbor >>>> LB -- Local site not best-site RB -- Remote site not best-site >>>> VM -- VLAN ID mismatch >>>> >>>> Legend for interface status >>>> Up -- operational >>>> Dn -- down >>>> >>>> Instance: mihai-vpls >>>> Local site: a (1) >>>> No connections found. >>>> >>>> x> show route table mihai-vpls.l2vpn.0 detail >>>> >>>> mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 >>>> holddown, >>>> 0 hidden) >>>> 10:10:1:1/96 (1 entry, 1 announced) >>>> *L2VPN Preference: 170/-101 >>>> Next hop type: Indirect >>>> Address: 0x26d8270 >>>> Next-hop reference count: 2 >>>> Protocol next hop: (null) >>>> Indirect next hop: 0 - INH Session ID: 0x0 >>>> State: <Active Int Ext> >>>> Age: 22:36 Metric2: 1 >>>> Validation State: unverified >>>> Task: mihai-vpls-l2vpn >>>> Announcement bits (1): 1-BGP_RT_Background >>>> AS path: I >>>> Communities: Layer2-info: encaps: VPLS, control >>>> flags:[0x0] , mtu: 0, site preference: 100 >>>> Label-base: 800000, range: 8, status-vector: >>>> 0x7F >>>> >>>> 20:20:2:1/96 (1 entry, 0 announced) >>>> *BGP Preference: 170/-101 >>>> Route Distinguisher: 20:20 >>>> Next hop type: Indirect >>>> Address: 0x26d8990 >>>> Next-hop reference count: 2 >>>> Source: 20.20.20.3 >>>> Protocol next hop: 20.20.20.2 >>>> Indirect next hop: 2 no-forward INH Session >>>> ID: 0x0 >>>> State: <Secondary Active Int Ext> >>>> Local AS: 65550 Peer AS: 65550 >>>> Age: 3:10 Metric2: 1 >>>> Validation State: unverified >>>> Task: BGP_65550.20.20.20.3+179 >>>> AS path: I (Originator) >>>> Cluster list: 0.0.0.1 >>>> Originator ID: 20.20.20.2 >>>> Communities: target:10:10 >>>> Import Accepted >>>> Label-base: 800000, range: 8, status-vector: >>>> 0x0 >>>> Localpref: 100 >>>> Router ID: 20.20.20.3 >>>> Primary Routing Table bgp.l2vpn.0 >>>> >>>> >>>> z> show route table mihai-vpls.l2vpn.0 detail >>>> >>>> mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 >>>> holddown, >>>> 0 hidden) >>>> 10:10:1:1/96 (1 entry, 0 announced) >>>> *BGP Preference: 170/-101 >>>> Route Distinguisher: 10:10 >>>> Next hop type: Indirect >>>> Address: 0x26d8990 >>>> Next-hop reference count: 2 >>>> Source: 20.20.20.3 >>>> Protocol next hop: 20.20.20.1 >>>> Indirect next hop: 2 no-forward INH Session >>>> ID: 0x0 >>>> State: <Secondary Active Int Ext> >>>> Local AS: 65550 Peer AS: 65550 >>>> Age: 2:55 Metric2: 1 >>>> Validation State: unverified >>>> Task: BGP_65550.20.20.20.3+62459 >>>> AS path: I (Originator) >>>> Cluster list: 0.0.0.1 >>>> Originator ID: 20.20.20.1 >>>> Communities: target:20:20 >>>> Import Accepted >>>> Label-base: 800000, range: 8 >>>> Localpref: 100 >>>> Router ID: 20.20.20.3 >>>> Primary Routing Table bgp.l2vpn.0 >>>> >>>> 20:20:2:1/96 (1 entry, 1 announced) >>>> *L2VPN Preference: 170/-101 >>>> Next hop type: Indirect >>>> Address: 0x26d8270 >>>> Next-hop reference count: 2 >>>> Protocol next hop: (null) >>>> Indirect next hop: 0 - INH Session ID: 0x0 >>>> State: <Active Int Ext> >>>> Age: 22:21 Metric2: 1 >>>> Validation State: unverified >>>> Task: mihai-vpls-l2vpn >>>> Announcement bits (1): 1-BGP_RT_Background >>>> AS path: I >>>> Communities: Layer2-info: encaps: VPLS, control >>>> flags:[0x0] , mtu: 0, site preference: 100 >>>> Label-base: 800000, range: 8, status-vector: >>>> 0xBF >>>> >>>> >>>> ----------------------------- >>>> >>>> >>>> If I change the policies on RR then vpls comes up: >>>> >>>> q# show policy-options >>>> policy-statement from-z { >>>> term 10 { >>>> from { >>>> protocol bgp; >>>> community vpls-z; >>>> } >>>> then { >>>> community delete vpls-z; >>>> community add vpls-x; >>>> accept; >>>> } >>>> } >>>> } >>>> policy-statement to-z { >>>> term 10 { >>>> from { >>>> protocol bgp; >>>> community vpls-x; >>>> } >>>> then { >>>> community delete vpls-x; >>>> community add vpls-z; >>>> accept; >>>> } >>>> } >>>> } >>>> community vpls-x members target:10:10; >>>> community vpls-z members target:20:20; >>>> >>>> x> show vpls connections | find connection-site >>>> connection-site Type St Time last >>>> up # >>>> Up trans >>>> 2 rmt Up Oct 31 18:22:35 2013 >>>> 1 >>>> Remote PE: 20.20.20.2, Negotiated control-word: No >>>> Incoming label: 800001, Outgoing label: 800000 >>>> Local interface: vt-1/1/10.235929600, Status: Up, >>>> Encapsulation: VPLS >>>> Description: Intf - vpls mihai-vpls local site 1 remote >>>> site 2 >>>> >>>> >>>> I can't understand what's the problem here. >>>> >>>> Regards, >>>> Mihai >>>> _________________________________________________ >>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>> <mailto:juniper-nsp@puck.nether.net> >>>> https://puck.nether.net/__mailman/listinfo/juniper-nsp >>>> <https://puck.nether.net/mailman/listinfo/juniper-nsp> >>>> >>>> >>>> >>>> >>>> -- >>>> Chris Jones >>>> JNCIE-ENT #272 >>>> CCIE# 25655 (R&S) >>> _______________________________________________ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >>> >>> >> >> > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp