advertising peer PPP addresses
Hi! We have a test setup with Debian Linux server running Bird. This server also acts as PPPoE server. We have OSPF running between Bird and Cisco router. But Bird is not advertising PPP peer's IP address to that Cisco router. Any hints? Here is our config file: # This pseudo-protocol watches all interface up/down events. protocol device { import all; scan time 10; # Scan interfaces every 10 seconds } # This pseudo-protocol performs synchronization between BIRD's routing # tables and the kernel. If your kernel supports multiple routing tables # (as Linux 2.2.x does), you can run multiple instances of the kernel # protocol and synchronize different kernel tables with different BIRD tables. protocol kernel { # learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds import all; # Default is import all export all; # Default is export none # kernel table 5; # Kernel table to synchronize with (default: main) } protocol ospf one { export all; rfc1583compat yes; debug all; tick 1; area 0 { interface "eth1.20" { cost 10; dead count 4; rx buffer large; authentication cryptographic; password "***"; }; }; }; Thanks in advance! -- Timur Irmatov, xmpp:irmatov@jabber.ru
I have solved my problem by adding: protocol direct { interface "ppp*"; } Sorry for the noise. -- Timur Irmatov, xmpp:irmatov@jabber.ru
On Fri, Nov 25, 2011 at 3:13 PM, Alexander V. Chernikov <melifaro@yandex-team.ru> wrote:
It is better to import interfaces via ospf if possible, e.g:
protocol ospf ospf_... { area 0.0.0.0 { interface "ppp*" { stub yes; };
No, if I comment out 'protocol direct' and configure ppp within ospf like you said, I don't get peer addresses exported. Also, what is the best way to advertise local pool for those PPP interfaces? One that I see is: protocol static { export none; import all; route 192.168.134/24 drop; }; proto ospf { import all; .... -- Timur Irmatov, xmpp:irmatov@jabber.ru
On Fri, Nov 25, 2011 at 03:41:42PM +0500, Timur Irmatov wrote:
On Fri, Nov 25, 2011 at 3:13 PM, Alexander V. Chernikov <melifaro@yandex-team.ru> wrote:
It is better to import interfaces via ospf if possible, e.g:
protocol ospf ospf_... { area 0.0.0.0 { interface "ppp*" { stub yes; };
No, if I comment out 'protocol direct' and configure ppp within ospf like you said, I don't get peer addresses exported.
If devices has ptp addresses (not a regular prefix), they are not added as stub networks. You can explicitly add them using 'stubnet IP;' in ospf area for each one, but it might be tedious. Another way is to anounce them as 'remote pool' together as a prefix (if they are).
Also, what is the best way to advertise local pool for those PPP interfaces? One that I see is:
protocol static { export none; import all; route 192.168.134/24 drop; };
That is a good idea, another way is to use 'stubnet 192.168.134/24;' in ospf area. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Fri, Nov 25, 2011 at 4:29 PM, Ondrej Zajicek <santiago@crfreenet.org> wrote:
Another way is to anounce them as 'remote pool' together as a prefix (if they are).
Could you please elaborate?
Also, what is the best way to advertise local pool for those PPP interfaces? One that I see is:
protocol static { export none; import all; route 192.168.134/24 drop; };
That is a good idea, another way is to use 'stubnet 192.168.134/24;' in ospf area.
May be I am misunderstanding something, but adding (just for test) 'stubnet 10.255.255.0/24' does not make that network known to other neighboring routers. -- Timur Irmatov, xmpp:irmatov@jabber.ru
On Fri, Nov 25, 2011 at 04:41:20PM +0500, Timur Irmatov wrote:
On Fri, Nov 25, 2011 at 4:29 PM, Ondrej Zajicek <santiago@crfreenet.org> wrote:
Another way is to anounce them as 'remote pool' together as a prefix (if they are).
Could you please elaborate?
If the other ends of PPP links have addresses that could be propagated together as one (or several) prefix, just propagate that prefix and not the individual addresses.
Also, what is the best way to advertise local pool for those PPP interfaces? One that I see is:
protocol static { export none; import all; route 192.168.134/24 drop; };
That is a good idea, another way is to use 'stubnet 192.168.134/24;' in ospf area.
May be I am misunderstanding something, but adding (just for test) 'stubnet 10.255.255.0/24' does not make that network known to other neighboring routers.
It should. Does it show as stubnet in 'show ospf state' ? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Mon, Nov 28, 2011 at 2:57 AM, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Nov 25, 2011 at 04:41:20PM +0500, Timur Irmatov wrote:
On Fri, Nov 25, 2011 at 4:29 PM, Ondrej Zajicek <santiago@crfreenet.org> wrote:
Another way is to anounce them as 'remote pool' together as a prefix (if they are).
Could you please elaborate?
If the other ends of PPP links have addresses that could be propagated together as one (or several) prefix, just propagate that prefix and not the individual addresses.
Yes, that is exactly what we are doing. We are achieving this by routing this pool as 'blackhole' in protocol static and then export to ospf. But we have several routers that act as PPPoE servers, and also we have some clients with static IP addresses. Because they can connect to any of those routers, we need to route their /32 addresses separately.
Also, what is the best way to advertise local pool for those PPP interfaces? One that I see is:
protocol static { export none; import all; route 192.168.134/24 drop; };
That is a good idea, another way is to use 'stubnet 192.168.134/24;' in ospf area.
May be I am misunderstanding something, but adding (just for test) 'stubnet 10.255.255.0/24' does not make that network known to other neighboring routers.
It should. Does it show as stubnet in 'show ospf state' ?
Uhm. My bad. Indeed, it is shown in output of 'show ospf state'. Also, neibouring Cisco does know about that network, don't know how I missed that earlier. I'll switch to using stubnet for my remote pools. Thank you very much! -- Timur Irmatov, xmpp:irmatov@jabber.ru
participants (3)
-
Alexander V. Chernikov -
Ondrej Zajicek -
Timur Irmatov