Re: [j-nsp] Interface group based on description
On the other hand we prefer external scripting (mostly m4 in our case) for generating configuration + load set terminal. It gives more features + you can link it with external tools (such as bgpq3 etc) — Sent from Mailbox for iPhone On Thu, Oct 31, 2013 at 9:48 AM, Crist Clark cjc+j-...@pumpky.net wrote: If you want to start down the commit script rabbit hole to do this, here is a good start: http://www.juniper.net/us/en/community/junos/script-automation/library/configuration/backbone-mtu/ On Wed, Oct 30, 2013 at 2:50 PM, Brad Fleming bdfle...@gmail.com wrote: Does anyone know any tricks for creating a grouping of interfaces based on the description attached? For example: Any logical interface with the label “BACKBONE to far-node” goes into a group that could then be referenced in OSPF, LDP, RSVP, etc. An interface-range is close but doesn’t allow you to reference a tagged link; it expands it’s members only to ge-0/0/0.0 even if other units are configured within the range. Interface-sets are not allowed to be referenced in protocol configuration as near as I can tell. I’d really love a way to provision an interface, label it with “BACKBONE” or “CPE”, and have that label automatically configure the interface for the proper protocols. It’d really eliminate mistakes when turning up new tail circuit locations. Any suggestions or pointers would be greatly appreciated! ___ 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
Re: [j-nsp] Interface group based on description
The closest thing which could do what you want is commit script + apply macro. Something like this: https://github.com/tehnerd/juniper_scripts/blob/master/commit/com_test.slax — Sent from Mailbox for iPhone On Thu, Oct 31, 2013 at 2:57 AM, Brad Fleming bdfle...@gmail.com wrote: Does anyone know any tricks for creating a grouping of interfaces based on the description attached? For example: Any logical interface with the label “BACKBONE to far-node” goes into a group that could then be referenced in OSPF, LDP, RSVP, etc. An interface-range is close but doesn’t allow you to reference a tagged link; it expands it’s members only to ge-0/0/0.0 even if other units are configured within the range. Interface-sets are not allowed to be referenced in protocol configuration as near as I can tell. I’d really love a way to provision an interface, label it with “BACKBONE” or “CPE”, and have that label automatically configure the interface for the proper protocols. It’d really eliminate mistakes when turning up new tail circuit locations. Any suggestions or pointers would be greatly appreciated! ___ 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
[j-nsp] EX STP question
My customer has two L2 domain (Domain1 and Domain2 built both with Juniper EX) managed by different teams. It needs now to connect those two domains but Domain1 supports only RSTP and Domain2 only VSTP. I think that in this case Domain2 should adapt automatically to RSTP for the vlans received from Domain1 in the BPDU. Does anybody confirm or amend ? Tks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JNCIS SP
Hi all Where can i find the study guide for the JNCIS SP? Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JNCIS SP
Once logged in to https://learningportal.juniper.net/, you can navigate to Learning Portal Home Fast Track JNCIS-SP eLearning JNCIS-SP Study Resources There are 3 PDF files available there, study guides for switching, routing and MPLS/VPN. /Per 31 okt 2013 kl. 15:55 skrev Mohammad Khalil eng.m...@gmail.com: Hi all Where can i find the study guide for the JNCIS SP? Thanks ___ 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
Re: [j-nsp] Interface group based on description
Thanks very much Nikita! I think I can make this work for our situation now that you’ve done all the work! :D On Oct 31, 2013, at 12:00 AM, Nikita Shirokov ns.ha...@gmail.com wrote: The closest thing which could do what you want is commit script + apply macro. Something like this: https://github.com/tehnerd/juniper_scripts/blob/master/commit/com_test.slax — Sent from Mailbox for iPhone On Thu, Oct 31, 2013 at 2:57 AM, Brad Fleming bdfle...@gmail.com wrote: Does anyone know any tricks for creating a grouping of interfaces based on the description attached? For example: Any logical interface with the label “BACKBONE to far-node” goes into a group that could then be referenced in OSPF, LDP, RSVP, etc. An interface-range is close but doesn’t allow you to reference a tagged link; it expands it’s members only to ge-0/0/0.0 even if other units are configured within the range. Interface-sets are not allowed to be referenced in protocol configuration as near as I can tell. I’d really love a way to provision an interface, label it with “BACKBONE” or “CPE”, and have that label automatically configure the interface for the proper protocols. It’d really eliminate mistakes when turning up new tail circuit locations. Any suggestions or pointers would be greatly appreciated! ___ 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
[j-nsp] community set vs community add
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 downNP -- 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 standbySN -- 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: 80, range: 8, status-vector: 0x7F
20:20:2:1/96 (1 entry, 0 announced)
*BGPPreference: 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: 80, 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)
*BGPPreference: 170/-101
Route Distinguisher: 10:10
Next hop type: Indirect
Address: 0x26d8990
Next-hop reference count: 2
Source: 20.20.20.3
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 downNP -- 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 standbySN -- 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: 80, range: 8, status-vector: 0x7F
Re: [j-nsp] community set vs community add
Depends if there are other communities attached besides vpls-z. The first
example would retain all of those.
If that's the only community on the route, then, in that case, they are the
same.
On Oct 31, 2013, at 1:53 PM, Mihai wrote:
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 downNP -- 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 standbySN -- 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
Re: [j-nsp] community set vs community add
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 downNP -- 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 standbySN -- 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
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: 80, 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)
*BGPPreference: 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:27Metric2: 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: 80, 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: 80, 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: 81, Outgoing label: 80
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;
Re: [j-nsp] community set vs community add
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: 80, 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)
*BGPPreference: 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: 80, 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: 80, 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: 81, Outgoing label: 80
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
Re: [j-nsp] community set vs community add
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: 80, 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)
*BGPPreference: 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: 80, 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: 80, 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: 81, Outgoing label: 80
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.
Re: [j-nsp] community set vs community add
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)
*BGPPreference: 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:06Metric2: 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: 80, 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: 80, 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)
*BGPPreference: 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: 80, 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: 80, 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: 81, Outgoing label: 80
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
Re: [j-nsp] community set vs community add
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: 80, 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)
*BGPPreference: 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: 80, 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: 80, 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
Re: [j-nsp] community set vs community add
On Thursday, October 31, 2013 10:38:18 PM Michael Hallgren wrote: 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. Modifying or updating communities on outbound sessions on route reflectors is routine. If you're referring to other BGP attributes, perhaps. When running NG-MVPN on Juniper's, I had to rewrite the communities that NG-MVPN's set on ingress or egress PE routers because the routes that were reflected to Cisco routers that didn't understand these communities - at the time - meant they could not route unicast correctly within the l3vpn's that carried the NG-MVPN traffic. Rewriting the community (really, making it conform more to what Cisco could understand) was a tricky, sneaky fix that worked. IOS XE and IOS XR now have very good support for NG-MVPN's, but I haven't checked how it would respond to such an issue these days. Suffice it to say, that was IOS, then. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
