[j-nsp] "community set" vs "community add"

Mihai mihaigabriel at gmail.com
Thu Oct 31 15:18:30 EDT 2013


I agree, but I don't think you understand what I am trying to do.
Let's take it step by step:

- z advertises l2vpn route to RR q


z> show route advertising-protocol bgp 20.20.20.3 detail

mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 
hidden)
*  20:20:2:1/96 (1 entry, 1 announced)
  BGP group ibgp type Internal
      Route Distinguisher: 20:20
      Label-base: 800000, range: 8
      Nexthop: Self
      Flags: Nexthop Change
      Localpref: 100
      AS path: [65550] I
      Communities: target:20:20 Layer2-info: encaps: VPLS, control 
flags:[0x0] , mtu: 0, site preference: 100

- the RR should replace the community "target:20:20" advertised by z 
with "target:10:10" and the advertise the prefix to x (RR client)

q# run show route table bgp.l2vpn.0 detail

bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  10:10:1:1/96 (1 entry, 1 announced)
         *BGP    Preference: 170/-101
                 Route Distinguisher: 10:10
                 Next hop type: Indirect
                 Address: 0x26ec814
                 Next-hop reference count: 1
                 Source: 20.20.20.1
                 Protocol next hop: 20.20.20.1
                 Indirect next hop: 2 no-forward INH Session ID: 0x0
                 State: <Active Int Ext>
                 Local AS: 65550 Peer AS: 65550
                 Age: 3:13:27 	Metric2: 1
                 Validation State: unverified
                 Task: BGP_65550.20.20.20.1+58349
                 Announcement bits (1): 0-BGP_RT_Background
                 AS path: I
                 Communities: target:10:10 Layer2-info: encaps: VPLS, 
control flags:[0x0] , mtu: 0, site preference: 100
                 Accepted
                 Label-base: 800000, range: 8
                 Localpref: 100
                 Router ID: 20.20.20.1


- x accepts the l2vpn route from RR and place it in the vrf-l2vpn table

x> show route receive-protocol bgp 20.20.20.3 table mihai-vpls.l2vpn.0 
detail

mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 
hidden)
*  20:20:2:1/96 (1 entry, 0 announced)
      Import Accepted
      Route Distinguisher: 20:20
      Label-base: 800000, range: 8, status-vector: 0x0
      Nexthop: 20.20.20.2
      Localpref: 100
      AS path: I (Originator)
      Cluster list:  0.0.0.1
      Originator ID: 20.20.20.2
      Communities: target:10:10

Now, x should have a vpls connection up,but this is not the case when 
the policy used on RR for changing the community target:20:20 to 
target:10:10 is this:

q# show policy-statement from-z
term 10 {
     from {
         protocol bgp;
         community vpls-z;
     }
     then {
         community set vpls-x;
         accept;
     }
}

q# top show protocols bgp
group ibgp {
     type internal;
     local-address 20.20.20.3;
     family l2vpn {
         signaling;
     }
     cluster 0.0.0.1;
     neighbor 20.20.20.1;
     neighbor 20.20.20.2 {
         import from-z;
         export to-z;
     }
}


x> show vpls connections

Legend for interface status
Up -- operational
Dn -- down

Instance: mihai-vpls
   Local site: a (1)
No connections found.




If I change the policy to:

q# show policy-statement from-z
term 10 {
     from {
         protocol bgp;
         community vpls-z;
     }
     then {
         community delete vpls-z;
         community add vpls-x;
         accept;
     }
}

then vpls comes up:

Legend for interface status
Up -- operational
Dn -- down

Instance: mihai-vpls
   Local site: a (1)
     connection-site           Type  St     Time last up          # Up trans
     2                         rmt   Up     Oct 31 21:23:39 2013           1
       Remote PE: 20.20.20.2, Negotiated control-word: No
       Incoming label: 800001, Outgoing label: 800000
       Local interface: vt-1/0/10.235929856, Status: Up, Encapsulation: VPLS
         Description: Intf - vpls mihai-vpls local site 1 remote site 2





On 10/31/2013 08:58 PM, Harry Reynolds wrote:
> If memory serves, the add adds to what is there, while set replaces what was there with what you are now adding. One appends, the other replaces, so not the same.
>
> Regards
>
>
>
> -----Original Message-----
> From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Mihai
> Sent: Thursday, October 31, 2013 11:53 AM
> To: EXT - ipv6freely at gmail.com
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] "community set" vs "community add"
>
> Aren't these 2 policies  the same thing?
>
>
>    policy-statement from-z {
>            term 10 {
>                 from {
>                     protocol bgp;
>                     community vpls-z;
>                 }
>                 then {
>                     community delete vpls-z;
>                     community add vpls-x;
>                     accept;
>                 }
>             }
>        }
>
>
>
> policy-statement from-z {
>             term 10 {
>                 from {
>                     protocol bgp;
>                     community vpls-z;
>                 }
>                 then {
>                     community set vpls-x;
>                     accept;
>                 }
>             }
>        }
>
>
>
> On 10/31/2013 08:46 PM, Chris Jones wrote:
>> set replaces all values with just the one specified.
>> add adds the specified community to the already existing list
>>
>>
>> On Thu, Oct 31, 2013 at 9:25 AM, Mihai <mihaigabriel at gmail.com
>> <mailto:mihaigabriel at gmail.com>> wrote:
>>
>>      Hello,
>>
>>        Using a simple topology with 2 PE's and one RR I am trying to
>>      establish a vpls connection between PE's using different route-targets.
>>      I am using the RR to rewrite the communities, but using "community
>>      set" instead of "community add" results in a "No connections found"
>>      message on both PE's.
>>
>>      x and z are PE's, q is RR
>>
>>      x> show configuration routing-instances mihai-vpls
>>      instance-type vpls;
>>      vlan-id 880;
>>      interface ge-1/1/6.880;
>>      route-distinguisher 10:10;
>>      vrf-target target:10:10;
>>      protocols {
>>           vpls {
>>               site a {
>>                   site-identifier 1;
>>               }
>>           }
>>      }
>>
>>      z> show configuration routing-instances mihai-vpls
>>      instance-type vpls;
>>      vlan-id 880;
>>      interface ge-1/1/7.980;
>>      route-distinguisher 20:20;
>>      vrf-target target:20:20;
>>      protocols {
>>           vpls {
>>               site b {
>>                   site-identifier 2;
>>               }
>>           }
>>      }
>>
>>      q# show policy-options
>>      policy-statement from-z {
>>           term 10 {
>>               from {
>>                   protocol bgp;
>>                   community vpls-z;
>>               }
>>               then {
>>                   community set vpls-x;
>>                   accept;
>>               }
>>           }
>>      }
>>      policy-statement to-z {
>>           term 10 {
>>               from {
>>                   protocol bgp;
>>                   community vpls-x;
>>               }
>>               then {
>>                   community set vpls-z;
>>                   accept;
>>               }
>>           }
>>      }
>>      community vpls-x members target:10:10;
>>      community vpls-z members target:20:20;
>>
>>
>> ------------------------------__------------------------------__----
>>
>>
>>      x> show vpls connections
>>      Layer-2 VPN connections:
>>
>>      Legend for connection status (St)
>>      EI -- encapsulation invalid      NC -- interface encapsulation not
>>      CCC/TCC/VPLS
>>      EM -- encapsulation mismatch     WE -- interface and instance encaps
>>      not same
>>      VC-Dn -- Virtual circuit down    NP -- interface hardware not present
>>      CM -- control-word mismatch      -> -- only outbound connection is up
>>      CN -- circuit not provisioned    <- -- only inbound connection is up
>>      OR -- out of range               Up -- operational
>>      OL -- no outgoing label          Dn -- down
>>      LD -- local site signaled down   CF -- call admission control failure
>>      RD -- remote site signaled down  SC -- local and remote site ID
>>      collision
>>      LN -- local site not designated  LM -- local site ID not minimum
>>      designated
>>      RN -- remote site not designated RM -- remote site ID not minimum
>>      designated
>>      XX -- unknown connection status  IL -- no incoming label
>>      MM -- MTU mismatch               MI -- Mesh-Group ID not available
>>      BK -- Backup connection          ST -- Standby connection
>>      PF -- Profile parse failure      PB -- Profile busy
>>      RS -- remote site standby        SN -- Static Neighbor
>>      LB -- Local site not best-site   RB -- Remote site not best-site
>>      VM -- VLAN ID mismatch
>>
>>      Legend for interface status
>>      Up -- operational
>>      Dn -- down
>>
>>      Instance: mihai-vpls
>>         Local site: a (1)
>>      No connections found.
>>
>>      x> show route table mihai-vpls.l2vpn.0 detail
>>
>>      mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown,
>>      0 hidden)
>>        10:10:1:1/96 (1 entry, 1 announced)
>>               *L2VPN  Preference: 170/-101
>>                       Next hop type: Indirect
>>                       Address: 0x26d8270
>>                       Next-hop reference count: 2
>>                       Protocol next hop: (null)
>>                       Indirect next hop: 0 - INH Session ID: 0x0
>>                       State: <Active Int Ext>
>>                       Age: 22:36      Metric2: 1
>>                       Validation State: unverified
>>                       Task: mihai-vpls-l2vpn
>>                       Announcement bits (1): 1-BGP_RT_Background
>>                       AS path: I
>>                       Communities: Layer2-info: encaps: VPLS, control
>>      flags:[0x0] , mtu: 0, site preference: 100
>>                       Label-base: 800000, range: 8, status-vector: 0x7F
>>
>>        20:20:2:1/96 (1 entry, 0 announced)
>>               *BGP    Preference: 170/-101
>>                       Route Distinguisher: 20:20
>>                       Next hop type: Indirect
>>                       Address: 0x26d8990
>>                       Next-hop reference count: 2
>>                       Source: 20.20.20.3
>>                       Protocol next hop: 20.20.20.2
>>                       Indirect next hop: 2 no-forward INH Session ID: 0x0
>>                       State: <Secondary Active Int Ext>
>>                       Local AS: 65550 Peer AS: 65550
>>                       Age: 3:10       Metric2: 1
>>                       Validation State: unverified
>>                       Task: BGP_65550.20.20.20.3+179
>>                       AS path: I (Originator)
>>                       Cluster list:  0.0.0.1
>>                       Originator ID: 20.20.20.2
>>                       Communities: target:10:10
>>                       Import Accepted
>>                       Label-base: 800000, range: 8, status-vector: 0x0
>>                       Localpref: 100
>>                       Router ID: 20.20.20.3
>>                       Primary Routing Table bgp.l2vpn.0
>>
>>
>>      z> show route table mihai-vpls.l2vpn.0 detail
>>
>>      mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown,
>>      0 hidden)
>>        10:10:1:1/96 (1 entry, 0 announced)
>>               *BGP    Preference: 170/-101
>>                       Route Distinguisher: 10:10
>>                       Next hop type: Indirect
>>                       Address: 0x26d8990
>>                       Next-hop reference count: 2
>>                       Source: 20.20.20.3
>>                       Protocol next hop: 20.20.20.1
>>                       Indirect next hop: 2 no-forward INH Session ID: 0x0
>>                       State: <Secondary Active Int Ext>
>>                       Local AS: 65550 Peer AS: 65550
>>                       Age: 2:55       Metric2: 1
>>                       Validation State: unverified
>>                       Task: BGP_65550.20.20.20.3+62459
>>                       AS path: I (Originator)
>>                       Cluster list:  0.0.0.1
>>                       Originator ID: 20.20.20.1
>>                       Communities: target:20:20
>>                       Import Accepted
>>                       Label-base: 800000, range: 8
>>                       Localpref: 100
>>                       Router ID: 20.20.20.3
>>                       Primary Routing Table bgp.l2vpn.0
>>
>>        20:20:2:1/96 (1 entry, 1 announced)
>>               *L2VPN  Preference: 170/-101
>>                       Next hop type: Indirect
>>                       Address: 0x26d8270
>>                       Next-hop reference count: 2
>>                       Protocol next hop: (null)
>>                       Indirect next hop: 0 - INH Session ID: 0x0
>>                       State: <Active Int Ext>
>>                       Age: 22:21      Metric2: 1
>>                       Validation State: unverified
>>                       Task: mihai-vpls-l2vpn
>>                       Announcement bits (1): 1-BGP_RT_Background
>>                       AS path: I
>>                       Communities: Layer2-info: encaps: VPLS, control
>>      flags:[0x0] , mtu: 0, site preference: 100
>>                       Label-base: 800000, range: 8, status-vector: 0xBF
>>
>>
>>      -----------------------------
>>
>>
>>      If I change the policies on RR then vpls comes up:
>>
>>      q# show policy-options
>>      policy-statement from-z {
>>           term 10 {
>>               from {
>>                   protocol bgp;
>>                   community vpls-z;
>>               }
>>               then {
>>                   community delete vpls-z;
>>                   community add vpls-x;
>>                   accept;
>>               }
>>           }
>>      }
>>      policy-statement to-z {
>>           term 10 {
>>               from {
>>                   protocol bgp;
>>                   community vpls-x;
>>               }
>>               then {
>>                   community delete vpls-x;
>>                   community add vpls-z;
>>                   accept;
>>               }
>>           }
>>      }
>>      community vpls-x members target:10:10;
>>      community vpls-z members target:20:20;
>>
>>      x> show vpls connections | find connection-site
>>           connection-site           Type  St     Time last up          #
>>      Up trans
>>           2                         rmt   Up     Oct 31 18:22:35 2013
>>             1
>>             Remote PE: 20.20.20.2, Negotiated control-word: No
>>             Incoming label: 800001, Outgoing label: 800000
>>             Local interface: vt-1/1/10.235929600, Status: Up,
>>      Encapsulation: VPLS
>>               Description: Intf - vpls mihai-vpls local site 1 remote
>> site 2
>>
>>
>>      I can't understand what's the problem here.
>>
>>      Regards,
>>      Mihai
>>      _________________________________________________
>>      juniper-nsp mailing list juniper-nsp at puck.nether.net
>>      <mailto:juniper-nsp at puck.nether.net>
>>      https://puck.nether.net/__mailman/listinfo/juniper-nsp
>>      <https://puck.nether.net/mailman/listinfo/juniper-nsp>
>>
>>
>>
>>
>> --
>> Chris Jones
>> JNCIE-ENT #272
>> CCIE# 25655 (R&S)
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>


More information about the juniper-nsp mailing list