Re: vpn6-mpls routes on BIRD 2
That was it! Thank you!
In case it is useful for anyone else, here's my entire config (ASNs and IPs
anonymized):
# start config
router id 127.0.0.1;
vpn4 table vpntab4;
vpn6 table vpntab6;
protocol bgp peer1 {
local as 65321;
neighbor 192.168.42.1 as 65321;
hold time 180;
vpn4 mpls {
table vpntab4;
import all;
};
vpn6 mpls {
table vpntab6;
import all;
extended next hop;
};
}
# end config
On Fri, Aug 24, 2018 at 12:24 PM Jan Maria Matejka
wrote:
> I suspect you are missing the "extended next hop" option in your
> BGP protocol config.
>
> Thanks
> Maria
>
> On 08/24/2018 07:02 PM, Chris Herdt wrote:
> > When I run bird in debug mode, I do see a lot of messages about missing
> next hop:
> >
> > bird: peer1: Missing next hop address
> > bird: peer1: Invalid NEXT_HOP attribute
> > bird: peer1: Invalid NEXT_HOP attribute
> > bird: peer1: Invalid NEXT_HOP attribute
> > [etc.]
> >
> > When I examine the update packets coming in for IPv6 route
> announcements, the next hop is an IPv4 address in this format (addresses
> changed for anonymity):
> >
> > :::192.168.42.6
> >
> > I have also tried a couple different things in my config files to
> explicitly set the next hop address, but the next hop address is still
> missing:
> >
> > filter setnexthop
> > ip explicit_next_hop;
> > {
> > explicit_next_hop = fd12:3456:789a:1::1;
> > bgp_next_hop = explicit_next_hop;
> > accept;
> > }
> >
> > ...
> >
> > vpn6 mpls {
> > table vpntab6;
> > missing lladdr ignore;
> > next hop self;
> > import filter setnexthop;
> > };
> >
> >
> > Anyone have any advice?
> >
> > Thanks,
> >
> > On Thu, Aug 23, 2018 at 8:42 PM Arvin Gan a...@advaoptical.com>> wrote:
> >
> > Hi ,
> >
> > From your protocols info, “BGP Next hop: ::” in channel
> vpn6-mpls, if next hop is empty, the route is withdrawn. Suggest to check
> it.
> >
> > __ __
> >
> > Best Regards,
> >
> > Arvin Gan
> >
> > __ __
> >
> > *From:*Bird-users bird-users-boun...@network.cz>> *On Behalf Of *Chris Herdt
> > *Sent:* Friday, August 24, 2018 5:48 AM
> > *To:* bird-users@network.cz
> > *Subject:* vpn6-mpls routes on BIRD 2
> >
> > __ __
> >
> > Thanks to the list for all the help you've given me so far!
> >
> > __ __
> >
> > Another question: I am running BIRD 2.0.2 and peering with a host
> that is announcing vpn4 mpls and vpn6 mpls routes.
> >
> > __ __
> >
> > The vpn4 mpls routes are working, but all of the vpn6 mpls routes
> appear as withdrawn routes. I'm not sure why -- I looked at the packet
> capture in Wireshark and the UPDATE messages containing the IPv6 routes all
> show zero for Withdrawn Routes Length. Any ideas?
> >
> > __ __
> >
> > Here's the result of 'show protocols all peer1' (addresses
> changed):
> >
> > __ __
> >
> > bird> show protocols all peer1
> > Name Proto Table State Since Info
> > peer1 BGP---up 14:35:04.353 Established
> > BGP state: Established
> > Neighbor address: 192.168.42.1
> > Neighbor AS: 65321
> > Neighbor ID: 192.168.42.1
> > Local capabilities
> > Multiprotocol
> > AF announced: vpn4-mpls vpn6-mpls
> > Route refresh
> > Graceful restart
> > 4-octet AS numbers
> > Enhanced refresh
> > Neighbor capabilities
> > Multiprotocol
> > AF announced: vpn4-mpls vpn6-mpls
> > Route refresh
> > Extended next hop
> > IPv6 nexthop: ipv4 ipv4-mc
> > Graceful restart
> > Restart time: 120
> > AF supported: vpn4-mpls vpn6-mpls
> > AF preserved:
> > 4-octet AS numbers
> > Session: internal multihop AS4
> > Source address: 192.168.100.1
> > Hold timer: 12.954/15
> > Keepalive timer: 0.005/5
> > Channel vpn4-mpls
> > State: UP
> > Table: vpntab4
> > Preference: 100
> > Input filter: ACCEPT
> > Output filter: REJECT
> > Routes: 9771 imported, 0 exported
> > Route change stats: received rejected filtered
> ignored accepted
> > Import updates: 9771 0 0
> 0 9771
> > Import withdraws: 20 0---
> 20 0
> > Export updates: 9771 9771 0
> --- 0
> > Export withdraws:0------
> --- 0
> > BGP Next hop: 192.168.100.1
> > IGP IPv4 table: master4
> >
Re: vpn6-mpls routes on BIRD 2
I suspect you are missing the "extended next hop" option in your
BGP protocol config.
Thanks
Maria
On 08/24/2018 07:02 PM, Chris Herdt wrote:
> When I run bird in debug mode, I do see a lot of messages about missing next
> hop:
>
> bird: peer1: Missing next hop address
> bird: peer1: Invalid NEXT_HOP attribute
> bird: peer1: Invalid NEXT_HOP attribute
> bird: peer1: Invalid NEXT_HOP attribute
> [etc.]
>
> When I examine the update packets coming in for IPv6 route announcements, the
> next hop is an IPv4 address in this format (addresses changed for anonymity):
>
> :::192.168.42.6
>
> I have also tried a couple different things in my config files to explicitly
> set the next hop address, but the next hop address is still missing:
>
> filter setnexthop
> ip explicit_next_hop;
> {
> explicit_next_hop = fd12:3456:789a:1::1;
> bgp_next_hop = explicit_next_hop;
> accept;
> }
>
> ...
>
> vpn6 mpls {
> table vpntab6;
> missing lladdr ignore;
> next hop self;
> import filter setnexthop;
> };
>
>
> Anyone have any advice?
>
> Thanks,
>
> On Thu, Aug 23, 2018 at 8:42 PM Arvin Gan > wrote:
>
> Hi ,
>
> From your protocols info, “BGP Next hop: ::” in channel vpn6-mpls,
> if next hop is empty, the route is withdrawn. Suggest to check it.
>
> __ __
>
> Best Regards,
>
> Arvin Gan
>
> __ __
>
> *From:*Bird-users > *On Behalf Of *Chris Herdt
> *Sent:* Friday, August 24, 2018 5:48 AM
> *To:* bird-users@network.cz
> *Subject:* vpn6-mpls routes on BIRD 2
>
> __ __
>
> Thanks to the list for all the help you've given me so far!
>
> __ __
>
> Another question: I am running BIRD 2.0.2 and peering with a host that is
> announcing vpn4 mpls and vpn6 mpls routes.
>
> __ __
>
> The vpn4 mpls routes are working, but all of the vpn6 mpls routes appear
> as withdrawn routes. I'm not sure why -- I looked at the packet capture in
> Wireshark and the UPDATE messages containing the IPv6 routes all show zero
> for Withdrawn Routes Length. Any ideas?
>
> __ __
>
> Here's the result of 'show protocols all peer1' (addresses changed):
>
> __ __
>
> bird> show protocols all peer1
> Name Proto Table State Since Info
> peer1 BGP --- up 14:35:04.353 Established
> BGP state: Established
> Neighbor address: 192.168.42.1
> Neighbor AS: 65321
> Neighbor ID: 192.168.42.1
> Local capabilities
> Multiprotocol
> AF announced: vpn4-mpls vpn6-mpls
> Route refresh
> Graceful restart
> 4-octet AS numbers
> Enhanced refresh
> Neighbor capabilities
> Multiprotocol
> AF announced: vpn4-mpls vpn6-mpls
> Route refresh
> Extended next hop
> IPv6 nexthop: ipv4 ipv4-mc
> Graceful restart
> Restart time: 120
> AF supported: vpn4-mpls vpn6-mpls
> AF preserved:
> 4-octet AS numbers
> Session: internal multihop AS4
> Source address: 192.168.100.1
> Hold timer: 12.954/15
> Keepalive timer: 0.005/5
> Channel vpn4-mpls
> State: UP
> Table: vpntab4
> Preference: 100
> Input filter: ACCEPT
> Output filter: REJECT
> Routes: 9771 imported, 0 exported
> Route change stats: received rejected filtered ignored
> accepted
> Import updates: 9771 0 0 0
> 9771
> Import withdraws: 20 0 --- 20
> 0
> Export updates: 9771 9771 0 ---
> 0
> Export withdraws: 0 --- --- ---
> 0
> BGP Next hop: 192.168.100.1
> IGP IPv4 table: master4
> Channel vpn6-mpls
> State: UP
> Table: vpntab6
> Preference: 100
> Input filter: ACCEPT
> Output filter: REJECT
> Routes: 0 imported, 0 exported
> Route change stats: received rejected filtered ignored
> accepted
> Import updates: 0 0 0 0
> 0
> Import withdraws: 2785 0 --- 2785
> 0
> Export updates: 0 0 0 ---
> 0
> Export withdraws: 0 --- --- ---
> 0
> BGP Next hop: ::
> IGP IPv6 table: master6
>
>
Re: bug or documentation bug
On Fri, Aug 24, 2018 at 05:58:08PM +0200, Clemens Schrimpe wrote: > Hello - > > the manual explains a global protocol option: > > description "text" > This is an optional description of the protocol. It is displayed as a part of > the output of 'show route all' command. Hello It should be 'show protocols all' command. Thanks, fixed. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
bug or documentation bug
Hello - the manual explains a global protocol option: description "text" This is an optional description of the protocol. It is displayed as a part of the output of 'show route all' command. But it doesn’t work (any more?). Tiny thing, just wanted to mention it. Greetings, Clemens
Re: BFD protocol doesn't send packets after link flap up on switch
I've found a workaround for this issue. Seems that crucial is line "2018-08-24 14:07:38 bfd1: Session to 172.30.2.1 added" I'm assuming what's happening here is that Bird selects another interface as source which doesn't have connectivity and never goes back to proper interface after it comes back up. As a workaround I've used explicit BFD neighbor declaration with local IP specified: "neighbor ip [dev "interface"] [local ip] [multihop switch]" After adding this line to config BFD started working as expected. Above behavior might be however problematic with higher number of peers. On Fri, Aug 24, 2018 at 2:45 PM Jakub Nowacki wrote: > Hi, > > I have multihop BGP peering with BFD setup on it. One of the peers is a > switch that runs Linux. I've run into situation where after link flap on > interface that switch connects to BFD protocol after successfully detecting > that flap BFD session cannot reestablich because switch side stops sending > BFD packets. I'm suspecting that this is due to switch behavior that > removes IP address of link when it goes down (BGP and BFD are using > interface ip address to connect). Bird is trying to bind to IP address that > is no longer available and that causes the issue. > > Logs below show following events > 1. Correct BFD packet exchange > 2. Link flaps at 14:07:38 > 3. Link is back up, starts receiving BFD packets from peer and state > changes from Down to Init at 14:07:45. Note that no BFD packets are being > generated, where they should be. > 4. Removing 'bfd;' line and reconfiguring at 14:08:31 > 5. Adding 'bfd; line and reconfiguring at 14:08:47 which successfully > restart BFD. > > 2018-08-24 14:07:37 bfd1: CTL received from 172.30.2.1 [Up A] > 2018-08-24 14:07:37 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: CTL received from 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: CTL received from 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Socket error: Invalid argument > 2018-08-24 14:07:38 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Socket error: Invalid argument > 2018-08-24 14:07:38 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Socket error: Invalid argument > 2018-08-24 14:07:38 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Socket error: Invalid argument > 2018-08-24 14:07:38 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:07:38 bfd1: Socket error: Invalid argument > 2018-08-24 14:07:38 bfd1: Session to 172.30.2.1 expired > 2018-08-24 14:07:38 bfd1: Session to 172.30.2.1 changed state from > Up to Down > 2018-08-24 14:07:38 bgp_gw_rs_1: BFD session down > 2018-08-24 14:07:38 bfd1: Session to 172.30.2.1 removed > 2018-08-24 14:07:38 bfd1: Socket error: bind: Cannot assign > requested address > 2018-08-24 14:07:38 bfd1: Session to 172.30.2.1 added > 2018-08-24 14:07:44 bfd1: CTL received from 172.30.2.1 [Down A] > 2018-08-24 14:07:44 bfd1: Session to 172.30.2.1 changed state from > Down to Init > 2018-08-24 14:07:45 bfd1: CTL received from 172.30.2.1 [Down A] > 2018-08-24 14:07:46 bfd1: CTL received from 172.30.2.1 [Down A] > 2018-08-24 14:07:46 bfd1: CTL received from 172.30.2.1 [Down A] > 2018-08-24 14:07:47 bfd1: CTL received from 172.30.2.1 [Down A] > ... > 2018-08-24 14:08:30 bfd1: CTL received from 172.30.2.1 [Down A] > 2018-08-24 14:08:31 bfd1: CTL received from 172.30.2.1 [Down A] > 2018-08-24 14:08:31 bfd1: Session to 172.30.2.1 removed > 2018-08-24 14:08:31 bfd1: Reconfigured > 2018-08-24 14:08:47 bfd1: Session to 172.30.2.1 added > 2018-08-24 14:08:47 bfd1: Session to 172.30.2.1 reconfigured > 2018-08-24 14:08:47 bfd1: Reconfigured > 2018-08-24 14:08:47 bfd1: CTL received from 172.30.2.1 [Down A] > 2018-08-24 14:08:47 bfd1: Session to 172.30.2.1 changed state from > Down to Init > 2018-08-24 14:08:47 bfd1: Sending CTL to 172.30.2.1 [Init A] > 2018-08-24 14:08:47 bfd1: CTL received from 172.30.2.1 [Up PA] > 2018-08-24 14:08:47 bfd1: Session to 172.30.2.1 changed state from > Init to Up > 2018-08-24 14:08:47 bfd1: Sending CTL to 172.30.2.1 [Up FA] > 2018-08-24 14:08:47 bfd1: Sending CTL to 172.30.2.1 [Up PA] > 2018-08-24 14:08:47 bfd1: CTL received from 172.30.2.1 [Up FA] > 2018-08-24 14:08:47 bfd1: CTL received from 172.30.2.1 [Up A] > 2018-08-24 14:08:47 bfd1: Sending CTL to 172.30.2.1 [Up A] > 2018-08-24 14:08:47 bfd1: CTL received from 172.30.2.1 [Up A] > 2018-08-24 14:08:47 bfd1: Sending CTL to 172.30.2.1 [Up A] > > > Kuba Nowacki > -- Kuba Nowacki Senior NetOps M: +(48) 605 508 118 E: jnowa...@greywizard.com GreyWizard Sp. z o.o. ul. Palacza 113 60-273 Poznań, Poland NIP: 779-24-22-423 Regon: 302744400 KRS: 512326 greywizard.com
