Hello.
Recently I started doing some basic simulations for traffic engineering
using my old Imunes with quagga, and I was suprised that my simple
config didnt work at all.
This is due how community-list are implemented. I guess its not
a quagga specific implementation but rather RFC. Anyway, I want
to ask community how you feel with current implementation.
I guess there are opers who do much more complicated, and so
how you actualy do it.. Tons of route-maps?
Below goes the config.. Im NO expert in BGP, if this can be implemented
better and cleaner using standard community matching, please let me show.
For me, current implementation is not flexible. Using community-list
looks useless, 'route-map match community' would be better using
communities directly instead of community-list.. etc.. etc..
With the changes I introduced to community matching, this config
works fine.. everything is announced where it should and it looks
very clear and readable to me.
Here is diff against old quagga (yes, I know its old.. I have my reasons,
lets not discuss this issue, I checked how its implemented in master
of current quagga, and it looks like nothing changed there):
http://borg.uu3.net/cgit/cgit.cgi/OEM.MY/quagga-0.99.15/commit/?h=bp_generic&id=2c7dcd91044e8a6844db20db5a8d646054464700
Implementation might NOT be perfect and might have bugs. Its here to start
discuss about how community matching could be done better (In my opinion).
Regards,
Borg
CUST: means its our customer (he pays us for transit)
PEER: its our peering agreenment
TRANS: its our provider (we pay him for transit)
=========== BGP config =================================================
router bgp 1
bgp router-id 172.16.0.26
network 10.0.1.0/24 route-map LOCAL
neighbor 172.16.0.2 remote-as 2
neighbor 172.16.0.2 route-map CUST-IN in
neighbor 172.16.0.2 route-map CUST-OUT out
neighbor 172.16.0.14 remote-as 3
neighbor 172.16.0.14 route-map PEER-IN in
neighbor 172.16.0.14 route-map PEER-OUT out
neighbor 172.16.0.25 remote-as 4
neighbor 172.16.0.25 route-map TRANS-IN in
neighbor 172.16.0.25 route-map TRANS-OUT out
neighbor 172.16.0.30 remote-as 5
neighbor 172.16.0.30 route-map PEER-IN in
neighbor 172.16.0.30 route-map PEER-OUT out
!
ip community-list 10 permit 1:0 1:10 1:20 1:30
ip community-list 20 permit 1:0 1:10
ip community-list 30 permit 1:0 1:10
!
route-map LOCAL permit 10
set community 1:0
!
route-map CUST-IN permit 10
set community 1:10
!
route-map CUST-OUT permit 10
match community 10
!
route-map PEER-IN permit 10
set community 1:20
!
route-map PEER-OUT permit 10
match community 20
!
route-map TRANS-IN permit 10
set community 1:30
!
route-map TRANS-OUT permit 10
match community 30
!
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
Recently I started doing some basic simulations for traffic engineering
using my old Imunes with quagga, and I was suprised that my simple
config didnt work at all.
This is due how community-list are implemented. I guess its not
a quagga specific implementation but rather RFC. Anyway, I want
to ask community how you feel with current implementation.
I guess there are opers who do much more complicated, and so
how you actualy do it.. Tons of route-maps?
Below goes the config.. Im NO expert in BGP, if this can be implemented
better and cleaner using standard community matching, please let me show.
For me, current implementation is not flexible. Using community-list
looks useless, 'route-map match community' would be better using
communities directly instead of community-list.. etc.. etc..
With the changes I introduced to community matching, this config
works fine.. everything is announced where it should and it looks
very clear and readable to me.
Here is diff against old quagga (yes, I know its old.. I have my reasons,
lets not discuss this issue, I checked how its implemented in master
of current quagga, and it looks like nothing changed there):
http://borg.uu3.net/cgit/cgit.cgi/OEM.MY/quagga-0.99.15/commit/?h=bp_generic&id=2c7dcd91044e8a6844db20db5a8d646054464700
Implementation might NOT be perfect and might have bugs. Its here to start
discuss about how community matching could be done better (In my opinion).
Regards,
Borg
CUST: means its our customer (he pays us for transit)
PEER: its our peering agreenment
TRANS: its our provider (we pay him for transit)
=========== BGP config =================================================
router bgp 1
bgp router-id 172.16.0.26
network 10.0.1.0/24 route-map LOCAL
neighbor 172.16.0.2 remote-as 2
neighbor 172.16.0.2 route-map CUST-IN in
neighbor 172.16.0.2 route-map CUST-OUT out
neighbor 172.16.0.14 remote-as 3
neighbor 172.16.0.14 route-map PEER-IN in
neighbor 172.16.0.14 route-map PEER-OUT out
neighbor 172.16.0.25 remote-as 4
neighbor 172.16.0.25 route-map TRANS-IN in
neighbor 172.16.0.25 route-map TRANS-OUT out
neighbor 172.16.0.30 remote-as 5
neighbor 172.16.0.30 route-map PEER-IN in
neighbor 172.16.0.30 route-map PEER-OUT out
!
ip community-list 10 permit 1:0 1:10 1:20 1:30
ip community-list 20 permit 1:0 1:10
ip community-list 30 permit 1:0 1:10
!
route-map LOCAL permit 10
set community 1:0
!
route-map CUST-IN permit 10
set community 1:10
!
route-map CUST-OUT permit 10
match community 10
!
route-map PEER-IN permit 10
set community 1:20
!
route-map PEER-OUT permit 10
match community 20
!
route-map TRANS-IN permit 10
set community 1:30
!
route-map TRANS-OUT permit 10
match community 30
!
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev