[j-nsp] VPLS route reflection

[Mihai]

yes, no problem after I activate inet unicast and inet6 unicast:

mx5t# run show bgp summary logical-system r2
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State 
Pending
bgp.l2vpn.0
                        1          1          0          0          0 
        0
inet.0
                        1          1          0          0          0 
        0
inet6.0
                        0          0          0          0          0 
        0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last 
Up/Dwn State|#Active/Received/Accepted/Damped...
172.27.255.5          65555         12         11       0       0 
  3:41 Establ
   bgp.l2vpn.0: 1/1/1/0
   vpls-test.l2vpn.0: 1/1/1/0
   inet.0: 1/1/1/0
   inet6.0: 0/0/0/0



On 07/02/2013 06:54 PM, James Jun wrote:
> Thanks for your response.
>
> Yea, LDP and MPLS are running and reachable (there are test l2circuits
> between lab edge routers). I noticed that on your BGP session, you’re
> only carrying l2vpn family – does it still work if you also carry inet.0
> + inet.6 on same the same session?
>
> james
>
> *From:*Mihai Gabriel [mailto:mihaigabriel at gmail.com]
> *Sent:* Tuesday, July 02, 2013 3:07 AM
> *To:* James Jun
> *Cc:* juniper-nsp at puck.nether.net
> *Subject:* Re: [j-nsp] VPLS route reflection
>
> VPLS with RR works very well for me in a small lab (see the example below).
>
> Make sure that your loopbacks are reachable through ldp and mpls is
> enabled on the interfaces.
>
> mx5t# top show logical-systems r1 protocols bgp
>
> group rr-client {
>
> type internal;
>
> local-address 172.27.255.1;
>
> family l2vpn {
>
> signaling;
>
> }
>
> neighbor 172.27.255.5;
>
> }
>
> mx5t# top show logical-systems r2 protocols bgp
>
> group rr-client {
>
> type internal;
>
> local-address 172.27.255.2;
>
> family l2vpn {
>
> signaling;
>
> }
>
> neighbor 172.27.255.5;
>
> }
>
> mx5t# top show logical-systems r5 protocols bgp
>
> group rr {
>
> type internal;
>
> local-address 172.27.255.5;
>
> family l2vpn {
>
> signaling;
>
> }
>
> cluster 0.0.0.1;
>
> neighbor 172.27.255.1;
>
> neighbor 172.27.255.2;
>
> }
>
> mx5t# run show route protocol bgp logical-system r5 table bgp.l2vpn.0
>
> bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
>
> + = Active Route, - = Last Active, * = Both
>
> 65555L:1:1:1/96
>
> *[BGP/170] 00:09:14, localpref 100, from 172.27.255.1
>
> AS path: I, validation-state: unverified
>
>  > to 172.27.0.26 via ge-1/1/6.53, Push 299808
>
> 65555L:1:2:1/96
>
> *[BGP/170] 00:09:14, localpref 100, from 172.27.255.2
>
> AS path: I, validation-state: unverified
>
>  > to 172.27.0.21 via ge-1/1/6.54, Push 299888
>
> mx5t# run show route protocol bgp logical-system r1 table bgp.l2vpn.0
>
> bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
>
> + = Active Route, - = Last Active, * = Both
>
> 65555L:1:2:1/96
>
> *[BGP/170] 00:02:49, localpref 100, from 172.27.255.5
>
> AS path: I, validation-state: unverified
>
>  > to 172.27.0.2 via ge-1/1/7.12
>
> mx5t# run show route protocol bgp logical-system r2 table bgp.l2vpn.0
>
> bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
>
> + = Active Route, - = Last Active, * = Both
>
> 65555L:1:1:1/96
>
> *[BGP/170] 00:03:00, localpref 100, from 172.27.255.5
>
> AS path: I, validation-state: unverified
>
>  > to 172.27.0.1 via ge-1/1/6.21
>
> mx5t# run show vpls mac-table logical-system r1 | find Bridging
>
> Bridging domain : __vpls-test__, VLAN : NA
>
> MAC MAC Logical NH RTR
>
> address flags interface Index ID
>
> 64:87:88:5e:a5:1c D vt-1/0/10.84934912
>
> 64:87:88:5e:a5:1d D ge-1/1/5.555
>
> On Tue, Jul 2, 2013 at 7:07 AM, James Jun <james at towardex.com
> <mailto:james at towardex.com>> wrote:
>
> Hey all,
>
> So, I've been trying to google for some sample configuration of
> BGP-signalled VPLS setup using route-reflectors, and having some trouble
> finding one. All of the sample BGP-signaled examples on Juniper site are
> using full-mesh iBGP between PE's with no RR's in the middle.
>
>
> A pretty simple and straight-forward iBGP topology like this, that we're
> all used to in a typical SP network:
>
> CE -- PE (rr client) ----- P (route-reflector) ------ P (route-reflector
> ) ----- PE (rr client) -- CE
>
>
> So, lacking any config examples, I've just enabled 'family l2vpn
> signaling;' on existing iBGP sessions that are using the above topology.
> Unfortunately, the route-reflector / P-router does not reflect the route
> received from PE and vice versa -- it is behaving like non-RR client
> peer that wants full mesh.
>
> When viewing bgp.l2vpn.0 RIB, routers can only see l2vpn NLRI's received
> from directly configured / meshed peer, but cannot see thru a
> route-reflector (i.e. P router cannot see NLRIs from a PE that's
> attached thru another P serving as route-reflector). Please note that
> unicast inet.0 and inet6.0 RIBs are also carried by same iBGP session
> transports across the topology -- and those routes obviously work
> flawlessly using route-reflectors.
>
>
> Setup looks like this on a P router:
>
> bgp {
> group teh-core {
> type internal;
> family inet {
> unicast;
> }
> family inet6 {
> unicast;
> }
> family l2vpn {
> signaling;
> }
> export mp64-ibgp-export-policy;
> peer-as 64552;
> neighbor 10.0.0.2 {
> description core1.lab2;
> }
> neighbor 10.0.0.3 {
> description core1.lab3;
> }
> }
>
> group PE-edge-routers__RR-clients {
> type internal;
> family inet {
> unicast;
> }
> family inet6 {
> unicast;
> }
> family l2vpn {
> signaling;
> }
> export mp64-ibgp-export-policy;
> cluster 10.0.0.1;
> peer-as 64552;
> neighbor 10.0.1.1 {
> description edge1.lab1;
> }
> neighbor 10.0.1.2 {
> description edge2.lab1;
> }
> }
>
> }
>
>
> Thanks in advance!
> james
> _______________________________________________
> 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
>