[j-nsp] "community set" vs "community add"
Mihai
mihaigabriel at gmail.com
Thu Oct 31 15:18:30 EDT 2013
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