[j-nsp] "community set" vs "community add"
Mihai
mihaigabriel at gmail.com
Thu Oct 31 15:21:39 EDT 2013
Sorry, the prefix advertised by z is this
q# run show route table bgp.l2vpn.0 detail | find "20:20:2:1/96"
20:20:2:1/96 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 20:20
Next hop type: Indirect
Address: 0x26ec990
Next-hop reference count: 1
Source: 20.20.20.2
Protocol next hop: 20.20.20.2
Indirect next hop: 2 no-forward INH Session ID: 0x0
State: <Active Int Ext>
Local AS: 65550 Peer AS: 65550
Age: 3:13:06 Metric2: 1
Validation State: unverified
Task: BGP_65550.20.20.20.2+179
Announcement bits (1): 0-BGP_RT_Background
AS path: I
Communities: target:10:10
Accepted
Label-base: 800000, range: 8
Localpref: 100
Router ID: 20.20.20.2
On 10/31/2013 09:18 PM, Mihai wrote:
> 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