BGP with wrong netmask on wan interface
Alexander Zubkov
green at qrator.net
Wed Nov 8 21:44:00 CET 2017
Please show what you have in "show rote all" for the multihop case. May be
you need to alter next_hop on the advertising router.
On Wed, Nov 8, 2017 at 9:41 PM, Alexander Zubkov <green at qrator.net> wrote:
> But this works:
>
> protocol static {
> route 192.168.2.0/24 via "test2";
> route 192.168.3.0/24 recursive 192.168.2.1;
> }
>
> bird> show route
> 192.168.0.0/16 dev dum1 [direct1 23:18:17] * (240)
> 192.168.1.0/24 dev test2 [direct1 23:10:42] * (240)
> 192.168.2.0/24 dev test2 [static1 23:10:42] * (200)
> 192.168.3.0/24 via 192.168.2.1 on test2 [static1 23:22:44] * (200)
>
> I also succeeded with such bgp setup:
>
> protocol static {
> route 192.168.2.0/24 via "test2";
> # route 192.168.3.0/24 recursive 192.168.2.1;
> }
>
> protocol bgp
> {
> import all;
> local as 65002;
> source address 192.168.1.2;
> neighbor 192.168.2.1 as 65001;
> multihop 1;
> }
>
> bird> show route
> 192.168.0.0/16 dev dum1 [direct1 23:18:16] * (240)
> 192.168.1.0/24 dev test2 [direct1 23:10:41] * (240)
> 192.168.2.0/24 dev test2 [static1 23:10:41] * (200)
> 192.168.4.0/24 via 192.168.2.1 on test2 [bgp1 23:38:37] * (100/0)
> [AS65001i]
>
> bird> show route all 192.168.4.0/24
> 192.168.4.0/24 via 192.168.2.1 on test2 [bgp1 23:38:37] * (100/0)
> [AS65001i]
> Type: BGP unicast univ
> BGP.origin: IGP
> BGP.as_path: 65001
> BGP.next_hop: 192.168.2.1
> BGP.local_pref: 100
>
> If I have direct in BGP - bird ignores interface direct route and tries to
> connect via dum1 interface. But multihop works.
>
> On Wed, Nov 8, 2017 at 9:24 PM, Alexander Zubkov <green at qrator.net> wrote:
>
>> Hi again,
>>
>> I think I've got you idea. Probably bird can not do "recursive" direct
>> routes. For example I set up:
>>
>> Linux:
>>
>> 9: test2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>> state UP group default qlen 1000
>> link/ether 56:0a:42:5f:b3:46 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.1.2/24 scope global test2
>> valid_lft forever preferred_lft forever
>>
>> 192.168.1.0/24 dev test2 proto kernel scope link src 192.168.1.2
>> 192.168.2.0/24 dev test2 scope link
>>
>> bird have (no export to kernel):
>>
>> protocol static {
>> route 192.168.2.0/24 via "test2";
>> route 192.168.3.0/24 via 192.168.2.1;
>> }
>>
>> And I see in bird no route for 192.168.3.0/24:
>>
>> bird> show route
>> 192.168.1.0/24 dev test2 [direct1 23:10:42] * (240)
>> 192.168.2.0/24 dev test2 [static1 23:10:42] * (200)
>>
>> If I add to Linux such device:
>>
>> 2: dum1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state
>> UNKNOWN group default
>> link/ether ee:b2:97:43:3c:79 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.100.1/16 scope global dum1
>> valid_lft forever preferred_lft forever
>>
>> And bird starts to route via it:
>>
>> bird> show route
>> 192.168.0.0/16 dev dum1 [direct1 23:18:16] * (240)
>> 192.168.1.0/24 dev test2 [direct1 23:10:41] * (240)
>> 192.168.2.0/24 dev test2 [static1 23:10:41] * (200)
>> 192.168.3.0/24 via 192.168.2.1 on dum1 [static1 23:18:16] * (200)
>>
>>
>> On Wed, Nov 8, 2017 at 3:48 PM, Magnus Löfqvist <ml at vmi.se> wrote:
>>
>>> Hi again,
>>>
>>>
>>>
>>> If I use multihop (ie removing direct and gateway direct from config),
>>> it will connect, but I get the imported routes with my internet gateway as
>>> router.
>>>
>>>
>>>
>>> XX.XX.XX.0/27 via 10.6.24.82 dev wwan0 proto bird
>>>
>>>
>>>
>>> It should be
>>>
>>> XX.XX.XX.0/27 via 10.9.140.1 dev tap0 proto bird
>>>
>>>
>>>
>>> It doesn’t matter if I specified the source address and local address,
>>> it seems always to try to send the traffic over wwan0 (external wan
>>> connection)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Med vänlig hälsning / Best regards
>>>
>>> Magnus Löfqvist
>>>
>>>
>>>
>>> *VMI IT Services AB*
>>>
>>> *Head office:*
>>>
>>>
>>> Hantverksvägen 15
>>>
>>> 764 93 VÄDDÖ, SWEDEN
>>>
>>> *Visiting address:*
>>>
>>> Lilla Torget 1A
>>>
>>> 761 30 NORRTÄLJE, SWEDEN
>>>
>>> Tel +46 176 20 89 00 (02)
>>>
>>> Fax +46 176 20 89 19
>>>
>>>
>>> E-mail: ml at vmi.se
>>>
>>>
>>>
>>> **** VMI E-mail disclaimer ****
>>>
>>>
>>>
>>> *The information in this e-mail is confidential and may be legally
>>> privileged.*
>>>
>>> *It is intended solely for the addressee. Access to this email by anyone
>>> else is unauthorized.*
>>>
>>> *If you are not the intended recipient, any disclosure, copying,
>>> distribution or any action taken *
>>>
>>> *or omitted to be taken in reliance on it, is prohibited and may be
>>> unlawful. Any opinions or *
>>>
>>> *advice contained in this e-mail are subject to the terms and conditions
>>> expressed in the *
>>>
>>> *VMI General terms and conditions.*
>>>
>>>
>>>
>>> *Från:* green at highloadlab.com [mailto:green at highloadlab.com] *För *Alexander
>>> Zubkov
>>> *Skickat:* den 8 november 2017 11:52
>>>
>>> *Till:* Magnus Löfqvist <ml at vmi.se>
>>> *Kopia:* bird-users at network.cz
>>> *Ämne:* Re: BGP with wrong netmask on wan interface
>>>
>>>
>>>
>>> In that case it probably because you are using direct (not multihop) bgp
>>> session and bird binds to the interface which have this address in its
>>> direct network - wwan0. In that case only routes with dev wwan0 will be
>>> applied. I think you want to use multihop bgp session. If you want to use
>>> direct session and this address is accepted directly via tap0, than I think
>>> specifying source address from tap0 in bgp session should work.
>>>
>>>
>>>
>>> On Wed, Nov 8, 2017 at 10:47 AM, Magnus Löfqvist <ml at vmi.se> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Yes, you are correct.
>>>
>>> But we have routes for 10.9.140.0/22 (OpenVPN transport network)
>>>
>>>
>>>
>>> ip ro sh:
>>>
>>> default via 10.6.52.59 dev wwan0
>>>
>>> 10.0.0.0/8 dev wwan0 proto kernel scope link src 10.6.52.58
>>>
>>> 10.9.140.0/22 dev tap0 proto kernel scope link src 10.9.140.33
>>>
>>>
>>>
>>> Bird:
>>>
>>> bird> show route
>>>
>>> 0.0.0.0/0 via 10.6.52.59 on wwan0 [kernel1 09:43:55] * (10)
>>>
>>> 10.9.140.0/22 dev tap0 [direct1 09:44:12] * (240)
>>>
>>>
>>>
>>> So why are not BGP traffic to 10.9.140.1 going thru tap0 ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Med vänlig hälsning / Best regards
>>>
>>> Magnus Löfqvist
>>>
>>>
>>>
>>> *VMI IT Services AB*
>>>
>>> *Head office:*
>>>
>>>
>>> Hantverksvägen 15
>>>
>>> 764 93 VÄDDÖ, SWEDEN
>>>
>>> *Visiting address:*
>>>
>>> Lilla Torget 1A
>>>
>>> 761 30 NORRTÄLJE, SWEDEN
>>>
>>> Tel +46 176 20 89 00 (02)
>>>
>>> Fax +46 176 20 89 19
>>>
>>>
>>> E-mail: ml at vmi.se
>>>
>>>
>>>
>>> **** VMI E-mail disclaimer ****
>>>
>>>
>>>
>>> *The information in this e-mail is confidential and may be legally
>>> privileged.*
>>>
>>> *It is intended solely for the addressee. Access to this email by anyone
>>> else is unauthorized.*
>>>
>>> *If you are not the intended recipient, any disclosure, copying,
>>> distribution or any action taken *
>>>
>>> *or omitted to be taken in reliance on it, is prohibited and may be
>>> unlawful. Any opinions or *
>>>
>>> *advice contained in this e-mail are subject to the terms and conditions
>>> expressed in the *
>>>
>>> *VMI General terms and conditions.*
>>>
>>>
>>>
>>> *Från:* green at highloadlab.com [mailto:green at highloadlab.com] *För *Alexander
>>> Zubkov
>>> *Skickat:* den 8 november 2017 10:16
>>> *Till:* Magnus Löfqvist <ml at vmi.se>
>>> *Kopia:* bird-users at network.cz
>>> *Ämne:* Re: BGP with wrong netmask on wan interface
>>>
>>>
>>>
>>> Hi,
>>>
>>> You have:
>>>
>>> WAN (Mobile): 10.6.90.187 / 255.0.0.0
>>>
>>> OpenVPN interface (tap0): 10.9.140.33 / 255.255.252.0
>>>
>>>
>>>
>>> protocol bgp BGP1 from RR_LTE { neighbor 10.9.140.1 as 1; preference
>>> 140;};
>>>
>>>
>>>
>>> So you are trying to reach 10.9.140.1. If you have no additional routes,
>>> than this address falls into
>>>
>>> 10.6.90.187 / 255.0.0.0 network, i.e. WAN interface and will be routed
>>> there.
>>>
>>>
>>>
>>> On Wed, Nov 8, 2017 at 8:20 AM, Magnus Löfqvist <ml at vmi.se> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have some mobile routers (connected over LTE) and with openvpn.
>>>
>>>
>>>
>>> Over the openvpn we are running a BGP to allow distribute some routes
>>> and export routes.
>>>
>>>
>>>
>>> Some of the routers are having wrong netmask (255.0.0.0 instead of
>>> 255.255.255.252).
>>>
>>> This seems to work (ie internet are working, and the openvpn connection
>>> is established).
>>>
>>>
>>>
>>> But when we are trying to get the BGP connection up, it tries to send
>>> the BGP connection over the WAN istead of openvpn connection.
>>>
>>> I guess that I have made some mistake in the config.
>>>
>>> It should take smaller path before matching the larger..
>>>
>>>
>>>
>>>
>>>
>>> WAN (Mobile): 10.6.90.187 / 255.0.0.0
>>>
>>> OpenVPN interface (tap0): 10.9.140.33 / 255.255.252.0
>>>
>>>
>>>
>>> Bird config:
>>>
>>>
>>>
>>> template bgp RR_LTE {
>>>
>>> debug all; # debug BGP
>>>
>>> description "BIRD RR";
>>>
>>> local as 1; # the AS used by
>>> the local BGP speaker
>>>
>>> direct;
>>>
>>> gateway direct;
>>>
>>> import filter import_ATM; #
>>> just accept everything
>>>
>>> export filter export_ATM; # and
>>> advertise it to all the neigbors
>>>
>>> connect retry time 10; # reconnect try
>>> after 10s
>>>
>>> hold time 240; # hold time send
>>> in BGP messages
>>>
>>> }
>>>
>>>
>>>
>>> protocol bgp BGP1 from RR_LTE { neighbor 10.9.140.1 as 1; preference
>>> 140;};
>>>
>>>
>>>
>>> root at client1:/etc# tcpdump -ni wwan0 tcp port 179 and host 10.9.140.1
>>>
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>> decode
>>>
>>> listening on wwan0, link-type EN10MB (Ethernet), capture size 65535 bytes
>>>
>>> 15:29:08.755188 IP 10.6.90.187.34974 > 10.9.140.1.179: Flags [S], seq
>>> 1482209106, win 14600, options [mss 1460,sackOK,TS val 88007 ecr
>>> 0,nop,wscale 8], length 0
>>>
>>> 15:29:11.762726 IP 10.6.90.187.45591 > 10.9.140.1.179: Flags [S], seq
>>> 1681977930, win 14600, options [mss 1460,sackOK,TS val 88307 ecr
>>> 0,nop,wscale 8], length 0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Med vänlig hälsning / Best regards
>>>
>>> Magnus Löfqvist
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20171108/4c69b824/attachment.html>
More information about the Bird-users
mailing list