Hello again!
I'm working with bgpd's views for IPv6 peers and I've found that it's
impossible to activate the same peer in more than one view. The configuration
that I'm using is the following:
bgp multiple-instance
!
router bgp 65000 view V1
no bgp default ipv4-unicast
neighbor 3ffe:ffff:ffff:ffff::1 remote-as 65001
neighbor 3ffe:ffff:ffff:ffff::2 remote-as 65002
!
address-family ipv6
neighbor 3ffe:ffff:ffff:ffff::1 activate
neighbor 3ffe:ffff:ffff:ffff::2 activate
exit-address-family
!
router bgp 65000 view V2
no bgp default ipv4-unicast
neighbor 3ffe:ffff:ffff:ffff::2 remote-as 65002
neighbor 3ffe:ffff:ffff:ffff::3 remote-as 65003
!
address-family ipv6
neighbor 3ffe:ffff:ffff:ffff::2 activate
neighbor 3ffe:ffff:ffff:ffff::3 activate
exit-address-family
!
When I try such configuration, the peering to 3ffe:ffff:ffff:ffff::2 in the
second view doesn't become established (it stops in the ACTIVE state).
I've been looking the sources, and apparently the problem is that quagga's
bgpd creates a new "struct peer" for each of the two peerings with
3ffe:ffff:ffff:ffff::2, and thereby it tries to establish two different
connections with that peer, but that it's not good because the remote peer
only wants to establish a single connection (it knows nothing about the two
views).
Before using quagga I was working with zebra_0.92a, and I didn't find such
problem with the same configuration. The reason is that in zebra_0.92a the
concepts of "peer" (struct peer) and "peer configuration" (struct peer_conf)
are separated, and in a configuration like the one above it would only create
one "struct peer" (which means only one connection) and two different "struct
peer_conf", one for each view.
This sounds more reasonable to me, so I don't understand why it was changed.
Sorry about the technical details (structs names...), but perhaps someone
knows why the structures were changed.
Any help will be welcome. Thanks in advance!
Jose Luis
I'm working with bgpd's views for IPv6 peers and I've found that it's
impossible to activate the same peer in more than one view. The configuration
that I'm using is the following:
bgp multiple-instance
!
router bgp 65000 view V1
no bgp default ipv4-unicast
neighbor 3ffe:ffff:ffff:ffff::1 remote-as 65001
neighbor 3ffe:ffff:ffff:ffff::2 remote-as 65002
!
address-family ipv6
neighbor 3ffe:ffff:ffff:ffff::1 activate
neighbor 3ffe:ffff:ffff:ffff::2 activate
exit-address-family
!
router bgp 65000 view V2
no bgp default ipv4-unicast
neighbor 3ffe:ffff:ffff:ffff::2 remote-as 65002
neighbor 3ffe:ffff:ffff:ffff::3 remote-as 65003
!
address-family ipv6
neighbor 3ffe:ffff:ffff:ffff::2 activate
neighbor 3ffe:ffff:ffff:ffff::3 activate
exit-address-family
!
When I try such configuration, the peering to 3ffe:ffff:ffff:ffff::2 in the
second view doesn't become established (it stops in the ACTIVE state).
I've been looking the sources, and apparently the problem is that quagga's
bgpd creates a new "struct peer" for each of the two peerings with
3ffe:ffff:ffff:ffff::2, and thereby it tries to establish two different
connections with that peer, but that it's not good because the remote peer
only wants to establish a single connection (it knows nothing about the two
views).
Before using quagga I was working with zebra_0.92a, and I didn't find such
problem with the same configuration. The reason is that in zebra_0.92a the
concepts of "peer" (struct peer) and "peer configuration" (struct peer_conf)
are separated, and in a configuration like the one above it would only create
one "struct peer" (which means only one connection) and two different "struct
peer_conf", one for each view.
This sounds more reasonable to me, so I don't understand why it was changed.
Sorry about the technical details (structs names...), but perhaps someone
knows why the structures were changed.
Any help will be welcome. Thanks in advance!
Jose Luis