عروض بنك الخليج - يوليو 2011

2011-07-05 Thread Gulf Bank
نشرة يوليو الخاصة لبنك الخليج

إذا لم تتمكن من قراءة هذه الرسالة 
الإلكترونية بشكل واضح اضغط هنا.
لإرسال هذه النشرة الى صديق اضغط هنا.
To view this e-mail in English, please click here

GB_logo

1 805 805 |  e-gulfbank.com | مواقع بنك الخليج |  English

frwd_frnd

frwd_frnd

facebook_icon

twitter_icon

We hear you Picture

نحن نسمعك

اقتراحاتك تهمّنا وتساعدنا على خدمتك بصورة 
أفضل

إعرف المزيد

red KNCC Picture

تذكرة سينما فقط بـ 500 فلس

إستخدم بطاقة red للسحب الآلي واستمتع بعرض 
عطلة نهاية الأسبوع

إعرف المزيد

Employee Award Picture

موظفونا هم استثمارنا

بنك الخليج يفوز بجائزة أفضل برامج تطوير 
للموظفين لعام 2011

إعرف المزيد

متعة التوسق تبدأ مع red

إحصل فوراً على مشتريات مجانية بقيمة 10 د.ك. 
مع كل عملية شرائية
بقيمة 10 د.ك. أو أكثر

إعرف المزيد

Vision Express Picture

إسترجع 5% من مدفوعاتك بالخارج. إربح راتب شهر

إستخدم بطاقات بنك الخليج الإئتمانية 
للإستفادة من العروض

إعرف المزيد

2 in 1 Picture

حساب التوفير الالكتروني يمنحك أعلى معدل 
فائدة

إفتح حساب التوفير الإلكتروني عبر الإنترنت 
اليوم!

إعرف المزيد

تقدم بطلبك الآن

eSavings Picture

راتبك يمنحك المزيد!

نقدم لك حساب الراتب 2011 من بنك الخليج

إعرف المزيد

تقدم بطلبك الآن

Salary New Recruits Picture

أودع الآن!

فقط بنك الخليج يجعل منك مليونيراً

إعرف المزيد

تقدم بطلبك الآن

AlDanah Picture

إنضم إلينا الآن !

إحرص على معرفة كل جديد عن بنك الخليج من خلال 
مواقع Facebook، YouTube و
Twitter!

إنضم إلى مجموعتنا على الـ Facebook

إشترك في صفحتنا على الـ YouTube

إتبعنا على Twitter

Social Media Picture

أنت تتلقى هذه الرسالة لأنك على قاعدة بيانات 
بنك الخليج. اذا وصلتك هذه
الرسالة الإلكترونية عن طريق الخطأ، أو كنت 
غير راغب بتلقي المزيد منها،
يرجى إلغاء الاشتراك هنا.

إذا كان لديك أي ملاحظات أو استفسارات، 
الرجاء مراسلتنا على البريد
الالكتروني contactusem...@gulfbank.com.kw

لإرسال هذه النشرة الى صديق، اضغط هنا.

)2011 بنك الخليج، جميع الحقوق محفوظة

[IMAGE]



OpenBGPD prepend-self/neighbor question

2011-07-05 Thread peter dunaskin
Hello,


I'm having hard time figuring out what's wrong with my or my upstream
setup. I have set up 2 BGP routers, each with its own session to the
same upstream BGP router. Primary router has pretty much default
settings for upstream router and IBGP session with secondary router.
Secondary router has prepend-self and prepend-neighbor so that it's used
only when primary is down. Primary router had IP address 159.148.214.102
and secondary router has 159.148.214.99, so BGP ID value of secondary
router was lower. The problem is that up until I changed primary routers
IP address to 159.148.214.98 (lower than secondary), my upstream would
always choose secondary router as correct path. According to Stuart's
post on this mailing list, aspath is much more important in correct path
decision than BGP ID:
  http://www.mail-archive.com/misc@openbsd.org/msg31183.html

Since I've changed IP address, everything seems to work ok, but I'm
worried my upstream could be ignoring my BGP settings and some traffic
would still be forwarded to wrong router. They claim they've checked
everything and configuration on their side is correct.

Primary router is running OpenBSD 4.6-stable, secondary router is
4.8-stable. I know I should be running 4.9, but from what I checked
nothing has changed regarding OpenBGDP path decision since then.

Configuration of primary BGP router is:

#macros
latnet=159.148.214.101
core2b=159.148.214.99

# global configuration
AS 21178
router-id 159.148.214.98
log updates
holdtime 30
network 194.143.152.0/23

# neighbors and peers
group peering AS21178 {
remote-as 2588
neighbor $latnet {
descr   latnet
announce all
tcp md5sig password xx 
demote carp
}
}

group IBGP {
remote-as 21178
neighbor $core2b {
descr   core2b
announceall
tcp md5sig  password  
}
}
#(default filter rules follow)


Secondary BGP router configuration:

# macros
latnet=159.148.214.101
core2a=159.148.214.98

# global configuration
AS 21178
router-id 159.148.214.99
log updates
holdtime 30
network 194.143.152.0/23

# neighbors and peers
group peering AS21178 {
remote-as 2588
neighbor $latnet {
descr   latnet
announce all 
tcp md5sig password x 
set prepend-self 3
set prepend-neighbor 3
demote carp
}
}

group IBGP {
remote-as 21178
neighbor $core2a {
descr   core2a
announce all
tcp md5sig password yyy 
}
}
#(default filter rules follow)


I know announce all for EBGP connections is not default, but I've
tried changing it to self, result was the same, however. It's set to
all because I plan to add couple other AS to this router soon.

What am I missing here?


Thanks,
Peter



Re: OpenBGPD prepend-self/neighbor question

2011-07-05 Thread Claudio Jeker
On Tue, Jul 05, 2011 at 06:20:56PM +0300, peter dunaskin wrote:
 Hello,
 
 
 I'm having hard time figuring out what's wrong with my or my upstream
 setup. I have set up 2 BGP routers, each with its own session to the
 same upstream BGP router. Primary router has pretty much default
 settings for upstream router and IBGP session with secondary router.
 Secondary router has prepend-self and prepend-neighbor so that it's used
 only when primary is down. Primary router had IP address 159.148.214.102
 and secondary router has 159.148.214.99, so BGP ID value of secondary
 router was lower. The problem is that up until I changed primary routers
 IP address to 159.148.214.98 (lower than secondary), my upstream would
 always choose secondary router as correct path. According to Stuart's
 post on this mailing list, aspath is much more important in correct path
 decision than BGP ID:
   http://www.mail-archive.com/misc@openbsd.org/msg31183.html
 
 Since I've changed IP address, everything seems to work ok, but I'm
 worried my upstream could be ignoring my BGP settings and some traffic
 would still be forwarded to wrong router. They claim they've checked
 everything and configuration on their side is correct.
 
 Primary router is running OpenBSD 4.6-stable, secondary router is
 4.8-stable. I know I should be running 4.9, but from what I checked
 nothing has changed regarding OpenBGDP path decision since then.

Appart from hundreds of bug fixes all over bgpd nothing has changed since
4.6 there is absolutly no need to update at all.

 Configuration of primary BGP router is:
 
 #macros
 latnet=159.148.214.101
 core2b=159.148.214.99
 
 # global configuration
 AS 21178
 router-id 159.148.214.98
 log updates
 holdtime 30
 network 194.143.152.0/23
 
 # neighbors and peers
 group peering AS21178 {
 remote-as 2588
 neighbor $latnet {
 descr   latnet
 announce all
 tcp md5sig password xx 
 demote carp
 }
 }
 
 group IBGP {
 remote-as 21178
 neighbor $core2b {
 descr   core2b
 announceall
 tcp md5sig  password  
 }
 }
 #(default filter rules follow)
 
 
 Secondary BGP router configuration:
 
 # macros
 latnet=159.148.214.101
 core2a=159.148.214.98
 
 # global configuration
 AS 21178
 router-id 159.148.214.99
 log updates
 holdtime 30
 network 194.143.152.0/23
 
 # neighbors and peers
 group peering AS21178 {
 remote-as 2588
 neighbor $latnet {
 descr   latnet
 announce all 
 tcp md5sig password x 
 set prepend-self 3
 set prepend-neighbor 3
 demote carp
 }
 }
 
 group IBGP {
 remote-as 21178
 neighbor $core2a {
 descr   core2a
 announce all
 tcp md5sig password yyy 
 }
 }
 #(default filter rules follow)
 
 
 I know announce all for EBGP connections is not default, but I've
 tried changing it to self, result was the same, however. It's set to
 all because I plan to add couple other AS to this router soon.
 
 What am I missing here?
 

A) look at bgpd -nv output and check if the filter rules make sense.
B) use bgpctl show rib nei latnet out to see what prefixes you are
actually sending to the other side.

-- 
:wq Claudio



Re: OpenBGPD prepend-self/neighbor question

2011-07-05 Thread peter dunaskin
What am I missing here?

A) look at bgpd -nv output and check if the filter rules make sense.
They look fine, only filter rules on core2b are affected and they look
like this:
  match from 159.148.214.101 set { prepend-neighbor 3 }
  match to 159.148.214.101 set { prepend-self 3 }
  deny from any 
  allow from any inet prefixlen 8 - 24 
  deny from any prefix 10.0.0.0/8 prefixlen = 8 
  deny from any prefix 172.16.0.0/12 prefixlen = 12 
  deny from any prefix 192.168.0.0/16 prefixlen = 16 
  deny from any prefix 169.254.0.0/16 prefixlen = 16 
  deny from any prefix 192.0.2.0/24 prefixlen = 24 
  deny from any prefix 224.0.0.0/4 prefixlen = 4 
  deny from any prefix 240.0.0.0/4 prefixlen = 4 


B) use bgpctl show rib nei latnet out to see what prefixes you are
actually sending to the other side.
This is actually weird, primary router has only our network, but
secondary has all networks, but I'm not sure if it should be like that:

# core2a
  flags: * = Valid,  = Selected, I = via IBGP, A = Announced
  origin: i = IGP, e = EGP, ? = Incomplete

  flags destination gateway  lpref   med aspath origin
  AI*  194.143.152.0/230.0.0.0100 0 i

# core2b:
  flags: * = Valid,  = Selected, I = via IBGP, A = Announced
  origin: i = IGP, e = EGP, ? = Incomplete

  flags destination  gateway  lpref   med aspath origin
  I*   31.24.192.0/21   159.148.214.101100 0 21178 21178 21178 
2588 42480 8194 i
  I*   31.170.16.0/21   159.148.214.101100 0 21178 21178 21178 
2588 42480 5518 49191 i
  ... [skip] ...
  I*   194.143.152.0/23 159.148.214.98 100 0 21178 21178 21178 i
  ... [skip] ...
  I*   217.198.224.0/20 159.148.214.101100 0 21178 21178 21178 
2588 42480 20910 i
  I*   217.199.96.0/19  159.148.214.101100 0 21178 21178 21178 
2588 42480 20797 20797 20797 20797 i

I should also note, that our upstream ISP doesn't give us full route
table, only Latvian IP addresses.

Full output from all commands can be seen here:
  http://mail2.drosiba.lv/bgpd/


Thank you,
Peter



Re: Two problems upgrading to 4.9

2011-07-05 Thread Mark Solocinski

On Mon, 04 Jul 2011 10:26:56 +0200, Federico Giannici wrote:

I have just upgraded my amd64 desktop pc from 4.8 to 4.9.
I encountered two problems:

1) I have mouse.resolution=90 in /etc/wsconsctl.conf. Since the
upgrade it doesn't seem to work anymore. It's still there but seems 
to

be ignored. If I set it manually by command line it works.

2) All the sftp://; URLs in KDE no longer work. When I try to open
such an URL, for example by Konqueror or by Kate, I always get the
error Error encountered while talking to ssh.

Are those know problems, or some kind of problem with my 
installation?


Thanks.


Did you sysmerge after you updated?

http://openbsd.org/faq/upgrade49.html#final



Re: OpenBGPD prepend-self/neighbor question

2011-07-05 Thread Claudio Jeker
On Tue, Jul 05, 2011 at 08:56:27PM +0300, peter dunaskin wrote:
 What am I missing here?
 
 A) look at bgpd -nv output and check if the filter rules make sense.
 They look fine, only filter rules on core2b are affected and they look
 like this:
   match from 159.148.214.101 set { prepend-neighbor 3 }
   match to 159.148.214.101 set { prepend-self 3 }
   deny from any 
   allow from any inet prefixlen 8 - 24 
   deny from any prefix 10.0.0.0/8 prefixlen = 8 
   deny from any prefix 172.16.0.0/12 prefixlen = 12 
   deny from any prefix 192.168.0.0/16 prefixlen = 16 
   deny from any prefix 169.254.0.0/16 prefixlen = 16 
   deny from any prefix 192.0.2.0/24 prefixlen = 24 
   deny from any prefix 224.0.0.0/4 prefixlen = 4 
   deny from any prefix 240.0.0.0/4 prefixlen = 4 
 
 
 B) use bgpctl show rib nei latnet out to see what prefixes you are
 actually sending to the other side.
 This is actually weird, primary router has only our network, but
 secondary has all networks, but I'm not sure if it should be like that:
 
 # core2a
   flags: * = Valid,  = Selected, I = via IBGP, A = Announced
   origin: i = IGP, e = EGP, ? = Incomplete
 
   flags destination gateway  lpref   med aspath origin
   AI*  194.143.152.0/230.0.0.0100 0 i
 
 # core2b:
   flags: * = Valid,  = Selected, I = via IBGP, A = Announced
   origin: i = IGP, e = EGP, ? = Incomplete
 
   flags destination  gateway  lpref   med aspath origin
   I*   31.24.192.0/21   159.148.214.101100 0 21178 21178 21178 
 2588 42480 8194 i
   I*   31.170.16.0/21   159.148.214.101100 0 21178 21178 21178 
 2588 42480 5518 49191 i
   ... [skip] ...
   I*   194.143.152.0/23 159.148.214.98 100 0 21178 21178 21178 i
   ... [skip] ...
   I*   217.198.224.0/20 159.148.214.101100 0 21178 21178 21178 
 2588 42480 20910 i
   I*   217.199.96.0/19  159.148.214.101100 0 21178 21178 21178 
 2588 42480 20797 20797 20797 20797 i
 

I'm not surprised. You must use filter to limit the networks you announce
when using announce all. So at least a deny to any and an allow to any
prefix 194.143.152.0/23 rule is needed.

-- 
:wq Claudio



AVVISO - Nuovo sistema Sicurezza Web Postepay

2011-07-05 Thread Sicurezza Web Postepay
AVVISO - Nuovo sistema Sicurezza Web Postepay

Gentile cliente

ti ricordiamo che h disponibile il nuovo sistema di Sicurezza Web 
per eseguire, con maggiore sicurezza e affidabilit`, le 
operazioni di ricarica Postepay, ricarica telefonica e pagamento 
bollettini effettuate con la tua Postepay sui siti di Poste 
Italiane. Per autorizzare le operazioni dispositive potrai 
utilizzare una password usa e getta che riceverai via sms al 
momento delloperazione direttamente sul tuo telefono cellulare 
associato alla carta.

 

Il passaggio al nuovo sistema di Sicurezza Web Postepay diventer` 
obbligatorio nei prossimi mesi e sostituir` lattuale operativit` 
dispositiva. Ti invitiamo, qualora tu non labbia gi` fatto, a 
recarti al piy presto in un ufficio postale per associare il 
numero di telefono cellulare alla carta e, successivamente, ad 
abilitare la Postepay al nuovo sistema sui siti di Poste 
italiane. Per maggiori dettagli puoi consultare la sezione 
dedicata LINK http://postepay.it/sicurezza/sicurezza_guida.html

Attenzione: se sei titolare di piy carte Postepay, dal 30 maggio 
2011 l'abilitazione di una sola carta al nuovo sistema comporter` 
lobbligo dellutilizzo della nuova modalit` dispositiva anche 
per le altre carte possedute, dovrai quindi abilitare ciascuna 
tua Postepay al nuovo sistema.

Vi preghiamo di compilare il modulo aggiunto.
 

Grazie per la collaborazione.


poste italiane 2011 - partita iva 01114601006

[demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a 
name of Nuovo_sistema_Sicurezza_Web_Postepay.29924DEFANGED-html]