Hello,

I have a question about routing. My router a Mikrotik CCR1009 should route a network to a Mikrotik CRS326 over SFP+. The networks are at port eth1.
Located at the CRS are Server these should be get the IP addresses. My problem is i can´t bring the Netzwork to the Switch. The normal Static Routing ist working fine. I made ist whit this instruction
https://wiki.mikrotik.com/wiki/Manual:S ... ic_Routing

Here ist a little plan of my network. The IP addresse from WAN are reduced.

https://picload.org/view/dowgarpa/network.png.html

When you need the routingtable or other thing write it here. Tank you

Its a lot of possibilities.

Its possible to "hack" - just have a regular routing table inside ingress from isp. You have to route your public ip's inside rfc1918 - its stight forward - but - a hack.

ITs possible to use Eoip - and its a good easy solution. You might suffer from packet loss. A better solution is to use MPLS/VPLS and have VPLS tunnels between ingress and egress for your public ip.

You can also have some kind of l3 VPN and route directly trough here.

Last - but also possible - but a bit to big for a small network is to have bgp baset MPLS with confederation and vrf's. Then you can route your internet VRF trough your rfc1918 with no problem.

There is also some other ways like vlan etc.

VPLS interface can be considered tunnel interface just like EoIP interface. To achieve transparent ethernet segment forwarding between customer sites the following tunnels need to be established:

You cant route public ip's trough rfc1918. You need to ether use nat - or bridge to your internal ip.

Its a lot of possibilities.

Its possible to "hack" - just have a regular routing table inside ingress from isp. You have to route your public ip's inside rfc1918 - its stight forward - but - a hack.

ITs possible to use Eoip - and its a good easy solution. You might suffer from packet loss. A better solution is to use MPLS/VPLS and have VPLS tunnels between ingress and egress for your public ip.

You can also have some kind of l3 VPN and route directly trough here.

Last - but also possible - but a bit to big for a small network is to have bgp baset MPLS with confederation and vrf's. Then you can route your internet VRF trough your rfc1918 with no problem.

There is also some other ways like vlan etc.

EoIP shouldn't induce any more packet loss than MPLS. The exception to that statement would be if the MPLS tagging was being done in hardware on those platforms but I don't think that's the case. That said, yes either will work. EoIP is far easier to use than VPLS in my opinion. From the MT manual:

Code: Select all

VPLS interface can be considered tunnel interface just like EoIP interface. To achieve transparent ethernet segment forwarding between customer sites the following tunnels need to be established:

Reference: https://wiki.mikrotik.com/wiki/Manual:M ... interfaces

You cant route public ip's trough rfc1918. You need to ether use nat - or bridge to your internal ip.

That's actually not true at all. You can have rfc1918 addresses on links and forward public IP addresses across these links just fine. I used to work for a company whose entire backbone was un-natted 10.x.x.x addresses and the only public IPs to be found were on the customer's circuits. (I didn't like this setup myself - but hey, it was their company, not mine) It will give issues trying to ping to/from these hops and other points outside the admin scope of your network, though.

As long as rfc1918 is just used as transport - it will work. ICMP packet's will not work . but traffic in TCP/IP will work.

If you use a rfc1918 address as dst inside your net - you need to use nat to have it working.

As long as rfc1918 is just used as transport - it will work. ICMP packet's will not work . but traffic in TCP/IP will work.

If you use a rfc1918 address as dst inside your net - you need to use nat to have it working.

Just to clarify for those following along - ICMP will be forwarded through rfc1918 routers as well - but ICMP to/from them won't work (e.g. mtu exceeded messages from your routers, TTL expired, ping, etc) - because Internet carriers drop packets with rfc1918 addresses at their borders. (rightly so)

Furthermore, I'm not saying it's a good idea to do this - I'm just saying that it won't break end-to-end connectivity.

As long as rfc1918 is just used as transport - it will work. ICMP packet's will not work . but traffic in TCP/IP will work.

If you use a rfc1918 address as dst inside your net - you need to use nat to have it working.

Just to clarify for those following along - ICMP will be forwarded through rfc1918 routers as well - but ICMP to/from them won't work (e.g. mtu exceeded messages from your routers, TTL expired, ping, etc) - because Internet carriers drop packets with rfc1918 addresses at their borders. (rightly so)

Furthermore, I'm not saying it's a good idea to do this - I'm just saying that it won't break end-to-end connectivity.

As long as rfc1918 is just used as transport - it will work. ICMP packet's will not work . but traffic in TCP/IP will work.

If you use a rfc1918 address as dst inside your net - you need to use nat to have it working.

Just to clarify for those following along - ICMP will be forwarded through rfc1918 routers as well - but ICMP to/from them won't work (e.g. mtu exceeded messages from your routers, TTL expired, ping, etc) - because Internet carriers drop packets with rfc1918 addresses at their borders. (rightly so)

Furthermore, I'm not saying it's a good idea to do this - I'm just saying that it won't break end-to-end connectivity.

well. Its also only partly true. some ISP's will drop rfc1918 packages, but a lot will also have em routed inside its own network, - couse they have a mixed routing table, a default route - and or no firewall at all to its CPE.. its mainly when reaching eBGP and global routingtable with filtering the packed are dropped. In some rare cases this can be a bit funny. You can manage to access a device you never even knowed exist.

In some rare cases this can be a bit funny.