headers
Sami Halabi | 1 Sep 2010 11:28
Picon

[quagga-users 11737] BGP Help

Hi,
I'm NEW to quagga and to BGP routing.
 
I have a quagga router that i want to connect between 2 connections:
1) is an internal connection in our country (high bandwidth) - a transit that connects local country ISPs, forwarding only traffic originated and destinated to one of the members, so it won't forward traffic for example that orginated by an ISP not from the country even if i pass it (against the policy) - ASN - 100.
2) is a pure link (low bandwidth) to one of the other ISP on the country (this line should route my packets that destinated to addresses not  in the country) - ASN 200.
 
I have ASN 300 (all ASNs are for the example).
 
i want to put a quagga router to with BGP so any traffic distinated to an ISP that is member of AS100  to go through link of AS 100 (including the traffic that goes to AS200), and all traffic that is destinated to any other address that isn't routeable through AS100 to go through AS200.
 
can you help me with bgp configuration in AS300 and AS200.
 
As i read i can prefer traffic (local prefs) to go through AS100, but what conf should be in the ISP so even if his own TRAFFIC that destinated to me that he's the originated (or any of his sub ASNs) of the traffic to  go through AS100 (again - there i have high bandwidth).
 
thanks in advance,
Sami
_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 6 comments |
headers
Tyler J. Wagner | 1 Sep 2010 11:58
Gravatar

[quagga-users 11738] Re: BGP Help

On Wednesday 01 Sep 2010 10:28:27 Sami Halabi wrote:
> i want to put a quagga router to with BGP so any traffic distinated to an
> ISP that is member of AS100  to go through link of AS 100 (including the
> traffic that goes to AS200), and all traffic that is destinated to any
> other address that isn't routeable through AS100 to go through AS200.
> 
> can you help me with bgp configuration in AS300 and AS200.
> 
> As i read i can prefer traffic (local prefs) to go through AS100, but what
> conf should be in the ISP so even if his own TRAFFIC that destinated to me
> that he's the originated (or any of his sub ASNs) of the traffic to  go
> through AS100 (again - there i have high bandwidth).

Sami,

AS 100 and 200 will announce individual routes to you via BGP. Set your local 
preference to higher priority for AS 100, set a default route to AS 200, and 
you're done. You may not even need the higher priority for AS 100 if those AS 
paths are shorter, since BGP will handle that calculation for you.

Regards,
Tyler

--

-- 
"The belief in immortality has always seemed cowardly to me. When very
young I learned that all things die, and all that we wish of good must
be won on this earth or not at all."
   -- Anne Smedley
Permalink | Reply | 5 comments |
headers
Sami Halabi | 1 Sep 2010 13:23
Picon

[quagga-users 11739] Re: BGP Help

Tyler,
That sounds okay, but how it doesn't complete the picture on AS200 (that is connected to my AS300 and AS100 also), i want it to somehow prefer traffic that is destinated to AS300 and its source address (origin) from one of its networks to go through AS100, and if not to route traffic through AS300 directly.
 
Thanks again,
Sami

2010/9/1 Tyler J. Wagner <tyler-/4Na+MoQkKtBDgjK7y7TUQ@public.gmane.org>
On Wednesday 01 Sep 2010 10:28:27 Sami Halabi wrote:
> i want to put a quagga router to with BGP so any traffic distinated to an
> ISP that is member of AS100  to go through link of AS 100 (including the
> traffic that goes to AS200), and all traffic that is destinated to any
> other address that isn't routeable through AS100 to go through AS200.
>
> can you help me with bgp configuration in AS300 and AS200.
>
> As i read i can prefer traffic (local prefs) to go through AS100, but what
> conf should be in the ISP so even if his own TRAFFIC that destinated to me
> that he's the originated (or any of his sub ASNs) of the traffic to  go
> through AS100 (again - there i have high bandwidth).

Sami,

AS 100 and 200 will announce individual routes to you via BGP. Set your local
preference to higher priority for AS 100, set a default route to AS 200, and
you're done. You may not even need the higher priority for AS 100 if those AS
paths are shorter, since BGP will handle that calculation for you.

Regards,
Tyler

--
"The belief in immortality has always seemed cowardly to me. When very
young I learned that all things die, and all that we wish of good must
be won on this earth or not at all."
  -- Anne Smedley

_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 4 comments |
headers
Tyler J. Wagner | 1 Sep 2010 14:20
Gravatar

[quagga-users 11740] Re: BGP Help

Sami,

To do that, just prefix your announcement to AS200. This will cause your 
announced space to AS200 to appear to have a longer AS path, so other networks 
prefer the AS100 route. Do something like the the following (substitute 
appropriate AS and IP numbers, of course).

router bgp 300
 neighbor AS100 peer-group
 neighbor AS100 remote-as 300
 neighbor AS100 soft-reconfiguration inbound
 neighbor AS200 peer-group
 neighbor AS200 remote-as 300
 neighbor AS200 soft-reconfiguration inbound
 neighbor AS200 route-map prepend out
 neighbor 10.0.200.1 peer-group AS200
 neighbor 10.0.100.1 peer-group AS100

route-map prepend permit 10
 set as-path prepend 300 300

That will cause your routes via AS200 to have a path of "200 300 300 300", and 
your routes via AS100 to have a path of "100 300", which is shorter and would 
be preferred.

Using peer groups makes it easier to add multiple upstream IPs in case of 
redundant routers. Using "soft-reconfiguration inbound" means you can make 
changes dynamically without clearing the BGP session. This reduces down time 
as routes are exchanged. However, it requires more RAM (equivalent to the size 
of the BGP route table from each peer). On a Linux box with Quagga, that's not 
likely to be a problem.

Regards,
Tyler

On Wednesday 01 Sep 2010 12:23:32 Sami Halabi wrote:
> Tyler,
> That sounds okay, but how it doesn't complete the picture on AS200 (that is
> connected to my AS300 and AS100 also), i want it to somehow prefer traffic
> that is destinated to AS300 and its source address (origin) from one of its
> networks to go through AS100, and if not to route traffic through AS300
> directly.
> 
> Thanks again,
> Sami
> 
--

-- 
"It is wrong to think that the task of physics is to find out how nature
is. Physics concerns what we can say about nature."
   -- Niels Bohr
Permalink | Reply | 3 comments |
headers
Florian Weimer | 1 Sep 2010 15:04
Picon

[quagga-users 11741] Capabilities and multi-protocol BGP

It seems that without explicit configuration, Quagga can only peer
with BGP speakers which advertise the multi-protocol capability as
soon as the peer advertises any capability.  Is this really true?  If
yes, is there some RFC I've missed which requires this behavior?

--

-- 
Florian Weimer                <fweimer@...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
Permalink | Reply | 3 comments |
headers
Bengt Gördén | 1 Sep 2010 15:28
Gravatar

[quagga-users 11742] Re: Capabilities and multi-protocol BGP

onsdag 01 september 2010 15:04:17 skrev  Florian Weimer:
> It seems that without explicit configuration, Quagga can only peer
> with BGP speakers which advertise the multi-protocol capability as
> soon as the peer advertises any capability.  

Do you mean by that, that quagga doesn't accept bgp-packets from non-
multiprotocol-speakers?

> Is this really true?  If
> yes, is there some RFC I've missed which requires this behavior?

Otherwise it should be like this. But you have probably already found out 
that, right?

from:
http://www.ietf.org/rfc/rfc4760.txt

Abstract

   .............  The extensions are backward compatible - a router
   that supports the extensions can interoperate with a router that
   doesn't support the extensions.

/bengan
Permalink | Reply | 2 comments |
headers
Florian Weimer | 1 Sep 2010 15:45
Picon

[quagga-users 11743] Re: Capabilities and multi-protocol BGP

* Bengt Gördén:

> onsdag 01 september 2010 15:04:17 skrev  Florian Weimer:
>> It seems that without explicit configuration, Quagga can only peer
>> with BGP speakers which advertise the multi-protocol capability as
>> soon as the peer advertises any capability.  
>
> Do you mean by that, that quagga doesn't accept bgp-packets from non-
> multiprotocol-speakers?

Yes, as soon as those non-multiprotocol speakers announce AS4 support.

>> Is this really true?  If
>> yes, is there some RFC I've missed which requires this behavior?
>
> Otherwise it should be like this. But you have probably already found out 
> that, right?

Sorry, found out what?

> from:
> http://www.ietf.org/rfc/rfc4760.txt
>
>
> Abstract
>
>
>    .............  The extensions are backward compatible - a router
>    that supports the extensions can interoperate with a router that
>    doesn't support the extensions.

There might an RFC that says that RFC 4660 is MANDATORY to implement
as oon as you implement capability support.  Otherwise, it seems to be
a bug in Quagga.

--

-- 
Florian Weimer                <fweimer@...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
Permalink | Reply | 1 comment |
headers
Bengt Gördén | 1 Sep 2010 16:12
Gravatar

[quagga-users 11744] Re: Capabilities and multi-protocol BGP

onsdag 01 september 2010 15:45:54 skrev  Florian Weimer:
> * Bengt Gördén:
> > onsdag 01 september 2010 15:04:17 skrev  Florian Weimer:
> >> It seems that without explicit configuration, Quagga can only peer
> >> with BGP speakers which advertise the multi-protocol capability as
> >> soon as the peer advertises any capability.
> >
> > Do you mean by that, that quagga doesn't accept bgp-packets from non-
> > multiprotocol-speakers?
> 
> Yes, as soon as those non-multiprotocol speakers announce AS4 support.
> 
> >> Is this really true?  If
> >> yes, is there some RFC I've missed which requires this behavior?
> >
> > Otherwise it should be like this. But you have probably already found out
> > that, right?
> 
> Sorry, found out what?

Sorry. Let's forget about that.

> > from:
> > http://www.ietf.org/rfc/rfc4760.txt
> >
> >
> > Abstract
> >
> >
> >    .............  The extensions are backward compatible - a router
> >    that supports the extensions can interoperate with a router that
> >    doesn't support the extensions.
> 
> There might an RFC that says that RFC 4660 is MANDATORY to implement

4760

> as oon as you implement capability support.  Otherwise, it seems to be
> a bug in Quagga.

According to 4271 it should shut down the BGP-peering. But if you follow 5492 
it can handle unrecognized capabilities.

To find out which RFC's that refers to 4760 you can do this in google:

"rfc 4760" -index-rfc

/bengan
Permalink | Reply | 0 comments |
headers
Sami Halabi | 1 Sep 2010 23:08
Picon

[quagga-users 11745] Re: BGP Help

Tyler,
Thank you for your detailed response, but maybe i didn't explain well...
AS100 doesn't allow traffic that originated by an AS that isn't a peering with it.
so lets say AS400 is reachable via AS200, the packets should flow between AS200 and AS300 directly as transit to AS400.
however traffic that is destinated to AS500 which is a peering member of AS100 should go through AS100 directly, and only in backup case AS100 isn't linked then the traffic should try to flow over AS200.

I appreciate very much your help, this is my last piece of the puzzle, and why i think needs AS200 (and maybe AS300) to do more configuration.

Sami

2010/9/1 Tyler J. Wagner <tyler-/4Na+MoQkKtBDgjK7y7TUQ@public.gmane.org>
Sami,

To do that, just prefix your announcement to AS200. This will cause your
announced space to AS200 to appear to have a longer AS path, so other networks
prefer the AS100 route. Do something like the the following (substitute
appropriate AS and IP numbers, of course).

router bgp 300
 neighbor AS100 peer-group
 neighbor AS100 remote-as 300
 neighbor AS100 soft-reconfiguration inbound
 neighbor AS200 peer-group
 neighbor AS200 remote-as 300
 neighbor AS200 soft-reconfiguration inbound
 neighbor AS200 route-map prepend out
 neighbor 10.0.200.1 peer-group AS200
 neighbor 10.0.100.1 peer-group AS100

route-map prepend permit 10
 set as-path prepend 300 300

That will cause your routes via AS200 to have a path of "200 300 300 300", and
your routes via AS100 to have a path of "100 300", which is shorter and would
be preferred.

Using peer groups makes it easier to add multiple upstream IPs in case of
redundant routers. Using "soft-reconfiguration inbound" means you can make
changes dynamically without clearing the BGP session. This reduces down time
as routes are exchanged. However, it requires more RAM (equivalent to the size
of the BGP route table from each peer). On a Linux box with Quagga, that's not
likely to be a problem.

Regards,
Tyler

On Wednesday 01 Sep 2010 12:23:32 Sami Halabi wrote:
> Tyler,
> That sounds okay, but how it doesn't complete the picture on AS200 (that is
> connected to my AS300 and AS100 also), i want it to somehow prefer traffic
> that is destinated to AS300 and its source address (origin) from one of its
> networks to go through AS100, and if not to route traffic through AS300
> directly.
>
> Thanks again,
> Sami
>
--
"It is wrong to think that the task of physics is to find out how nature
is. Physics concerns what we can say about nature."
  -- Niels Bohr

_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 2 comments |
headers
Sami Halabi | 1 Sep 2010 23:10
Picon

[quagga-users 11746] Re: BGP Help

BTW: the remote-as in the configuration should be 100 and 200 right?

On Thu, Sep 2, 2010 at 12:08 AM, Sami Halabi <sodynet1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Tyler,
Thank you for your detailed response, but maybe i didn't explain well...
AS100 doesn't allow traffic that originated by an AS that isn't a peering with it.
so lets say AS400 is reachable via AS200, the packets should flow between AS200 and AS300 directly as transit to AS400.
however traffic that is destinated to AS500 which is a peering member of AS100 should go through AS100 directly, and only in backup case AS100 isn't linked then the traffic should try to flow over AS200.

I appreciate very much your help, this is my last piece of the puzzle, and why i think needs AS200 (and maybe AS300) to do more configuration.

Sami

2010/9/1 Tyler J. Wagner <tyler-/4Na+MoQkKtBDgjK7y7TUQ@public.gmane.org>
Sami,


To do that, just prefix your announcement to AS200. This will cause your
announced space to AS200 to appear to have a longer AS path, so other networks
prefer the AS100 route. Do something like the the following (substitute
appropriate AS and IP numbers, of course).

router bgp 300
 neighbor AS100 peer-group
 neighbor AS100 remote-as 300
 neighbor AS100 soft-reconfiguration inbound
 neighbor AS200 peer-group
 neighbor AS200 remote-as 300
 neighbor AS200 soft-reconfiguration inbound
 neighbor AS200 route-map prepend out
 neighbor 10.0.200.1 peer-group AS200
 neighbor 10.0.100.1 peer-group AS100

route-map prepend permit 10
 set as-path prepend 300 300

That will cause your routes via AS200 to have a path of "200 300 300 300", and
your routes via AS100 to have a path of "100 300", which is shorter and would
be preferred.

Using peer groups makes it easier to add multiple upstream IPs in case of
redundant routers. Using "soft-reconfiguration inbound" means you can make
changes dynamically without clearing the BGP session. This reduces down time
as routes are exchanged. However, it requires more RAM (equivalent to the size
of the BGP route table from each peer). On a Linux box with Quagga, that's not
likely to be a problem.

Regards,
Tyler

On Wednesday 01 Sep 2010 12:23:32 Sami Halabi wrote:
> Tyler,
> That sounds okay, but how it doesn't complete the picture on AS200 (that is
> connected to my AS300 and AS100 also), i want it to somehow prefer traffic
> that is destinated to AS300 and its source address (origin) from one of its
> networks to go through AS100, and if not to route traffic through AS300
> directly.
>
> Thanks again,
> Sami
>
--
"It is wrong to think that the task of physics is to find out how nature
is. Physics concerns what we can say about nature."
  -- Niels Bohr


_______________________________________________
Quagga-users mailing list
Quagga-users@...
http://lists.quagga.net/mailman/listinfo/quagga-users
Permalink | Reply | 1 comment |

Gmane