Hi all, a (hopefully) quick question: one of our peer says it is announcing a set of network to the route server, but there routes do not actually appear to be there... If I issue a "sh route protocol <PEER>" the list is empty, as well as if I issue "sh route where bgp_path.first=<peer-as>". Is there a way to check if those network actually arrive to the route server? Thanks, Simone. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Ciao Simone, on 28.01.2011 18:18 Simone Morandini wrote:
a (hopefully) quick question: one of our peer says it is announcing a set of network to the route server, but there routes do not actually appear to be there... If I issue a "sh route protocol <PEER>" the list is empty, as well as if I issue "sh route where bgp_path.first=<peer-as>". Is there a way to check if those network actually arrive to the route server?
very much depends on how your config looks like. If you don't have any incoming filters you should be able to see any announcement. Worst case is that you will have to sniff on the interface to see what's going on. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333
On Sat, Jan 29, 2011 at 04:02:32AM +0100, Arnold Nipper wrote:
Ciao Simone,
on 28.01.2011 18:18 Simone Morandini wrote:
a (hopefully) quick question: one of our peer says it is announcing a set of network to the route server, but there routes do not actually appear to be there... If I issue a "sh route protocol <PEER>" the list is empty, as well as if I issue "sh route where bgp_path.first=<peer-as>". Is there a way to check if those network actually arrive to the route server?
very much depends on how your config looks like. If you don't have any incoming filters you should be able to see any announcement.
Worst case is that you will have to sniff on the interface to see what's going on.
or set debug for their protocol and check the log -- Wanna turn ICANN into ICANN't? Join a darknet today: http://www.anonet2.org/darknet_comparison
On Sun, 30 Jan 2011 03:29:45 +0000, Nick <nick@somerandomnick.ano.mailgate.vanet.org> wrote:
On Sat, Jan 29, 2011 at 04:02:32AM +0100, Arnold Nipper wrote:
Ciao Simone,
on 28.01.2011 18:18 Simone Morandini wrote:
a (hopefully) quick question: one of our peer says it is announcing a set of network to the route server, but there routes do not actually appear to be there... If I issue a "sh route protocol <PEER>" the list is empty, as well as if I issue "sh route where bgp_path.first=<peer-as>". Is there a way to check if those network actually arrive to the route server?
very much depends on how your config looks like. If you don't have any incoming filters you should be able to see any announcement.
Worst case is that you will have to sniff on the interface to see what's going on.
or set debug for their protocol and check the log
In the scenario where filters was applied on pipes, not on BGP protocols, all received routes can be viewed via CLI: show route protocol <PEER> table <TABLE_FOR_THAT_PEER>.
Mikhail A. Grishin wrote:
In the scenario where filters was applied on pipes, not on BGP protocols, all received routes can be viewed via CLI: show route protocol <PEER> table <TABLE_FOR_THAT_PEER>.
thanks Mikhail, using the command you suggested I actually see the networks, so it looks like they are not propagated to the peers. If I look for one of these networks in the logfile I see something like: 25-01-2011 12:48:28 <TRACE> peername > removed [sole] <peer-network> via <peer-ip> on eth0 25-01-2011 15:20:11 <TRACE> peername > added [best] <peer-network> via <peer-ip> on eth0 My config file is generated automatically, so there are (or should be) no differences from one peer to the other... Thanks, Simone. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Hi all,
In the scenario where filters was applied on pipes, not on BGP protocols, all received routes can be viewed via CLI: show route protocol <PEER> table <TABLE_FOR_THAT_PEER>.
apologies for "upping" my thread, but I'd like to solve this issue... With the above suggested command, "show route protocol <PEER> table <TABLE_FOR_THAT_PEER>", I do see the networks of that peer, so it looks like he is announcing correctly to the route server. Anyway, I don't see these routes propagated to the peers, neither with "show route where bgp_path.first=<peeras>" from birdc, nor from the peering router... Where should I look for those "lost" networks? Filtering is done the very same way as for the other peers, as the config file is generated through a script. Thanks a lot, Simone. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Simone, on 09.02.2011 18:32 Simone Morandini wrote:
Hi all,
In the scenario where filters was applied on pipes, not on BGP protocols, all received routes can be viewed via CLI: show route protocol <PEER> table <TABLE_FOR_THAT_PEER>.
apologies for "upping" my thread, but I'd like to solve this issue... With the above suggested command, "show route protocol <PEER> table <TABLE_FOR_THAT_PEER>", I do see the networks of that peer, so it looks like he is announcing correctly to the route server. Anyway, I don't see these routes propagated to the peers, neither with "show route where bgp_path.first=<peeras>" from birdc, nor from the peering router...
Where should I look for those "lost" networks? Filtering is done the very same way as for the other peers, as the config file is generated through a script.
did you check manually that these networks would really pass all your filters (as-path, prefix, whatever you are applying). From my experience 100% the cases come from customers not having registered their prefixes with RIPE. HTH, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333
Hi all,
did you check manually that these networks would really pass all your filters (as-path, prefix, whatever you are applying).
thanks for the suggestion, the problem was exactly this: I was mistakenly building the configuration file, so the networks listed there were similar but different from the networks actually announced, and BIRD was correctly filtering them (I didn't realize this at first). Thanks for the support, Simone. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Wed, Feb 09, 2011 at 06:32:21PM +0100, Simone Morandini wrote:
Hi all,
In the scenario where filters was applied on pipes, not on BGP protocols, all received routes can be viewed via CLI: show route protocol <PEER> table <TABLE_FOR_THAT_PEER>.
apologies for "upping" my thread, but I'd like to solve this issue... With the above suggested command, "show route protocol <PEER> table <TABLE_FOR_THAT_PEER>", I do see the networks of that peer, so it looks like he is announcing correctly to the route server.
So if you have the prefixes in the peer-local table and not in global table, then the problem is in the pipe between tables. You should enable debugging for that pipe (command debug PIPE_NAME all) and examine the log. -- 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."
participants (5)
-
Arnold Nipper -
Mikhail A. Grishin -
Nick -
Ondrej Zajicek -
Simone Morandini