Re: Touble ospf md5 authentication
On Fri, Mar 19, 2010 at 05:52:04PM +0159, Vitaliy Kolodinsky wrote:
> In area 0.0.0.2 works some Cisco routers, Quagga and experimental
> BIRD. Cisco and Quagga work perfectly together.
> Cisco at the end of OSPF Hello packet sent LLS Data Block.
> Quagga this unit is not sending.
> LLS Data Block is mentioned in the IETF RFC 4813
> May participate in the testing.
Hello
Could you try attached patch to BIRD 1.2.1? That should fix this issue.
--
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."
diff -uprN bird-1.2.1/proto/ospf/packet.c bird-1.2.1-/proto/ospf/packet.c
--- bird-1.2.1/proto/ospf/packet.c 2010-01-14 11:06:27.0 +0100
+++ bird-1.2.1-/proto/ospf/packet.c 2010-03-19 19:24:47.0 +0100
@@ -179,7 +179,7 @@ ospf_pkt_checkauth(struct ospf_neighbor
return 0;
}
- if (ntohs(pkt->length) + OSPF_AUTH_CRYPT_SIZE != size)
+ if (ntohs(pkt->length) + OSPF_AUTH_CRYPT_SIZE < size)
{
OSPF_TRACE(D_PACKETS, "OSPF_auth: size mismatch (%d vs %d)",
ntohs(pkt->length) + OSPF_AUTH_CRYPT_SIZE, size);
signature.asc
Description: Digital signature
Re: Touble ospf md5 authentication
On Fri, Mar 19, 2010 at 06:11:51PM +0100, Csaba Szép wrote: > Hello! > > In my opinion, this is the same issue that i reported at 2009.10.05 in > this list. Hello It is similar (also related to LLS) but not the same issue. The problem you reported (with error message 'received: options mismatch') was fixed in version 1.2.0 (i hope). This one is specific to usage of MD5 auth together with LLS. -- 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: Touble ospf md5 authentication
Hello! Of course this is only a workaround But. I use this command with Cisco 7200 12.2(28)SB5 software, which is older than 12.3(21) Another temporaly solution is to disable lls globally . router ospf 1 router-id 10.0.0.2 no capability lls 2010/3/19 Vitaliy Kolodinsky : > Dear, Csaba Szép. > > Вы писали 19 марта 2010 г., 19:11:51: > >> In my opinion, this is the same issue that i reported at 2009.10.05 in >> this list. > >> Then i disabled LLS in the cisco side, and after everything works well. > > >> ip ospf lls disable > > Using the ip ospf lls disable probably quite a good temporary solution, but > the old IOS, this command is not > > bras7 (config-subif) # ip ospf lls disa > ^ > % Invalid input detected at '^' marker. > > bras7 (config-subif) # do sh ver > Cisco Internetwork Operating System Software > IOS (tm) 7200 Software (C7200-JS-M), Version 12.3 (21), RELEASE SOFTWARE (fc2) > Technical Support: http://www.cisco.com/techsupport > > > With pleasure I will see a patch from the author > and with no less pleasure test the patch work. > > -- > > Best regards, > Vitaliy > Kolodinsky > BYVK-RIPE > ISP Atlant Telecom > kolodin...@telecom.by > >
Re: Touble ospf md5 authentication
Dear, Csaba Szép. Вы писали 19 марта 2010 г., 19:11:51: > In my opinion, this is the same issue that i reported at 2009.10.05 in > this list. > Then i disabled LLS in the cisco side, and after everything works well. > ip ospf lls disable Using the ip ospf lls disable probably quite a good temporary solution, but the old IOS, this command is not bras7 (config-subif) # ip ospf lls disa ^ % Invalid input detected at '^' marker. bras7 (config-subif) # do sh ver Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-JS-M), Version 12.3 (21), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport With pleasure I will see a patch from the author and with no less pleasure test the patch work. -- Best regards, Vitaliy Kolodinsky BYVK-RIPE ISP Atlant Telecom kolodin...@telecom.by
Re: minor bird crash
On 19.03.2010 15:02 Ondrej Zajicek wrote > On Fri, Mar 19, 2010 at 01:57:25PM +0100, Arnold Nipper wrote: >> > and if you do are you clearing the bgp sessions (in bird-speak >> > reloading the protocols)? >> > >> >> good question :-) My impression was that "configure soft" should do the >> trick, but I'm not sure whether this really is true. Reloading the pipes >> for instance generates a mssive route update afais. That's definitely >> not what we want. I have even added "prefer older on;" to the bgp >> protocol section to make prefixes more stable across the IXP. > > Essentially, you have three options what to do after a change in filters: > thank you for the detailled explanation. One final question: what does the timestamp attached to routes mean? Like show route 194.0.194.0/24 via 80.81.192.35 on eth0 [R192_35 2010-03-14 16:22:10] * (100) [AS42315?] TIA, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 signature.asc Description: OpenPGP digital signature
Re: Touble ospf md5 authentication
Hello! In my opinion, this is the same issue that i reported at 2009.10.05 in this list. Then i disabled LLS in the cisco side, and after everything works well. ip ospf lls disable 2010/3/19 Ondrej Zajicek : > On Fri, Mar 19, 2010 at 05:52:04PM +0159, Vitaliy Kolodinsky wrote: >> > Hmm, it seems that Cisco just sends some trash after the end of OSPF >> > packet. >> > Perhaps it would suffice to remove the check in BIRD, but i personally >> > don't test this compatibility. >> >> In area 0.0.0.2 works some Cisco routers, Quagga and experimental >> BIRD. Cisco and Quagga work perfectly together. >> Cisco at the end of OSPF Hello packet sent LLS Data Block. >> Quagga this unit is not sending. >> LLS Data Block is mentioned in the IETF RFC 4813 >> May participate in the testing. > > Yes, LLS data blocks in OSPF packets is the cause of the problem. Thank > you for a note, i didn't know about RFC 4813. I will look at this > issue and send you the patch for BIRD to be able to handle LLS data > blocks. > > -- > 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." > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkujrW8ACgkQw1GB2RHercNN4gCeJttuETRAYSEE7Qczl6pYNCMh > YysAn0YWM1ENwQbzx2KJ4lG1hRqUjsUn > =f0t3 > -END PGP SIGNATURE- > >
Re: Touble ospf md5 authentication
On Fri, Mar 19, 2010 at 05:52:04PM +0159, Vitaliy Kolodinsky wrote: > > Hmm, it seems that Cisco just sends some trash after the end of OSPF packet. > > Perhaps it would suffice to remove the check in BIRD, but i personally > > don't test this compatibility. > > In area 0.0.0.2 works some Cisco routers, Quagga and experimental > BIRD. Cisco and Quagga work perfectly together. > Cisco at the end of OSPF Hello packet sent LLS Data Block. > Quagga this unit is not sending. > LLS Data Block is mentioned in the IETF RFC 4813 > May participate in the testing. Yes, LLS data blocks in OSPF packets is the cause of the problem. Thank you for a note, i didn't know about RFC 4813. I will look at this issue and send you the patch for BIRD to be able to handle LLS data blocks. -- 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: Touble ospf md5 authentication
On Fri, Mar 19, 2010 at 04:15:27PM +0159, Vitaliy Kolodinsky wrote: > Dear, Ondrej Zajicek. > > ?? ?? 19 ? 2010 ?., 16:05:04: > > > On Fri, Mar 19, 2010 at 01:57:36PM +0200, Vitaliy Kolodinsky wrote: > >> Dear, bird-us...@atrey.karlin.mff.cuni.cz. > >> > >> Who has a working BIRD 1.2.1 ospf md5 authentication and Cisco? > >> > >> > >> ---Log File-- > >> Mar 16 17:34:52 vulture2 bird: MyOSPF: OSPF_auth: size mismatch (88 vs 124) > >> Mar 16 17:34:52 vulture2 bird: Bad OSPF packet from 93.125.5.141 - > >> authentification failed > > > That is strange, could you send me an output of tcpdump on that packets? > > (tcpdump -s 0 -x) Hmm, it seems that Cisco just sends some trash after the end of OSPF packet. Perhaps it would suffice to remove the check in BIRD, but i personally don't test this compatibility. -- 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: Touble ospf md5 authentication
Dear, Ondrej Zajicek. Вы писали 19 марта 2010 г., 16:05:04: > On Fri, Mar 19, 2010 at 01:57:36PM +0200, Vitaliy Kolodinsky wrote: >> Dear, bird-us...@atrey.karlin.mff.cuni.cz. >> >> Who has a working BIRD 1.2.1 ospf md5 authentication and Cisco? >> >> >> ---Log File-- >> Mar 16 17:34:52 vulture2 bird: MyOSPF: OSPF_auth: size mismatch (88 vs 124) >> Mar 16 17:34:52 vulture2 bird: Bad OSPF packet from 93.125.5.141 - >> authentification failed > That is strange, could you send me an output of tcpdump on that packets? > (tcpdump -s 0 -x) 16:06:51.521476 IP 93.125.5.138 > 224.0.0.5: OSPFv2, Hello, length: 108 0x: 45c0 0090 af0c 0159 c63c 5d7d 058a 0x0010: e000 0005 0201 0048 5d7d 058a 0002 0x0020: 0002 0510 4ba1 5a10 ffe0 0x0030: 000a 1200 0028 5d7d 0587 0x0040: 5d7d 0506 5d7d 0507 5d7d 0586 5d7d 0588 0x0050: 5d7d 058b 5d7d 058c d5b8 e114 6236 9632 0x0060: 077c dcfa 7ea2 cac8 d7c3 af5c 0009 0x0070: 0001 0004 0001 0002 0014 4ba1 5a10 0x0080: 6726 c4b0 26dc 0582 874c 7296 98eb ce77 16:06:53.525031 IP 93.125.5.133 > 224.0.0.5: OSPFv2, Hello, length: 108 0x: 45c0 0090 495f 0159 2bef 5d7d 0585 0x0010: e000 0005 0201 0048 5d7d 0506 0002 0x0020: 0002 0510 4ba2 cd13 ffe0 0x0030: 000a 1200 0028 5d7d 0587 0x0040: 5d7d 0507 5d7d 0586 5d7d 0588 5d7d 058a 0x0050: 5d7d 058b 5d7d 058c d5b8 e114 c33e e87d 0x0060: 19f8 6dd2 3892 e4b8 bf9b 70d7 0009 0x0070: 0001 0004 0001 0002 0014 4ba2 cd13 0x0080: 0f41 ed82 0ae3 c693 6428 af08 8a47 3648 16:06:53.896032 IP 93.125.5.139 > 224.0.0.5: OSPFv2, Hello, length: 108 0x: 45c0 0090 3e6e 0159 36da 5d7d 058b 0x0010: e000 0005 0201 0048 5d7d 058b 0002 0x0020: 0002 0510 4ba2 61c8 ffe0 0x0030: 000a 1200 0028 5d7d 0587 0x0040: 5d7d 0506 5d7d 0507 5d7d 0586 5d7d 0588 0x0050: 5d7d 058a 5d7d 058c d5b8 e114 0c7d 0dac 0x0060: b3fd fd3d 9916 d949 8efd a327 0009 0x0070: 0001 0004 0001 0002 0014 4ba2 61c8 0x0080: b599 46e0 d304 2213 c442 5821 8e1b c562 16:06:54.470461 IP 93.125.5.135 > 224.0.0.5: OSPFv2, LS-Update, length: 64 0x: 45c0 0064 f0b1 0159 84c6 5d7d 0587 0x0010: e000 0005 0204 0040 d5b8 e114 0002 0x0020: 0002 0510 4bac fa49 0001 0x0030: 0e10 2005 0a80 0284 5d7d 0588 8000 0002 0x0040: 4377 0024 00ff 0x0050: 27a9 7d32 4b03 1f70 625c b1ab 0x0060: 1311 6dc0 16:06:54.471771 IP 93.125.5.134 > 224.0.0.6: OSPFv2, LS-Ack, length: 44 0x: 45c0 0050 ba4c 0159 bb3f 5d7d 0586 0x0010: e000 0006 0205 002c 5d7d 0586 0002 0x0020: 0002 0510 0005 5084 0e10 2005 0x0030: 0a80 0284 5d7d 0588 8000 0002 4377 0024 0x0040: fe2a f44a a621 7612 cb02 dfb0 764c 7c4b 16:06:54.543948 IP 93.125.5.135 > 224.0.0.5: OSPFv2, LS-Update, length: 64 0x: 45c0 0064 f0b2 0159 84c5 5d7d 0587 0x0010: e000 0005 0204 0040 d5b8 e114 0002 0x0020: 0002 0510 4bac fa4a 0001 0x0030: 0e10 2005 0a80 013b 5d7d 0588 8000 0002 0x0040: 2bd9 0024 00ff 0x0050: bfcf ad0e ec4a 8105 a36a c4b4 0x0060: 8e0d 1c1c 16:06:54.712154 IP 93.125.5.141 > 224.0.0.5: OSPFv2, Hello, length: 108 0x: 45c0 0090 9e27 0159 d71e 5d7d 058d 0x0010: e000 0005 0201 0048 5d7d 0507 0002 0x0020: 0002 0510 4ba3 661a ffe0 0x0030: 000a 1200 0028 5d7d 0587 0x0040: 5d7d 0506 5d7d 0586 5d7d 0588 5d7d 058a 0x0050: 5d7d 058b 5d7d 058c d5b8 e114 df1f 8fc6 0x0060: 07e8 35a1 7edb 9ec7 6346 7041 0009 0x0070: 0001 0004 0001 0002 0014 4ba3 661a 0x0080: 2514 486c c8c7 7831 b6db bfa6 5196 833a Mar 19 16:06:51 vulture2 bird: MyOSPF: Running ospf_age cleanup Mar 19 16:06:51 vulture2 bird: MyOSPF: OSPF_auth: size mismatch (88 vs 124) Mar 19 16:06:51 vulture2 bird: Bad OSPF packet from 93.125.5.138 - authentification failed Mar 19 16:06:53 vulture2 bird: MyOSPF: OSPF_auth: size mismatch (88 vs 124) Mar 19 16:06:53 vulture2 bird: Bad OSPF packet from 93.125.5.133 - authentification failed Mar 19 16:06:53 vulture2 bird: MyOSPF: OSPF_auth: size mismatch (88 vs 124) Mar 19 16:06:53 vulture2 bird: Bad OSPF packet from 93.125.5.139 - authentification failed Mar 19 16:06:54 vulture2 bird: MyOSPF: LSUPD packet received from 93.125.5.135 via vlan200 Mar 19 16:06:54 vulture2 bird: MyOSPF: length 64 Mar 19 16:06:54 vulture2 bird: MyOSPF: router 213.184.225.20 Mar 19 16:06:54 vulture2 bird: MyOSPF: LSA Type: 0005, Id: 10.128.2
Re: Touble ospf md5 authentication
On Fri, Mar 19, 2010 at 01:57:36PM +0200, Vitaliy Kolodinsky wrote: > Dear, bird-us...@atrey.karlin.mff.cuni.cz. > > Who has a working BIRD 1.2.1 ospf md5 authentication and Cisco? > > > ---Log File-- > Mar 16 17:34:52 vulture2 bird: MyOSPF: OSPF_auth: size mismatch (88 vs 124) > Mar 16 17:34:52 vulture2 bird: Bad OSPF packet from 93.125.5.141 - > authentification failed That is strange, could you send me an output of tcpdump on that packets? (tcpdump -s 0 -x) -- 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: minor bird crash
On Fri, Mar 19, 2010 at 01:57:25PM +0100, Arnold Nipper wrote: > > and if you do are you clearing the bgp sessions (in bird-speak > > reloading the protocols)? > > > > good question :-) My impression was that "configure soft" should do the > trick, but I'm not sure whether this really is true. Reloading the pipes > for instance generates a mssive route update afais. That's definitely > not what we want. I have even added "prefer older on;" to the bgp > protocol section to make prefixes more stable across the IXP. Essentially, you have three options what to do after a change in filters: 1) restart a protocol All routes from the protocol are withdrawn from the connected table and will appear later (after restart) If these routes are primary routes in that table, other protocols connected to that table receive two notifications (first about route disappear and later about route appear). 2) reload a protocol All routes are repropagated through the protocol If these repropagations does not change primary route in the connected tables, the event wouldn't be propagated tho other connected protocols. I will write more about it later. 3) do nothing (and have an inconsistent state of propagated routes) If you use 'configure soft' command, BIRD ignore changes in filters and in that case it does nothing. But it is expected that operator restarts or reloads affected protocols. The main reason for 'configure soft' is that BIRD can't decide whether the change in filters is important enough. For example if you found that you have a bug in common 'martians' filter function and you found that one BGP neighour sent you a martian route, then you update the common filter function but you know that you have to restart/reload just that one BGP neighbour. But if you use 'configure', BIRD decides to restart/reload all protocols that use the common filter function. For older (before 1.2.1) versions, 'configure' does not use protocol reload (just a restart [*]), so there was another reason for 'configure soft' (to choose reload instead of restart). [*] or reconfigure, which is used for OSPF and RIP and is unrelated to BGP or pipe. > Documentation says: Changes in filters usually lead to restart of > affected protocols. If soft option is used, changes in filters does not > cause BIRD to restart affected protocols, therefore already accepted > routes (according to old filters) would be still propagated, but new > routes would be processed according to the new filters. > > However with _our_ current model, we only filter between customer table > and master table, accepting everything from customer side. From what > I've seen (more precise: meant to have seen) applying new filters does > not trigger importing routes to the master table. > > Another question: what exactly is reloading a table doing. There is no such thing like reloading a table - we speak about reloading a protocol. As i wrote eariler, it is essencially repropagating routes through a protocol. There are two subcases - reload-in (used when import filter changes) and reload-out (used when export filter changes): reload-in for BGP protocol - BGP protocol sends route-refresh request and then the other side sends updates for all prefixes. reload-out for BGP protocol - BGP protocol sends updates for all prefixes in connected table (and accepted by export filter). reload-in/out for pipe protocol - all routes from one table are repropagated to the other table. This should not have direct impact on external behavior of route server (just causes some CPU load). In all cases that change a state of some routing table (reload-in for BGP and reload-in/out for a pipe), the repropagation of route might change primary route in that routing table and in that case the change is propagated to other protocols (and might cause sending updates for BGP protocols). > Reloading the pipes > for instance generates a mssive route update afais. That is strange, just reloading a pipe (if there is no real change in export/import) may cause some CPU load, but the primary routes should not change and therefore connected BGP protocols should not send any updates. -- 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: minor bird crash
On 19.03.2010 09:03 Wolfgang Hennerbichler wrote > On Mar 19, 2010, at 08:47 , Arnold Nipper wrote: > > what I meant by checking the as-path was if the peer-as was in the > as-path: > > if ! (bgp_path ~ [= 1120 * =]) then reject; > ic ... >> where pref_AS() simply matches against all prefixes found in >> RADB for AS y. > > our members decided to not filter on RADB but RIPE and rather use the > solution above instead of dropping prefixes. > afaik RIPE is a subset of what you get from RADB. I like RADB because of its features like being able to do whois -h whois.radb.net \!ias-telia,1 or whois -h whois.radb.net \!gas1299 for example. Piping to some sed and tr and you are done ;-) > Out of curiosity: How often do you rebuild your filters, We did it only once the day, but current plans are to do it more often. Perhaps every 2h or so. Sebastian did not only work on Hoofprints but also spent some time on re-writing the filter generation software (incl. an aggregate6). Rebuilding the filters for ~370 AS-SETs now takes a little more than five minutes. > and if you do are you clearing the bgp sessions (in bird-speak > reloading the protocols)? > good question :-) My impression was that "configure soft" should do the trick, but I'm not sure whether this really is true. Reloading the pipes for instance generates a mssive route update afais. That's definitely not what we want. I have even added "prefer older on;" to the bgp protocol section to make prefixes more stable across the IXP. Documentation says: Changes in filters usually lead to restart of affected protocols. If soft option is used, changes in filters does not cause BIRD to restart affected protocols, therefore already accepted routes (according to old filters) would be still propagated, but new routes would be processed according to the new filters. However with _our_ current model, we only filter between customer table and master table, accepting everything from customer side. From what I've seen (more precise: meant to have seen) applying new filters does not trigger importing routes to the master table. Another question: what exactly is reloading a table doing. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 signature.asc Description: OpenPGP digital signature
Touble ospf md5 authentication
Dear, bird-us...@atrey.karlin.mff.cuni.cz.
Who has a working BIRD 1.2.1 ospf md5 authentication and Cisco?
---Log File--
Mar 16 17:34:52 vulture2 bird: MyOSPF: OSPF_auth: size mismatch (88 vs 124)
Mar 16 17:34:52 vulture2 bird: Bad OSPF packet from 93.125.5.141 -
authentification failed
-
--Configuration---
protocol ospf MyOSPF {
import all;
# export all;
area 2 {
stub no;
networks {
93.125.5.128/27;
};
interface "vlan200" {
priority 0;
password "xx" {
id 5;
};
authentication cryptographic;
};
};
}
-
--
Best regards,
Vitaliy
Kolodinsky
ospf md5 authentication
Spam detection software, running on the system "trubka.network.cz", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Dear, bird-users. Who has a working BIRD 1.2.1 ospf md5
authentication
and Cisco? ---Log File-- Mar 16 17:34:52 vulture2 bird: MyOSPF:
OSPF_auth:
size mismatch (88 vs 124) Mar 16 17:34:52 vulture2 bird: Bad OSPF packet
from 93.125.5.141 - authentification failed [...]
Content analysis details: (5.7 points, 5.0 required)
pts rule name description
-- --
3.2 FH_DATE_PAST_20XX The date is grossly in the future.
1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in bl.open-whois.org.
1.4 AWLAWL: From: address is in the auto white-list
--- Begin Message ---
Dear, bird-users.
Who has a working BIRD 1.2.1 ospf md5 authentication and Cisco?
---Log File--
Mar 16 17:34:52 vulture2 bird: MyOSPF: OSPF_auth: size mismatch (88 vs 124)
Mar 16 17:34:52 vulture2 bird: Bad OSPF packet from 93.125.5.141 -
authentification failed
-
--Configuration---
protocol ospf MyOSPF {
import all;
# export all;
area 2 {
stub no;
networks {
93.125.5.128/27;
};
interface "vlan200" {
priority 0;
password "xx" {
id 5;
};
authentication cryptographic;
};
};
}
-
--
Best regards,
Vitaliy
Kolodinsky
--- End Message ---
Re: minor bird crash
On Mar 19, 2010, at 08:47 , Arnold Nipper wrote:
> On 19.03.2010 08:10 Wolfgang Hennerbichler wrote
>
>> ... checks if the as-path is valid ...
>
> you really do that? We only do something like
>
> case bgp_path.last {
> 13238: if pref_AS13238() then accept;
> 43247: if pref_AS43247() then accept;
> }
we filter on prefixes, but we only mark them good or "not in RIPE". A customer
can select in the webinterface if he would like to receive only good routes,
all routes or he can do a per-peer selection.
what I meant by checking the as-path was if the peer-as was in the as-path:
if ! (bgp_path ~ [= 1120 * =]) then reject;
> where pref_AS() simply matches against all prefixes found in RADB
> for AS y.
our members decided to not filter on RADB but RIPE and rather use the solution
above instead of dropping prefixes.
Out of curiosity: How often do you rebuild your filters, and if you do are you
clearing the bgp sessions (in bird-speak reloading the protocols)?
> Best regards,
> Arnold
cu soon,
Wolfgang
> --
> Arnold Nipper / nIPper consulting, Sandhausen, Germany
> email: arn...@nipper.de phone: +49 6224 9259 299
> mobile: +49 172 2650958 fax: +49 6224 9259 333
>
--
www.vix.at | www.aco.net
w...@univie.ac.at | WH844-RIPE
Vienna University Computer Center
Tel: +43 1 4277-14031 | Fax: -9140
Re: minor bird crash
On 19.03.2010 08:10 Wolfgang Hennerbichler wrote
> ... checks if the as-path is valid ...
you really do that? We only do something like
case bgp_path.last {
13238: if pref_AS13238() then accept;
43247: if pref_AS43247() then accept;
}
where pref_AS() simply matches against all prefixes found in RADB
for AS y.
Best regards,
Arnold
--
Arnold Nipper / nIPper consulting, Sandhausen, Germany
email: arn...@nipper.de phone: +49 6224 9259 299
mobile: +49 172 2650958 fax: +49 6224 9259 333
signature.asc
Description: OpenPGP digital signature
Re: minor bird crash
On Mar 18, 2010, at 21:03 , Arnold Nipper wrote: > On 18.03.2010 15:25 Wolfgang Hennerbichler wrote > >> I'm having my bird6 nearly up and running, and just stumbled across >> the following minor crash. > > just curious ... what is a _minor_ crash? Sounds like a little bit > pregnant ;-) heh :) a minor crash in my little world is a crash that is caused by a stupid user, not a gifted software developer. > > SCNR, Arnold > btw: why don't you make your filter a function? You only would have to > define it once and use it several times? But perhaps I'm not getting the > whole picture ... yeah, there's more to that than just the part you've seen. it also contains a set of ip adresses generated from the ripedb to mark them as 'good' routes, checks if the as-path is valid and so on... > -- > Arnold Nipper / nIPper consulting, Sandhausen, Germany > email: arn...@nipper.de phone: +49 6224 9259 299 > mobile: +49 172 2650958 fax: +49 6224 9259 333 > -- www.vix.at | www.aco.net w...@univie.ac.at | WH844-RIPE Vienna University Computer Center Tel: +43 1 4277-14031 | Fax: -9140
Re: IPv6 Template
On Mar 18, 2010, at 22:36 , Ondrej Filip wrote:
> On 17.3.2010 16:34, Wolfgang Hennerbichler wrote:
>> Hi Ondrejs & Fellow BIRD users,
>>
>> I'm currently building the IPv6 Part of our BIRD Configuration Template. I'm
>> trying to build it in the same way as our IPv4 stuff, which is trivial,
>> because I've prepared all the code for a "dual stack" implementation. My
>> question is, what your current best practice is for avoiding martians or
>> unnecessary ipv6 routes (Like the Link Local Range, but I guess there are
>> much more which I currently am not thinking about).
>>
>> Like in IPv4 I have this:
>> prefix set martians;
>> {
>> martians = [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+,
>> 224.0.0.0/4+, 240.0.0.0/4+ ];
>> if net.ip = 0.0.0.0 then return false;
>> # Avoid too short and too long prefixes
>> if (net.len < 8) || (net.len > 30) then return false;
>> if net ~ martians then return false;
>> return true;
>> }
>>
>> What is your recommendation for that?
>
> As Ondrej has mentioned, this is a little bit better/faster approach:
>
> --
> function avoid_martians()
> prefix set martians;
> {
> martians = [ 169.254.0.0/16+, 172.16.0.0/12+,
> 192.168.0.0/16+, 10.0.0.0/8+,
> 224.0.0.0/4+, 240.0.0.0/4+,
> 0.0.0.0/32-, 0.0.0.0/0{31,32}, 0.0.0.0/0{0,7} ];
>
> # Avoid RFC1918 networks
> if net ~ martians then return false;
>
> return true;
> }
> --
>
> But I personally prefer: 0.0.0.0/0{25,32}
> :-)
Yeah, we really should not accept bigger networks than /24, that's true.
>
> I use this IPv6 filter:
> --
> # This function excludes weird networks
> function avoid_martians()
> prefix set martians;
> {
> martians = [ fc00::/7+, fec0::/10+,
> ::/128-, ::/0{0,15}, ::/0{49,128} ];
>
> if net ~ martians then return false;
>
> return true;
> }
> --
Allright, I came up with this now (Thanks to Arnold's Hint and yours above):
# this function avoids illegal ipv6 networks.
function avoid_martians()
prefix set ipv6_no_gos;
{
ipv6_no_gos = [ 3ffe::/16+, 2001:db8::/32+, fe00::/9+, ff00::/8+, ::/128-,
::/0{0,15}, ::/0{49,128} ];
if net ~ ipv6_no_gos then return false;
return true;
}
Thanks for your hints;
Wolfgang
--
www.vix.at | www.aco.net
w...@univie.ac.at | WH844-RIPE
Vienna University Computer Center
Tel: +43 1 4277-14031 | Fax: -9140
