VPLS RouterOS <-> JUNOS BGP signalling problem

jasejames · Tue Mar 02, 2010 11:44 am

I am trying to get a VPLS session working between a JUNOS router and RouterOS. Mikrotik works fine; setting OSPF with TE, BGP with l2vpn family set and RSVP to specify the tunnel paths between the devices works without issue. However I'm having problems getting the JUNOS box to play (an SRX100, V10.0R2.10).

OSPF works. BGP works. RSVP works. The Mikrotik is sending the ARP requests to the JUNOS box when one end pings the other but the JUNOS isn't acting on them. When pinging from the side connected to the JUNOS, no packets are sent over the MPLS cloud.

Running a debug on the JUNOS I've noticed the following when the VPLS session is attempting to establish:

Mar  2 17:21:27.788843 L2VPN instance VPLS1 updated from configuration
Mar  2 17:21:27.790445     local-site 1 updated from configuration
Mar  2 17:21:27.790673  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  2 17:21:27.790791 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 1 (1) as up.
Mar  2 17:21:27.790866         intf fe-0/0/7.0 (site 1/0) updated from configuration
Mar  2 17:21:27.790997  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  2 17:21:27.791089 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 1 (1) as up.
Mar  2 17:21:27.791175         intf vpls-5.1.2 (site 1/2) updated from configuration
Mar  2 17:21:27.791303  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  2 17:21:27.791389 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 1 (1) as up.
Mar  2 17:21:27.791472         intf vpls-5.1.3 (site 1/3) updated from configuration
Mar  2 17:21:27.791662  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  2 17:21:27.791753 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 1 (1) as up.
Mar  2 17:21:27.791851         intf vpls-5.1.4 (site 1/4) updated from configuration
Mar  2 17:21:27.791956  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  2 17:21:27.792034 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 1 (1) as up.
Mar  2 17:21:27.792117         intf vpls-5.1.5 (site 1/5) updated from configuration
Mar  2 17:21:27.792221  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  2 17:21:27.792949 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 1 (1) as up.
Mar  2 17:21:27.793109         intf vpls-5.1.6 (site 1/6) updated from configuration
Mar  2 17:21:27.793225  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  2 17:21:27.793306 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 1 (1) as up.
Mar  2 17:21:27.793416         intf vpls-5.1.7 (site 1/7) updated from configuration
Mar  2 17:21:27.793522  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  2 17:21:27.793600 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 1 (1) as up.
Mar  2 17:21:27.793683         intf vpls-5.1.8 (site 1/8) updated from configuration
Mar  2 17:21:27.804576 Reconfiguring L2VPN instance VPLS1
Mar  2 17:21:27.804743 Site 1 ID 1: Starting timer for change processing,  change flags 1010, reason: reconfig
Mar  2 17:21:27.810110 vc_iflchange  intf fe-0/0/7.0
Mar  2 17:21:27.810250 [vc_intf_params_change] Intf fe-0/0/7.0: NO CHANGE
Mar  2 17:21:27.818012 [vc_ifachange] intf fe-0/0/7.0: new status intf Up (old status intf Up)
Mar  2 17:21:27.818166 [vc_ifachange] Triggering VC status update timer for intf fe-0/0/7.0
Mar  2 17:21:27.818239        Triggering VC status update timer for intf fe-0/0/7.0
Mar  2 17:21:27.818366 [vc_ifachange] fe-0/0/7.0 is not in any vc yet
Mar  2 17:21:27.818526 [vc_intf_params_change] Intf fe-0/0/7.0: NO CHANGE
Mar  2 17:21:27.821623 rt_flash_update_callback: flash VPLS1-l2vpn (VPLS1.l2vpn.0) start
Mar  2 17:21:27.821770 New policy call for L2VPN from VPLS1.L2VPN.0
Mar  2 17:21:27.821856 New policy processing complete for L2VPN from VPLS1.L2VPN.0
Mar  2 17:21:27.821945 rt_flash_update_callback: flash VPLS1-l2vpn (VPLS1.l2vpn.0) done
Mar  2 17:21:27.823115 rt_flash_update_callback: flash VPLS1-l2vpn (VPLS1.l2vpn.0) start
Mar  2 17:21:27.823246 Flash call for L2VPN from VPLS1.L2VPN.0
Mar  2 17:21:27.824638 route flash: processing 1:1::2:0
Mar  2 17:21:27.824744 Remote advertisement: (off 0, rng 16, label-base 16, encaps 19) add from next-hop 2.2.2.2 remote PE 1.1.1.1 site 2 (RD 1:1:)
Mar  2 17:21:27.824812     Invalid label-block for real advertisement
Mar  2 17:21:27.824904 Flash processing complete for L2VPN from VPLS1.L2VPN.0
Mar  2 17:21:27.824997 rt_flash_update_callback: flash VPLS1-l2vpn (VPLS1.l2vpn.0) done
Mar  2 17:21:27.857685 [vc_intf_vc_status_update] Recomputing the status of the VC for interface : fe-0/0/7.0, flags 0x0, 0x840180
Mar  2 17:21:27.857825 vc_intf_vc_status_update] interface : fe-0/0/7.0 vc status = intf Up : intf_up = TRUE
Mar  2 17:21:27.857906 [vc_intf_vc_status_update] interface : fe-0/0/7.0 Local vpls adv_down = 0, vc_down = 0, ccc_up = 1
Mar  2 17:21:27.858000 [vc_intf_vc_status_update] interface : fe-0/0/7.0 Done Computing adv, vc down and ccc_up status adv_down = 0, vc_down = 0, ccc_up = 1
Mar  2 17:21:27.858088 [vc_intf_vc_status_update] Done Recomputing the status of the VC for interface : fe-0/0/7.0, flags 0x0, 0x840180
Mar  2 17:21:31.484099 Handling change processing for local-site 1 (1):
Mar  2 17:21:33.919213 Starting change processing for local-site 1 (1): flags 0x1010
Mar  2 17:21:33.919360 Site change processing done for site 1 ID 1; cancelling running site change processing timer
Mar  2 17:21:33.919440 Handling change processing for local-site 1 done

Looks like the issue is that the JUNOS box is rejecting the advertisement from the Mikrotik box when setting up the sites. From my rudimentary knowledge of this subject this creates a mapping between the labels and sites, and this is then used to populate the MAC tables on a MAC<->site basis. But I might be totally wrong here.

The fact that things are getting this far suggests to me that it's not very far from working but I have to confess that I'm learning this stuff as I go along and a lot of it is alien to me

Relevant config as follows:

Mikrotik (R2 2.2.2.2):

/interface bridge
add disabled=no name=lo 
add disabled=no name=vpls1

/interface traffic-eng
add bandwidth=10kbps disabled=no from-address=2.2.2.2 name=R2_to_R4 primary-path=dyn to-address=4.4.4.4

/interface bridge port
add bridge=vpls1 disabled=no interface=ether2 

/interface vpls bgp-vpls
add bridge=vpls1 disabled=no export-route-targets=1:1 import-route-targets=1:1 name=bgp-vpls1 route-distinguisher=1:1 site-id=2

/mpls
set dynamic-label-range=16-1048575 propagate-ttl=yes

/mpls traffic-eng interface
add bandwidth=100kbps disabled=no interface=ether1 

/mpls traffic-eng tunnel-path
add disabled=no name=dyn use-cspf=yes

/routing bgp instance
set default as=65530 disabled=no router-id=2.2.2.2 

/routing bgp peer
add address-families=ip,l2vpn,vpnv4 disabled=no remote-address=1.1.1.1 remote-as=65530 update-source=lo 

/routing ospf instance
set default disabled=no mpls-te-area=backbone mpls-te-router-id=lo router-id=2.2.2.2

/routing ospf network
add area=backbone comment="" disabled=no network=192.168.12.0/24
add area=backbone comment="" disabled=no network=2.2.2.2/32

Juniper (R4 4.4.4.4):

set interfaces fe-0/0/7 encapsulation ethernet-vpls
set interfaces fe-0/0/7 unit 0 family vpls
set routing-instances VPLS1 instance-type vpls
set routing-instances VPLS1 interface fe-0/0/7.0
set routing-instances VPLS1 route-distinguisher 1:1
set routing-instances VPLS1 vrf-target target:1:1
set routing-instances VPLS1 protocols vpls traceoptions file vpls.log
set routing-instances VPLS1 protocols vpls traceoptions flag all
set routing-instances VPLS1 protocols vpls site-range 16
set routing-instances VPLS1 protocols vpls mac-table-size 65000
set routing-instances VPLS1 protocols vpls interface-mac-limit 65000
set routing-instances VPLS1 protocols vpls mac-table-aging-time 10000
set routing-instances VPLS1 protocols vpls no-tunnel-services
set routing-instances VPLS1 protocols vpls site 1 site-identifier 1
set routing-instances VPLS1 protocols vpls site 1 interface fe-0/0/7.0
set protocols rsvp no-interface-hello
set protocols rsvp interface vlan.300
set protocols mpls label-switched-path R4_to_R2 to 2.2.2.2
set protocols mpls label-switched-path R4_to_R2 bandwidth 10k
set protocols mpls interface all
set protocols bgp group peers type internal
set protocols bgp group peers local-address 4.4.4.4
set protocols bgp group peers family inet-vpn unicast
set protocols bgp group peers family l2vpn signaling
set protocols bgp group peers peer-as 65530
set protocols bgp group peers neighbor 1.1.1.1
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface vlan.300
set protocols ospf area 0.0.0.0 interface lo0.0

I believe the configuration is completely standard, and from what I can make out of the standards used by both sides they should be compatible.

Can anyone see what might be wrong here?

Thanks.

jasejames · Tue Mar 02, 2010 9:31 pm

Right, looking into this further I have noticed some differences in the way the BGP packets are constructed.

1) (probably a benign difference) under extended communities, the Mikrotik device has the F and S flags set, whereas these are clear on the Juniper.

2) (also probably benign) the BGP update is listed as type incomplete on the Mikrotik (?/redistributed), whereas it's an IGP update on the Juniper.

3) (this is, I think, the problem) the label block offset is 0 on the Mikrotik implementation, 1 on JUNOS; the label base is 16 on Mikrotik against 262145 for the Juniper (this I don't think is a problem because RSVP is working fine it would seem), and the label block size is 8 on the Juniper vs 16 on the Mikrotik. The Mikrotik's packet seems to be failing the Juniper's sanity check.

A capture of a single BGP update packet, containing one JUNOS update and one RouterOS one is attached.

Are there any knobs on either device I can twist to get this working?

It seems that the Mikrotik is accepting the update from the Juniper, as it is forwarding packets and encapsulating them in MPLS along the way. However the Juniper is not accepting the Mikrotik's update, and thus is not forwarding anything to/from fe-0/0/7.0 as expected.

jasejames · Tue Mar 02, 2010 9:36 pm

Actually just looking at this I note that the site range is set to 8 on the Junos device despite my setting it to 16 (can't work that one out). Must look into that, doesn't seem right.

Still think it's that offset though!

jasejames · Tue Mar 02, 2010 10:49 pm

Right, I've been reading a little further on this and have reached the following two conclusions:

1) There is a political difference between JUNOS and RouterOS on the block-size: 8 for JUNOS (2 blocks for 16 sites), 16 for Mikrotik (and an unknown number of sites). Juniper say that this is configurable but do not see anywhere where either can be tweaked. RouterOS seems easy on the formatting of this but I'm not sure whether JUNOS is.

2) According to Juniper documentation the label offset goes from 1 to 16 for a 16-site network. The implication seems to be that an offset of zero is invalid. I believe that this is the reason JUNOS is choking. Could this be altered?

3) RouterOS sends that all packets sent to it are to be sequenced, Junos says unsequenced. Yet Sequence numbers are being sent by the Mikrotik device on packets sent to the Juniper....

Mplsguy · Wed Mar 03, 2010 9:27 am

RFC 4761 does not specify that ID block offset 0 should be considered as invalid. What VPLS NLRI says is: originator advertises that sites with IDs in range blockoffset->blockoffset+blocksize-1 should use labels labelbase->labelbase+blocksize-1. So if receiver ID fits in this range he knows what label to use when sending to originator. Refer to RFC 4761, section 3.2.2.

There is a way how you can try to confirm that block offset 0 is indeed the problem. RouterOS is advertising labels in blocks of 16. When you enable bgp-vpls instance, RouterOS at first sends update for site-ids that are "close" to its own site-id (this way RouterOS advertises its presence and that it participates in particular VPLS and also assigns some labels for other sites to use). If RouterOS has site-id=2, it will send NLRI for id range 0-15 (blockoffset=0, size=16). You can "force" RouterOS advertise labels for "next" range (16-31) by setting site-id in range 16-31. To be safe also set site id of juniper in this range as well. Probably you will have to increase site range on juniper for this to work.

edit: in quick scan over RFC 4761 I failed to find anything stating that site id 0 should not be used. Therefore block offset 0 should also be fine. It would be great if you could really confirm that the blockoffset 0 is the problem in your case.

jasejames · Wed Mar 03, 2010 10:53 am

Hi Mplsguy,

Thanks very much for your reply.

I set the ID on the JUNOS box to 20 and on the Mikrotik to 21.

The Juniper now gets past the sanity check, suggesting that offset 0 is indeed the problem.

Debug enclosed (important bits starred):

Mar  3 16:48:50.424990 L2VPN instance VPLS1 updated from configuration
Mar  3 16:48:50.426588     local-site 20 updated from configuration
Mar  3 16:48:50.426830  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  3 16:48:50.426935 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 20 (20) as up.
Mar  3 16:48:50.427008         intf fe-0/0/7.0 (site 20/0) updated from configuration
Mar  3 16:48:50.427138  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  3 16:48:50.427254 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 20 (20) as up.
Mar  3 16:48:50.427345         intf vpls-5.20.17 (site 20/17) updated from configuration
Mar  3 16:48:50.427449  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  3 16:48:50.427525 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 20 (20) as up.
Mar  3 16:48:50.427604         intf vpls-5.20.18 (site 20/18) updated from configuration
Mar  3 16:48:50.427700  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  3 16:48:50.427785 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 20 (20) as up.
Mar  3 16:48:50.427865         intf vpls-5.20.19 (site 20/19) updated from configuration
Mar  3 16:48:50.427964  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  3 16:48:50.428039 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 20 (20) as up.
Mar  3 16:48:50.428117         intf vpls-5.20.21 (site 20/21) updated from configuration
Mar  3 16:48:50.428215  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  3 16:48:50.428899 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 20 (20) as up.
Mar  3 16:48:50.429039         intf vpls-5.20.22 (site 20/22) updated from configuration
Mar  3 16:48:50.429155  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  3 16:48:50.429374 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 20 (20) as up.
Mar  3 16:48:50.429478         intf vpls-5.20.23 (site 20/23) updated from configuration
Mar  3 16:48:50.429587  l2vpn_update_irb_state: irb_present 0  conn_type 0  prev_irb_intf 0  irb_intf 0
Mar  3 16:48:50.429669 l2vpn_site_intf_mgroup_up_count_updated(), Marking site 20 (20) as up.
Mar  3 16:48:50.429748         intf vpls-5.20.24 (site 20/24) updated from configuration
Mar  3 16:48:50.441004 Reconfiguring L2VPN instance VPLS1
Mar  3 16:48:50.445763 vc_iflchange  intf fe-0/0/7.0
Mar  3 16:48:50.445921 [vc_intf_params_change] Intf fe-0/0/7.0: NO CHANGE
Mar  3 16:48:50.451490 [vc_ifachange] intf fe-0/0/7.0: new status intf Up (old status intf Up)
Mar  3 16:48:50.451617 [vc_ifachange] Triggering VC status update timer for intf fe-0/0/7.0
Mar  3 16:48:50.451685        Triggering VC status update timer for intf fe-0/0/7.0
Mar  3 16:48:50.451793 [vc_ifachange] fe-0/0/7.0 is not in any vc yet
Mar  3 16:48:50.451878 [vc_intf_params_change] Intf fe-0/0/7.0: NO CHANGE
Mar  3 16:48:50.454284 rt_flash_update_callback: flash VPLS1-l2vpn (VPLS1.l2vpn.0) start
Mar  3 16:48:50.454416 New policy call for L2VPN from VPLS1.L2VPN.0
Mar  3 16:48:50.454501 New policy processing complete for L2VPN from VPLS1.L2VPN.0
Mar  3 16:48:50.454598 rt_flash_update_callback: flash VPLS1-l2vpn (VPLS1.l2vpn.0) done
Mar  3 16:48:50.458481 rt_flash_update_callback: flash VPLS1-l2vpn (VPLS1.l2vpn.0) start
Mar  3 16:48:50.458610 Flash call for L2VPN from VPLS1.L2VPN.0
Mar  3 16:48:50.458691 route flash: processing 1:1::21:0

***
Mar  3 16:48:50.458802 Remote advertisement: (off 0, rng 16, label-base 48, encaps 19) add from next-hop 2.2.2.2 remote PE 1.1.1.1 site 21 (RD 1:1:)
Mar  3 16:48:50.458870     Invalid label-block for real advertisement
***

Mar  3 16:48:50.458942 route flash: processing 1:1::21:16

***
Mar  3 16:48:50.459029 Remote advertisement: (off 16, rng 16, label-base 16, encaps 19) add from next-hop 2.2.2.2 remote PE 1.1.1.1 site 21 (RD 1:1:)
Mar  3 16:48:50.459200 Chaning site designation for instance VPLS1 site <remote site> ID 21 type remote
Mar  3 16:48:50.461614 remote site ID 21 marked designated
***

Mar  3 16:48:50.461705 Site <remote site> ID 21: Starting timer for change processing,  change flags 218, reason: remote adv recv -- RD 1:1:
Mar  3 16:48:50.461817 task_timer_reset: reset VPLS1-l2vpn_Site change
Mar  3 16:48:50.461919 task_timer_set_oneshot_latest: timer VPLS1-l2vpn_Site change interval set to 0.043418
Mar  3 16:48:50.462003 Flash processing complete for L2VPN from VPLS1.L2VPN.0
Mar  3 16:48:50.462090 rt_flash_update_callback: flash VPLS1-l2vpn (VPLS1.l2vpn.0) done
Mar  3 16:48:50.489888 [vc_intf_vc_status_update] Recomputing the status of the VC for interface : fe-0/0/7.0, flags 0x0, 0x840180
Mar  3 16:48:50.490027 vc_intf_vc_status_update] interface : fe-0/0/7.0 vc status = intf Up : intf_up = TRUE
Mar  3 16:48:50.490109 [vc_intf_vc_status_update] interface : fe-0/0/7.0 Local vpls adv_down = 0, vc_down = 0, ccc_up = 1
Mar  3 16:48:50.490182 [vc_intf_vc_status_update] interface : fe-0/0/7.0 Done Computing adv, vc down and ccc_up status adv_down = 0, vc_down = 0, ccc_up = 1
Mar  3 16:48:50.501230 [vc_intf_vc_status_update] Done Recomputing the status of the VC for interface : fe-0/0/7.0, flags 0x0, 0x840180
Mar  3 16:48:50.503937 task_timer_dispatch: calling VPLS1-l2vpn_Site change, late by 0.002

***
Mar  3 16:48:50.504062 Handling change processing for remote-site 21:
Mar  3 16:48:50.504140 Starting change processing for remote-site 21: flags 0x218
Mar  3 16:48:50.504239 Mesh group for lcl site 20, rmt site ID 21 is __ves__
Mar  3 16:48:50.504322 Abort VC creation, reason  control-word support mismatch
Mar  3 16:48:50.504401 Handling change processing for remote-site 21 done
***

Mar  3 16:48:50.504485 task_timer_dispatch: returned from VPLS1-l2vpn_Site change, rescheduled in 0

Seems though that now the Juniper is choking on those flags, probably the disagreement over whether packets in the PW should be sequenced...

BTW if you read this document:

http://kb.juniper.net/library/CUSTOMERS ... ration.pdf

This is where I got the impression from that the block offset should start at 1 rather than zero, at least as far as Juniper is concerned (and didn't they write the RFC?

)

Seems that your workaround has partially worked anyway -- devious trick

-- but the sequencing(?) possibly also needs to be looked at....

I can provide SSH access to the box connected to a Mikrotik via an access server if you require it at some point.

jasejames · Wed Mar 03, 2010 11:13 am

Actually I think Wireshark is talking crap when it comes to the nature of the disagreement between the two.

Mikrotik is setting 00000010 for the control vector against 00000000 for JUNOS. According to the RFC this means that Mikrotik demands a control word, and JUNOS says it must not be there.

Nothing to do with sequencing at all -- that's bit 7 rather than 6.

jasejames · Wed Mar 03, 2010 3:45 pm

Yeah this definitely seems to be the outstanding issue.

From what I can tell JUNOS doesn't use the control word, and there doesn't seem to be a way of enabling it.

Given that it is "optional" and its purpose doesn't seem to be defined, is this a Mikrotik-proprietary thing? Looks like ROS is using it for sequencing purposes...

In which case, how do I shoot it?

Mplsguy · Wed Mar 03, 2010 4:12 pm

Sequencing is not the only purpose of control word. It can also be used for fragmentation and reassembly, and this is the main reason why RouterOS uses it. And this can hardly be considered "proprietary", because fragmentation and reassembly in RouterOS is implemented according to RFC 4623. Usage of control word is pretty controversial topic, as there have been some problems with Cisco compatibility as well.

I guess new setting can be added to specify whether control word is used or not, but there is no way to disable it at this time. Thanks for reference to Juniper doc, both of these things - control word and site ID base will be addressed (as this kind of "BGP based VPLS" is Junipers "standard" anyway), although I can not give any time estimates at the moment.

jasejames · Wed Mar 03, 2010 4:35 pm

Thanks Mplsguy, much appreciated.

We're a fairly big regional public-sector ISP, and there's a possibility that we could use RBs for non-internal networks (internals need to be EAL4 so we need Junipers for them), but of course our network is all Juniper.

Awaiting any updates with interest

And thanks for the RFC4623 -- looked it over and it now makes sense. I believe Juniper gets around the issue by using high MTU values for VPLS connections, but the Cisco (and Mikrotik) approach seems more sensible it must be said.

smite · Tue Jul 20, 2010 1:08 am

Mplsguy/jasejames,

Has this ever been resolved?
I have a Juniper M10 running 10.0R1.8 and Mikrotik RB1100 running 4.9 and I am running into the same problem.
First I also had the "Invalid label-block for real advertisement" and when I googled on this, this forum post is in the only one of the entire internet referencing this error.

I then changed the site-ids as advised and now I also run into the same:

Jul 19 21:55:48.795483 Mesh group for lcl site bgp-vpls1, rmt site ID 20 is __ves__
Jul 19 21:55:48.795543 Abort VC creation, reason control-word support mismatch

This also only has a single hit on the internet. This post.

With the Mikrotik is running 5.0beta4, the same symptoms appear.

Mplsguy · Tue Jul 20, 2010 7:06 pm

I am sorry to say that, but this particular "problem" has not been fixed yet due to scarce resources - it is noted and on TODO list for next batch of MPLS improvements. Probably loud and clear demand for this feature may boost its priority, but anyway - thanks for the reports. Any other reports/wishes for better juniper compatibility are welcome.

smite · Wed Jul 21, 2010 3:09 pm

Is there anything I can help with?

I currently have 1 M10, 2 RB1100 and some M40s in my testsetup.

Would it help to have temporary access to this setup?
It would make the routerboards much more valuable for me, and propably others, if they would interoperate with the large installed base of Junipers.

Has any interoperability testing regarding MPLS, VPLS, etc. been done with any brands?

Mplsguy · Wed Jul 21, 2010 11:34 pm

Your help will be most handy when these features get implemented - you will be welcome to test them

.

As to the interoperability testing - there has been plenty of testing with Cisco equipment, different models. I must say that there were also number of problems that had to be addressed, especially VPLS/EoMPLS related, so in this case it is just a matter of testing with Juniper and resolving any issues.

smite · Thu Jul 22, 2010 8:06 am

Do you have any time-period for this?

I will be moving these RB1100 in production soon and then I will no longer have a large amount to test with.

Mplsguy · Thu Jul 22, 2010 2:01 pm

Please contact support (refer to this topic) with info on what type of RBs you use and what ROS version, hopefully you will get testing package in the nearest future (today or tomorrow).

smite · Fri Jul 23, 2010 8:55 am

Thank you, I have sent the mail.

misak · Thu Nov 17, 2016 10:46 am

Hello,

seems i've also hit this issue, please look at http://forum.mikrotik.com/viewtopic.php?f=14&t=114487

And now is end of 2016, any expectation of improved compatibility?

VPLS RouterOS <-> JUNOS BGP signalling problem

VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS with RSVP/BGP signalling possible?

Re: VPLS RouterOS <-> JUNOS with RSVP/BGP signalling possible?

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Re: VPLS RouterOS <-> JUNOS BGP signalling problem

Who is online