I am trying to make a vpls connection with a cisco7604, and seems that the tunnel never comes up.
I configure the cisco-bgp-vpls window, and in the vpls interface, come dynamically a connected one, but traffic between is not present.
At the cisco, some stuf is up, like ldp, and bgp l2vpn peer, but the tunnel never comes up completly.
Did anyone already configured bgp-based vpls against cisco.?

I received on cisco this message constantly:

cisco7604#
*Jan 26 13:36:05.899: %XCONNECT-5-PW_STATUS: MPLS peer 192.168.3.119 vcid 9999, VC DOWN, VC state DOWN
*Jan 26 13:36:05.899: %XCONNECT-5-PW_STATUS: MPLS peer 192.168.3.119 vcid 9999, VC UP, VC state UP



I attached peace of config.

cisco: peer: 192.168.3.191
mikrotik peer: 192.168.3.119


[admin@186] /interface vpls> print
Flags: X - disabled, R - running, D - dynamic,
B - bgp-signaled, C - cisco-bgp-signaled
0 RDC name="vpls1" mtu=1500 l2mtu=1500 mac-address=02:F7:D3:09:70:63
arp=enabled disable-running-check=no remote-peer=192.168.3.191
vpls-id=65030:9999 cisco-style=no cisco-style-id=0
advertised-l2mtu=1500 pw-type=raw-ethernet vpls=vpls1


[admin@186] /interface vpls cisco-bgp-vpls> print detail
Flags: X - disabled, I - inactive
0 name="vpls1" route-distinguisher=65030:9999 vpls-id=65030:9999
import-route-targets=65030:9999 export-route-targets=65030:9999 l2router-id=192.168.3.119
bridge=bridge3 bridge-cost=1 bridge-horizon=1

[admin@186] /routing bgp peer> print detail
Flags: X - disabled, E - established
0 E name="peer1" instance=default remote-address=192.168.3.191 remote-as=65030 tcp-md5-key=""
nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default in-filter=""
out-filter="" address-families=ip,l2vpn-cisco,vpnv4 update-source=192.168.3.119
interface=loopback0 default-originate=never remove-private-as=no as-override=no passive=no
use-bfd=no


[admin@186] /mpls ldp neighbor> print
Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-hello,
V - vpls
# TRANSPORT LOCAL-TRANSPORT PEER SEN
0 DOTV 192.168.3.191 192.168.3.119 192.168.3.191:0 yes
[metronoc@186] /mpls ldp neighbor>



Cisco:

l2 router-id 192.168.3.191
l2 vfi vpls1 autodiscovery
vpn id 9999
vpls-id 65030:9999
rd 65030:9999
route-target 65030:9999

ip bgp-community new-format
mpls label protocol ldp

interface Vlan3000
xconnect vfi vpls1

cisco7604#sh xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware

XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
DN vfi vpls1 UP mpls 192.168.3.119:9999 DN
UP ac Vl3000:3000(Eth VLAN) UP vfi vpls1 UP
cisco7604#

cisco7604#sh mpls l2transport vc detail
Local interface: VFI vpls1 VFI up
Interworking type is Ethernet
Destination address: 192.168.3.119, VC ID: 9999, VC status: down
Output interface: none, imposed label stack {}
Preferred path: not configured
Default path: no route
No adjacency
Create time: 00:12:34, last status change time: 00:00:07
Signaling protocol: LDP, peer 192.168.3.119:0 up
Targeted Hello: 192.168.3.191(LDP Id) -> 192.168.3.119, LDP is UP
Status TLV support (local/remote) : enabled/not supported
LDP route watch : enabled
Label/status state machine : activating, LruRru
Last local dataplane status rcvd: No fault
Last local SSS circuit status rcvd: No fault
Last local SSS circuit status sent: No fault
Last local LDP TLV status sent: No fault
Last remote LDP TLV status rcvd: Not sent
Last remote LDP ADJ status rcvd: No fault
MPLS VC labels: local 26, remote 155
AGI: type 1, len 8, 000A FE06 0000 270F
Local AII: type 1, len 4, C0A8 03BF (192.168.3.191)
Remote AII: type 1, len 4, C0A8 0377 (192.168.3.119)
Group ID: local n/a, remote n/a
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
Control Word: On (configured: autosense)
VC statistics:
transit packet totals: receive 4, send 0
transit byte totals: receive 344, send 0
transit packet drops: receive 0, seq error 0, send 0

cisco7604#

cisco7604#sh ip bgp l2vpn vpls all summary
BGP router identifier 192.168.3.191, local AS number 65030
BGP table version is 59, main routing table version 59
2 network entries using 296 bytes of memory
2 path entries using 120 bytes of memory
2/2 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 688 total bytes of memory
BGP activity 19/12 prefixes, 35/28 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.3.119 4 65030 736 713 59 0 0 10:36:48 1


Mikrotik log:

Jan/02/1970 11:55:32 route,debug,event Interface change
Jan/02/1970 11:55:32 route,debug,event interface=vpls1
Jan/02/1970 11:55:32 route,debug,event status=UP
Jan/02/1970 11:55:32 route,debug,event mtu=1500
Jan/02/1970 11:55:32 route,debug,event Interface change
Jan/02/1970 11:55:32 route,debug,event interface=vpls1
Jan/02/1970 11:55:32 route,debug,event status=UP,RUNNING
Jan/02/1970 11:55:32 route,debug,event mtu=1500
Jan/02/1970 11:55:32 route,debug,event Interface change
Jan/02/1970 11:55:32 route,debug,event interface=vpls1
Jan/02/1970 11:55:32 route,debug,event status=UP
Jan/02/1970 11:55:32 route,debug,event mtu=1500
Jan/02/1970 11:55:32 route,debug,event Interface change
Jan/02/1970 11:55:32 route,debug,event interface=vpls1
Jan/02/1970 11:55:32 route,debug,event status=UP,RUNNING
Jan/02/1970 11:55:32 route,debug,event mtu=1500

Pls did anybody in this forum configured vpls against cisco? - Is RouterOS compatible with cisco? - The only way routerOS make it work in vpls is with another mikrotik.

Comments appreciated. Thanks

cisco-bgp-vpls implementation was indeed tested with cisco 7609. Unluckily that does not mean that it will interoperate with particular cisco router and/or IOS version.

I suggest you:
- enable more mpls/ldp/l2vpn debugs on cisco to help diagnose the problem
- send souput file to support, made after a few up/down events
- if possible, capture bgp and ldp session establishment and mapping exchanges using wireshark and send to support

What line cards are those? ES-cards?

I run VPLS to SIP-600 without problems, but I do it as if it was EoMPLS.

Configuration:

MikroTik: (bridge to VLAN interface or whatever

Cisco This basically terminates the xconnect on a SVI. On the SIP, I can then put it in a VRF or I can put it on a switchport.

What line cards are those? ES-cards?

I run VPLS to SIP-600 without problems, but I do it as if it was EoMPLS.

Configuration:

MikroTik:

Code: Select all

/interface vpls
add name="VC001231234" remote-peer=198.18.1.2 cisco-style=yes cisco-style-id=1231234 pw-type=raw-ethernet

(bridge to VLAN interface or whatever

Cisco

Code: Select all

vlan 1234
 name "VC001231234"
!
interface vlan 1234
 description Cust: Customer (edge1/VC001231234)
 no ip address
 xconnect 198.18.1.1 1231234 encapsulation mpls
!

This basically terminates the xconnect on a SVI. On the SIP, I can then put it in a VRF or I can put it on a switchport.

Thanks Eising. I put this on hold and start back agiain. Me too, I could only done Eompls on cisco7600, but never VPLS. I guess mikrotik calls "vpls" what cisco calls "eompls". I guess mikrotik does not sopport "vpls" and kompella draft? Am I Wrong? Pls Advise. Thanks.

No, it's my impression that they do VPLS just fine, my linecards just don't. At least not in a way I'd like them to.
By the way, in my example I put an ip address on the SVI. This is a SIP-600 only feature...

I suggest you follow Mplsguys recommendations for further debugging. Maybe also post it here, I might be able to help.

I also recommend you to try your VFI-based configuration without BGP autodiscovery. Simply configure each neighbor by hand. See if it helps.

Well, I can agree that RouterOS usage of term VPLS might be confusing, especially if looking from cisco perspective.

In RouterOS "VPLS interface" (entity appearing in "/interface vpls" that you can use as any other network interface in your router) is what is known as "pseudowire". There are a few ways how to make them - if you add static VPLS interface "by hand" you get what is usually called EoMPLS - LDP signalled pseudowire (RFC 4447, RFC 4762).

Then there are 2 ways how dynamic VPLS interfaces (pseudowires) can appear
- RFC 4761 compliant way, where BGP is used for both - autodiscovery and signalling (i.e. label exchange), configured in "/interface vpls bgp-vpls". This will dynamically create VPLS interfaces (pseudowires)
- Cisco style BGP VPLS where BGP is used only for autodiscovery, configured in "/interface vpls cisco-bgp-vpls". This will dynamically create VPLS interfaces, but they will be further signalled using LDP (as for static VPLS interfaces/pseudowires). On cisco this feature is called "VPLS Autodiscovery: BGP Based",
http://www.cisco.com/en/US/docs/ios/12_ ... _vpls.html

As to Kompella draft - to my knowledge this has evolved into RFC 4761 (BGP is used for both - autosdiscovery and signalling) and is not supported by Cisco. It is used by Juniper, but is indeed supported in RouterOS as well.

I do not have any in-depth knowledge of cisco, but from interoperability testing I remember that it was important that your cisco does support particular mode of operation on particular port. It definitely affects forwarding plane, I have no idea if it affects control plane as well (you seem to have control plane issues, but this is just a guess).

If you feel like helping resolve the issue in RouterOS, please provide more info. BGP NLRI exchange seems to go fine in your case, so the problem is somewhere in LDP signalling. This can be due to multiple reasons - Cisco not liking some info RouterOS sends (or expecting more info) or the other way around. There have been such issues before and RouterOS has been updated to be able to work with different cisco hardware/ios versions. It has proved that investigating session packet captures (targeted LDP session in this case) is the most efficient way to figure problem out.