Re: Check on routes announced by peer

2011-02-14 Thread Simone Morandini

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.



Re: Check on routes announced by peer

2011-02-10 Thread Ondrej Zajicek
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: 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.


signature.asc
Description: Digital signature


Re: Check on routes announced by peer

2011-02-09 Thread Simone Morandini

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.



Re: Check on routes announced by peer

2011-02-09 Thread Arnold Nipper
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: arn...@nipper.de   phone: +49 6224 9259 299
mobile: +49 152 53717690  fax:   +49 6224 9259 333



signature.asc
Description: OpenPGP digital signature


Re: Check on routes announced by peer

2011-02-01 Thread Simone Morandini

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.



Re: Check on routes announced by peer

2011-01-30 Thread Mikhail A. Grishin
On Sun, 30 Jan 2011 03:29:45 +, Nick
n...@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.



Re: Check on routes announced by peer

2011-01-29 Thread Nick
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


Check on routes announced by peer

2011-01-28 Thread Simone Morandini

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.



Re: Check on routes announced by peer

2011-01-28 Thread Arnold Nipper
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: arn...@nipper.de   phone: +49 6224 9259 299
mobile: +49 152 53717690  fax:   +49 6224 9259 333



signature.asc
Description: OpenPGP digital signature