[j-nsp] "community set" vs "community add"
Michael Hallgren
m.hallgren at free.fr
Thu Oct 31 16:38:18 EDT 2013
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: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
>>>
>>>
>>>
>>
>>
> _______________________________________________
> 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