Community discussions

MUM Europe 2020
 
User avatar
Eising
Member Candidate
Member Candidate
Topic Author
Posts: 272
Joined: Mon Oct 27, 2008 10:21 am
Location: Copenhagen, Denmark

Can't get connected routes into ospf on a VRF

Fri Mar 20, 2009 1:00 pm

Hi there,

I'm testing MPLS with L3VPN's, and I'm experiencing the following problem (both present on 3.20 and 3.22).

I have to following layout (in nice ascii art):

+--------+
| Virtual|
| server |
+--------+
 
    |
    v
+--------+   MPLS   +----------+    MPLS     +---------+
| RB1000 | -------- | Cisco 76k| ------------| RB10000 |
+--------+   BGP    +----------+    BGP      +---------+
      |                                           |
      v                                           v
+--------+                                   +--------+
| HP5406 |                                   | HP5406 |
+--------+                                   +--------+
    /       \                                /        \
[RB450] [RB600]                            [RB450]   [RB600]

The left RB1k is edge1, the right is edge2. The 7600 works as a route-reflector for VPNV4 routes.
the RB450's and RB600's are CE routers and the link is vlan encapsulated. It's a test setup, so the CE routers themselves do the vlan encapsulation. Each CE router has a 192.168.x.0/24 network. A router connected to the same RB1k PE router can ping the other routers 192.168.x address, but a router on the other PE cannot unless it sets the source address to it's own 192.168 address.

the OSPF instance for the VRF is set up as follows:
/routing ospf instance
add comment="" disabled=no distribute-default=never metric-bgp=20 metric-connected=20 \
    metric-default=1 metric-other-ospf=20 metric-rip=20 metric-static=20 name=customer1 \
    redistribute-bgp=as-type-1 redistribute-connected=as-type-1 redistribute-other-ospf=no \
    redistribute-rip=no redistribute-static=no router-id=0.0.0.0 routing-table=customer1
So it redistributes both the BGP it has learned from the VPNV4 AFI, and connected routes.
However, connected routes are completely absent from the routing tables. I see them as connected, and they appear as type-1 LSA's in the ospf database on the PE where the interface terminates, but it's completely absent on the other router.

Take this example:
[admin@edge1.core] /routing ospf lsa> pri where area=kunde1-backbone
AREA                         TYPE         ID             ORIGINATOR     SEQUENCE-NUMBER AGE       
customer1-backbone              router       10.10.1.2      10.10.1.2      0x8000008C      330       
customer1-backbone              router       10.10.1.28     10.10.1.28     0x80000005      338       
customer1-backbone              router       10.255.254.1   10.255.254.1   0x80000097      988       
customer1-backbone              network      10.10.1.4      10.255.254.1   0x80000089      754       
customer1-backbone              network      10.10.1.28     10.10.1.28     0x80000002      339       

[admin@edge2.core] /routing ospf lsa> pri where area=kunde1-backbone
AREA                                                  TYPE         ID             ORIGINATOR     SEQUENCE-NUMBER AGE       
customer1-backbone                                       router       10.10.1.17     10.10.1.17     0x8000008A      129       
customer1-backbone                                       router       10.255.254.1   10.255.254.1   0x80000096      116       
customer1-backbone                                       network      10.10.1.20     10.255.254.1   0x80000089      116       
As it's redistributed from BGP, it should appear as external, but that doesn't seem to be the case either:
[admin@edge2.core] /routing ospf lsa> print where area=external
AREA                                                  TYPE         ID             ORIGINATOR     SEQUENCE-NUMBER AGE       
external                                              as-external  10.255.254.1   10.10.1.17     0x80000089      383       
external                                              as-external  127.0.0.1      10.10.1.17     0x80000002      626       
external                                              as-external  192.168.1.0    10.10.1.17     0x80000089      383       
Any ideas?
The road to hell is paved with good intentions.
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: Can't get connected routes into ospf on a VRF

Fri Mar 20, 2009 1:45 pm

Please post also your routing table and bgp instance configuration. Most likely this is because you have not configured your BGP instance to redistribute-connected. In RouterOS when BGP distributes OSPF routes, local connected route, although redistributed by OSPF, is not considered OSPF route.
 
User avatar
Eising
Member Candidate
Member Candidate
Topic Author
Posts: 272
Joined: Mon Oct 27, 2008 10:21 am
Location: Copenhagen, Denmark

Re: Can't get connected routes into ospf on a VRF

Fri Mar 20, 2009 2:20 pm

Okay, that wasn't how I was doing it, so I tried to enable that. Now I get all the link-nets, but it still doesn't work.
My bgp instance:
set default as=48564 client-to-client-reflection=yes comment="" disabled=no ignore-as-path-len=\
    no name=default out-filter="" redistribute-connected=yes redistribute-ospf=yes \
    redistribute-other-bgp=no redistribute-rip=no redistribute-static=no router-id=198.18.255.2 \
    vrf=customer1
My peering with the cisco:
add address-families=ipv6,l2vpn-cisco,vpnv4 comment="" default-originate=never disabled=no \
    hold-time=3m in-filter=core instance=default multihop=no name=cr0.core \
    nexthop-choice=force-self out-filter="" remote-address=198.18.255.1 remote-as=48564 \
    route-reflect=no tcp-md5-key="" ttl=255 update-source=lo0
My route-table on edge1:
 0 ADC  dst-address=10.10.1.0/29 pref-src=10.10.1.2 gateway=ether2.500 distance=0 scope=10 routing-mark=customer1 
 1 ADb  dst-address=10.10.1.16/32 gateway=198.18.255.3 recursive via 198.18.10.1 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5002 
 2 ADC  dst-address=10.10.1.24/29 pref-src=10.10.1.26 gateway=ether3.10 distance=0 scope=10 routing-mark=customer1 
 3 ADo  dst-address=10.255.254.1/32 gateway=10.10.1.4 on customer1 reachable ether2.500 distance=110 scope=20 target-scope=10 routing-mark=customer1 ospf-metric=20 ospf-type=intra-area 
 4 ADb  dst-address=10.255.254.3/32 gateway=198.18.255.3 recursive via 198.18.10.1 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=igp bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5002 
 5 ADo  dst-address=127.0.0.1/32 gateway=10.10.1.28 on customer1 reachable ether3.10 distance=110 scope=20 target-scope=10 routing-mark=customer1 ospf-metric=20 ospf-type=intra-area 
 6 ADo  dst-address=192.168.1.0/24 gateway=10.10.1.4 on customer1 reachable ether2.500 distance=110 scope=20 target-scope=10 routing-mark=customer1 ospf-metric=20 ospf-type=intra-area 
 7 ADb  dst-address=192.168.3.0/24 gateway=198.18.255.3 recursive via 198.18.10.1 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=igp bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5002 
 8 ADS  dst-address=0.0.0.0/0 gateway=198.18.0.1 reachable ether4 distance=0 scope=30 target-scope=10 
 9 ADC  dst-address=198.18.0.0/24 pref-src=198.18.0.98 gateway=ether4 distance=0 scope=10 
10 ADC  dst-address=198.18.10.0/30 pref-src=198.18.10.2 gateway=ether1 distance=0 scope=10 
11 ADo  dst-address=198.18.10.4/30 gateway=198.18.10.1 reachable ether1 distance=110 scope=20 target-scope=10 ospf-metric=11 ospf-type=intra-area 
12 ADo  dst-address=198.18.255.1/32 gateway=198.18.10.1 reachable ether1 distance=110 scope=20 target-scope=10 ospf-metric=11 ospf-type=intra-area 
13 ADC  dst-address=198.18.255.2/32 pref-src=198.18.255.2 gateway=lo0 distance=0 scope=10 
14 ADo  dst-address=198.18.255.3/32 gateway=198.18.10.1 reachable ether1 distance=110 scope=20 target-scope=10 ospf-metric=21 ospf-type=intra-area 
on edge2

 0 ADb  dst-address=10.10.1.0/32 gateway=198.18.255.2 recursive via 198.18.10.5 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5001 
 1 ADC  dst-address=10.10.1.16/29 pref-src=10.10.1.17 gateway=ether2.3000 distance=0 scope=10 routing-mark=customer1 
 2 ADb  dst-address=10.10.1.24/32 gateway=198.18.255.2 recursive via 198.18.10.5 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5001 
 3 ADb  dst-address=10.255.254.1/32 gateway=198.18.255.2 recursive via 198.18.10.5 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=igp bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5001 
 4 ADo  dst-address=10.255.254.3/32 gateway=10.10.1.20 on customer1 reachable ether2.3000 distance=110 scope=20 target-scope=10 routing-mark=customer1 ospf-metric=20 ospf-type=intra-area 
 5 ADb  dst-address=127.0.0.1/32 gateway=198.18.255.2 recursive via 198.18.10.5 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=igp bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5001 
 6 ADb  dst-address=192.168.1.0/24 gateway=198.18.255.2 recursive via 198.18.10.5 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=igp bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5001 
 7 ADo  dst-address=192.168.3.0/24 gateway=10.10.1.20 on customer1 reachable ether2.3000 distance=110 scope=20 target-scope=10 routing-mark=customer1 ospf-metric=20 ospf-type=intra-area 
 8 ADS  dst-address=0.0.0.0/0 gateway=198.18.0.1 reachable ether4 distance=0 scope=30 target-scope=10 
 9 ADC  dst-address=198.18.0.0/24 pref-src=198.18.0.99 gateway=ether4 distance=0 scope=10 
10 ADo  dst-address=198.18.10.0/30 gateway=198.18.10.5 reachable ether1 distance=110 scope=20 target-scope=10 ospf-metric=11 ospf-type=intra-area 
11 ADC  dst-address=198.18.10.4/30 pref-src=198.18.10.6 gateway=ether1 distance=0 scope=10 
12 ADo  dst-address=198.18.255.1/32 gateway=198.18.10.5 reachable ether1 distance=110 scope=20 target-scope=10 ospf-metric=11 ospf-type=intra-area 
13 ADo  dst-address=198.18.255.2/32 gateway=198.18.10.5 reachable ether1 distance=110 scope=20 target-scope=10 ospf-metric=21 ospf-type=intra-area 
14 ADC  dst-address=198.18.255.3/32 pref-src=198.18.255.3 gateway=lo0 distance=0 scope=10 

The virtual server runs a quagga as a CE router, and I have to following route-table on it:
O>* 10.10.1.0/29 [110/20] via 10.10.1.26, eth0.10, 01:59:52
O>* 10.10.1.16/32 [110/30] via 10.10.1.26, eth0.10, 00:13:42
O   10.10.1.24/29 [110/10] is directly connected, eth0.10, 01:59:52
C>* 10.10.1.24/29 is directly connected, eth0.10
O>* 10.255.254.1/32 [110/30] via 10.10.1.26, eth0.10, 01:59:52
O>* 10.255.254.3/32 [110/30] via 10.10.1.26, eth0.10, 01:59:51
C>* 127.0.0.0/8 is directly connected, lo
O>* 192.168.1.0/24 [110/30] via 10.10.1.26, eth0.10, 01:59:52
O>* 192.168.3.0/24 [110/30] via 10.10.1.26, eth0.10, 01:59:51
A traceroute to 192.168.3.1 show the following:
traceroute to 192.168.3.1 (192.168.3.1), 30 hops max, 60 byte packets
 1   (10.10.1.26)  0.135 ms  0.112 ms  0.105 ms
 2  * * *
 3  * * *
While a 192.168.1.1 traceroute works fine:
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1   (10.10.1.26)  0.077 ms  0.059 ms  0.071 ms
 2   (192.168.1.1)  0.415 ms  0.490 ms  0.577 ms
The road to hell is paved with good intentions.
 
User avatar
Eising
Member Candidate
Member Candidate
Topic Author
Posts: 272
Joined: Mon Oct 27, 2008 10:21 am
Location: Copenhagen, Denmark

Re: Can't get connected routes into ospf on a VRF

Fri Mar 20, 2009 2:50 pm

Just to expand a little, this is what I see from one of the CE routers:
[admin@rb6002.test] > /ping 192.168.1.1                        
192.168.1.1 ping timeout
2 packets transmitted, 0 packets received, 100% packet loss
[admin@rb6002.test] > /ping 192.168.1.1 src-address=192.168.3.1
192.168.1.1 64 byte ping: ttl=61 time=4 ms
1 packets transmitted, 1 packets received, 0% packet loss
[admin@rb6002.test] > /tool traceroute 192.168.1.1 src-address=192.168.3.1
     ADDRESS                                    STATUS
   1      10.10.1.17 1ms 1ms 1ms 
   2     198.18.10.5 1ms 1ms 1ms 
                      mpls-label=20 more-labels
                      mpls-label=23
   3     198.18.10.2 1ms 1ms 1ms 
   4     192.168.1.1 1ms 1ms 1ms 
[admin@rb6002.test] > /tool traceroute 192.168.1.1                        
     ADDRESS                                    STATUS
   1      10.10.1.17 1ms 1ms 1ms 
   2       (unknown) timeout timeout timeout 


The road to hell is paved with good intentions.
 
Mplsguy
MikroTik Support
MikroTik Support
Posts: 226
Joined: Fri Jun 06, 2008 5:06 pm

Re: Can't get connected routes into ospf on a VRF

Fri Mar 20, 2009 3:42 pm

The problem here is that route on edge1:
0 ADC  dst-address=10.10.1.0/29 pref-src=10.10.1.2 gateway=ether2.500 distance=0 scope=10 routing-mark=customer1 
becomes:
0 ADb  dst-address=10.10.1.0/32 gateway=198.18.255.2 recursive via 198.18.10.5 ether1 distance=200 scope=40 target-scope=30 routing-mark=customer1 bgp-local-pref=100 bgp-origin=incomplete bgp-ext-communities=RT:48564:99,RT:48564:500,0x0/0x3:48564:5001
on edge2. The prefix length gets screwed up for VPNv4 routes. Thank you for your report, this will be fixed in next version, you can contact support for fixed package. In the meantime you can use prefixes with length /24 (prefix length incorrectly gets rounded up, so only /8, /16, /24 /32 prefixes will work right).

Also, note that some router (quagga, I assume) redistributes loopback 127.0.0.1/32 route into OSPF. Probably you should filter that.
 
User avatar
Eising
Member Candidate
Member Candidate
Topic Author
Posts: 272
Joined: Mon Oct 27, 2008 10:21 am
Location: Copenhagen, Denmark

Re: Can't get connected routes into ospf on a VRF

Fri Mar 20, 2009 3:59 pm

Cool! I knew something wasn't right! :)
I'll filter 127.0.0.1 before I get in production. The quagga router is just there right now for extended testing (iperf etc.)
The road to hell is paved with good intentions.

Who is online

Users browsing this forum: No registered users and 2 guests