Community discussions

MUM Europe 2020
 
wolfman
just joined
Topic Author
Posts: 3
Joined: Wed Jul 09, 2008 5:07 pm

vrf problems

Thu Jul 10, 2008 6:02 pm

Hi all!

I am trying to get working MPLS/MPBGP L3 VPN setup as stated in http://wiki.mikrotik.com/wiki/Virtual_R ... Forwarding
Im using one RB450 and RB1000 with ROs 3.10 and one Cisco 7200. IGP (OSPF), LDP and MPBGP setup is fine, and in the end i get proper routes inside vrf, but then the problem occurs on each RB.
On Cisco device, when I state 'ip vrf forwarding vrf_name' command on interface (or vlan subinterface), IOS clears current ip address, and allows it to be reentered, thus allowing remote (peer) host to do icmp ping and forward ip traffic.
On each RouterBoard device, when I issue '/ip route vrf add ...' command it results with ip communication breakdown between that interface's ip address and coresponding peer (ping stops, and it worked before moving interface in particular vrf). I tried to assign some loopback address and put it inside same vrf, and then to force ping with that source address, but it didn't help. I can see mac address of corresponding interface though.
I see that post on wiki is preliminary version, but I'm interested in other people's experience with this topic. Could it be bug inside routing-test package or am I doing something wrong?

Best regards,
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: vrf problems

Thu Jul 10, 2008 10:53 pm

Perhaps I did not understand you correctly (it would help if you posted your setup description/diagram and current configuration for both - Cisco and RouterOS), but currently there is no way in RouterOS how to ping from routeros host 'inside' vrf. Ping (traceroute as well) uses only main routing table for route lookup. When you put interface in vrf, connected route for address on interface moves to vrf routing table and this makes it unusable by e.g. ping. Therefore to check connectivity you should ping from host connected to routeros vrf interface.
 
wolfman
just joined
Topic Author
Posts: 3
Joined: Wed Jul 09, 2008 5:07 pm

Re: vrf problems

Fri Jul 11, 2008 1:03 pm

First of all, thanks for reply...
I am doing just that - pinging from host connected to vrf interface, and it works on cisco but not on mikrotik.
I also reckon that mikrotik doesn't have system tools supporting vrf, like cisco has ('ping vrf vrf_name ip_add' and 'trace vrf vrf_name ip_add'), but it isn't just for diagnostic tools, it lacks functionality. I could post entire setup, but like I said I don't have problem with PE-PE communication via LDP and MPBGP, all routes and labels are fine, I have each vrf table populated properly, I only have IP communication problem with PE-CE, and only if PE host is running Mikrotik RouterOS. I dont even have to establish PE-PE MBGP because problem resides inside PE and is related to vrf 'connected' route.
Can anyone verify this setup and this rather trivial problem, which is definitely causing whole vpn not to work?
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: vrf problems

Fri Jul 11, 2008 3:08 pm

Unluckily at the moment problem of routeros not being able to originate packets from VRF (route using vrf routing table) applies also to e.g. ping response that PE must generate in response to CE request. Therefore it really currently makes CE-PE communication impossible. Still - it does not affect PE forwarding data (forwarding data received on vrf interface according to vpnv4 route over LSP and forwarding data received using LSP to VRF interface).

So at the moment you can not:
- ping PE from CE
- ping CE from PE
- ping PE from PE (using VRF addresses)
- use CE-PE routing protocol

But you can:
- ping from CE to CE over P network
 
wolfman
just joined
Topic Author
Posts: 3
Joined: Wed Jul 09, 2008 5:07 pm

Re: vrf problems

Fri Jul 11, 2008 4:25 pm

Hmm, I can't recall I manage to do ping CE-CE over P either, but there is big chance i did something wrong in whole setup.
I will try to do that again and I will get back with results. Thanks for clarifying things regarding CE-PE!

Cheers
 
Russ
newbie
Posts: 25
Joined: Mon May 02, 2005 11:55 pm
Location: New Zealand

Re: vrf problems

Thu Oct 09, 2008 3:03 am

Hi All,

I'm having a go at setting up MPLS l3 VPN's and can't get CE talking to CE, sorry If I'm hijacking the thread but its along the same lines as this.

My configuration goes:
192.168.50.1/24 -e3-(R1)-e1-- 10.0.0.0/30 --e1-(R2)-e3- 192.168.51.1/24

192.168.50.0 and 192.168.51.0 are the customer networks I'm trying to connect.

R1:
[admin@R1] /ip route> /ip address print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 0   address=10.0.0.1/30 network=10.0.0.0 broadcast=10.0.0.3 interface=ether1 actual-interface=ether1 
 1   address=192.168.50.1/24 network=192.168.50.0 broadcast=192.168.50.255 interface=ether3 actual-interface=ether3 
 2   address=10.100.0.1/32 network=10.100.0.1 broadcast=10.100.0.1 interface=loopback actual-interface=loopback 

[admin@R1] /routing bgp> instance print 
Flags: X - disabled 
 0   name="default" as=65530 router-id=10.100.0.1 redistribute-connected=yes redistribute-static=no redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter="" vrf=cust1 client-to-client-reflection=yes ignore-as-path-len=no

[admin@R1] /routing bgp> peer print 
Flags: X - disabled 
 0   name="peer1" instance=default remote-address=10.100.0.2 remote-as=65530 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter="" out-filter="" address-families=vpnv4 update-source=loopback default-originate=no 

[admin@R1] /routing bgp> vpnv4-route print detail 
Flags: N - no label 
 0   route-distinguisher=65530:100 dst-address=192.168.51.0/24 gateway=10.100.0.2 interface=ether1 in-label=16 out-label=16 bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:65530:100" 
 1   route-distinguisher=65530:100 dst-address=192.168.50.0/24 interface=ether3 in-label=16 bgp-ext-communities="RT:65530:100"

[admin@R1] /ip route> pr detail 
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 0 ADC  dst-address=192.168.50.0/24 pref-src=192.168.50.1 distance=0 scope=10 routing-mark=cust1 
 1 ADb  dst-address=192.168.51.0/24 gateway=10.100.0.2 recursive via 10.0.0.2 ether1 distance=20 scope=40 target-scope=30 routing-mark=cust1 bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:65530:100" 
 2 ADC  dst-address=10.0.0.0/30 pref-src=10.0.0.1 distance=0 scope=10 
 3 ADC  dst-address=10.100.0.1/32 pref-src=10.100.0.1 distance=0 scope=10 
 4 ADo  dst-address=10.100.0.2/32 gateway=10.0.0.2 reachable ether1 distance=110 scope=20 target-scope=10 

[admin@R1] /ip route vrf> print detail 
Flags: X - disabled, I - inactive 
 0   routing-mark=cust1 interfaces=ether3 route-distinguisher=65530:100 import-route-targets=65530:100 export-route-targets=65530:100 
R2:
[admin@R2] > /ip address print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 0   address=192.168.51.1/24 network=192.168.51.0 broadcast=192.168.51.255 interface=ether3 actual-interface=ether3 
 1   address=10.0.0.2/30 network=10.0.0.0 broadcast=10.0.0.3 interface=ether1 actual-interface=ether1 
 2   address=10.100.0.2/32 network=10.100.0.2 broadcast=10.100.0.2 interface=loopback actual-interface=loopback 

[admin@R2] /routing bgp> instance print detail 
Flags: X - disabled 
 0   name="default" as=65530 router-id=0.0.0.0 redistribute-connected=yes redistribute-static=no redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter="" vrf=cust1 client-to-client-reflection=yes ignore-as-path-len=no 

[admin@R2] /routing bgp> peer print detail 
Flags: X - disabled 
 0   name="peer1" instance=default remote-address=10.100.0.1 remote-as=65530 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter="" out-filter="" address-families=vpnv4 update-source=loopback default-originate=no 

[admin@R2] /routing bgp> vpnv4-route print detail 
Flags: N - no label 
 0   route-distinguisher=65530:100 dst-address=192.168.50.0/24 gateway=10.100.0.1 interface=ether1 in-label=16 out-label=16 bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:65530:100" 
 1   route-distinguisher=65530:100 dst-address=192.168.51.0/24 interface=ether3 in-label=16 bgp-ext-communities="RT:65530:100" 

[admin@R2] /ip route> print  detail 
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 0 ADb  dst-address=192.168.50.0/24 gateway=10.100.0.1 recursive via 10.0.0.1 ether1 distance=20 scope=40 target-scope=30 routing-mark=cust1 bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities="RT:65530:100" 
 1 ADC  dst-address=192.168.51.0/24 pref-src=192.168.51.1 distance=0 scope=10 routing-mark=cust1 
 2 ADC  dst-address=10.0.0.0/30 pref-src=10.0.0.2 distance=0 scope=10 
 3 ADo  dst-address=10.100.0.1/32 gateway=10.0.0.1 reachable ether1 distance=110 scope=20 target-scope=10 
 4 ADC  dst-address=10.100.0.2/32 pref-src=10.100.0.2 distance=0 scope=10 

[admin@R2] /routing bgp> /ip route vrf print detail 
Flags: X - disabled, I - inactive 
 0   routing-mark=cust1 interfaces=ether3 route-distinguisher=65530:100 import-route-targets=65530:100 export-route-targets=65530:100
Any help with my setup would be much appreciated, if you need any further prints or exports please let me know.

Cheers,
Russ
-- Russ
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: vrf problems

Fri Oct 10, 2008 4:37 pm

Issue has been found with MPLS ingress for VPNv4 routes that may also affect your setup. In case you are willing to get your setup up and running before 3.15 version is released I suggest you contact support and ask for updated mpls-test package (specify architecture you are using).
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: vrf problems

Fri Oct 10, 2008 5:09 pm

One another thing - if not done already, you should make sure that LSP to reach BGP next hop of VPNv4 route is established (either by LDP or RSVP-TE). Although R1 and R2 are directly attached, route on R1 to reach BGP next hop (R2's loopback interface address) is not directly connected (from R1's perspective), so VPNv4 route will not work until R1 will have LSP (e.g. LDP binding from R2 for 10.100.0.2/32) to reach R2. The same for R2.

Who is online

Users browsing this forum: No registered users and 67 guests