[j-nsp] "community set" vs "community add"
Mihai
mihaigabriel at gmail.com
Thu Oct 31 16:06:32 EDT 2013
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:mihaigabriel at gmail.com]
> Sent: Thursday, October 31, 2013 12:19 PM
> To: Harry Reynolds
> Cc: EXT - ipv6freely at gmail.com; juniper-nsp at 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-bounces at puck.nether.net] On Behalf Of Mihai
>> Sent: Thursday, October 31, 2013 11:53 AM
>> To: EXT - ipv6freely at gmail.com
>> Cc: juniper-nsp at 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 <mihaigabriel at gmail.com
>>> <mailto:mihaigabriel at 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 at puck.nether.net
>>> <mailto:juniper-nsp at 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 at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
>
>
More information about the juniper-nsp
mailing list