Re: [j-nsp] community set vs community add
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 01/11/2013 06:32, Mark Tinka a écrit : 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. Yes, maybe I was using a sledge hammer (promoting conservativeness). If it's ``good'' or ``bad'' to rewrite communities in this way, may depend on how you then use them. 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. Which sounds like an example of (forced to but yet) ``good'' to me. Cheers, mh 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJzaosACgkQZNZ/rrgsqafgJQCfVbY0IEro1Z5PvFGEsobsSPqu YxwAoJK4fvObBW/tuzD57KIdF9V/mFtp =JEoA -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] community set vs community add
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 01/11/2013 06:32, Mark Tinka a écrit : 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. Maybe I used a sledge hammer, promoting being conservative. Such use of BGP communities, may be ``good'' or ``bad'' depending on how they are then used, I think. 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. Which appears being a ``good'' reason (in spite of being forced). Cheers, mh 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJza84ACgkQZNZ/rrgsqafTEgCgm658C7s/m+6hVFOcP/7Eyh4s UuwAnAxavfvGmtgUO99XB4mmB4zGi076 =n+Rd -END PGP SIGNATURE- ___ 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; accept
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
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
: 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
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