swinog March 2007

swinog@lists.swinog.ch

33 participants
27 discussions

RE: [swinog] MPLS VRF source routing (inter-vrf routing)

by Varaillon Jean Christophe

Could NAT be an option? Jean-Christophe Varaillon ------------ ALTEC Telecoms - NOC 14, Patmou, 151 23 Maroussi, Greece Tel: +30 210 6872932 Fax: +30 210 6872904 E-mail: vajc(a)altectelecoms.gr ICQ: 264-755-242 -----Original Message----- From: swinog-bounces(a)lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Steven.Glogger(a)swisscom.com Sent: Thursday, March 22, 2007 12:12 AM To: swinog(a)swinog.ch Subject: [swinog] MPLS VRF source routing (inter-vrf routing) hi all i've got some nice cisco bugs / features / whatever. some prerequisites: - 2 VRFs: vrf blue and vrf red - both vrfs have a different default route. - a PPP session / user terminating in vrf blue a specific route (10.0.1.0/29) is routed over static route (e.g. radius avpair) over the ppp session (vrf blue). this route is imported to vrf red by importing rd values and route-map filtering. so the connectivity from the red vrf to the vrf blue is working (one way). so, the goal (and this is the problem) is traffic souring that specific route should go back to vrf red. how i thought would be the simplest way to do it: policy routing. interface virtual-access123 ip policy route-map set-vrf-red ... ! access-list 110 permit 10.0.1.0 0.0.0.7 any route-map set-vrf-red permit 10 match ip address 110 set vrf red ! would be the nicest way of doing this. now the but: if you put the policy on the virtual-template / radius profile the session starts flapping (connect/disconnect/connect/disconnect....). so: not usable. my other approach was: interconnect vrf blue with vrf red by a vlan / interface. assume on vrf blue: fastethernet0/0 with 11.0.0.1/30 connnected to vrf red with fastethernet0/1 with 11.0.0.2/30. modifying the route map to: route-map set-vrf-red permit 10 match ip address 110 set interface fastethernet0/0 set ip next-hop 11.0.0.2 ! this will stop the flapping (disconnect/connect/disconnect...) of the ppp session and the whole routing works as expected.... BUT: somewhen it stops working because of one thousand possible CEF bugs ;-( i have to put "no ip route-cache cef" on the interconnection interface, then it works. some hours later (as already said) it stops working. when i do again "no ip route-cache cef" on the interface it works some other hours. i've tried several IOS for the C7200series and the only half-way working version is the 12.4T (or even 12.3T). so, now the big question to the community: 1) do you see any other working way doing source-routing from one vrf to another vrf? (there's a vrf source routing command, but i think this will really not scale) 2) do you have encountered the same CEF bugs? (i have seen them on 7206, 1841 and 2851 series routers) how cisco tells me to do it: http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080296409.html i would be glad to get some input from you guys. greetings -steven _______________________________________________ swinog mailing list swinog(a)lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

15 years, 5 months

dnswl.org ?

by Per Jessen

Matthias Leisi wrote: > 194.67.23.0/24 does not equal the full set of *.mail.ru hostnames. > > Similarly, dnswl.org contains three /24s for uol.com.br (see > http://www.dnswl.org/search.pl?s=3633). Now this is not a statement > that uol.com.br is all nice and cosy, but it's a statement of the fact > that the postmaster for uol.com.br told us that these are the ranges > for the mailservers (and we verified that using eg senderbase.org). > > Since such ranges are usually not as trustworthy as /32s of > well-respected mailserver operators, dnswl.org lists such ranges with > a score of "none"; for all practical reasons, this should translate > into "do not greylist, since there is most likely a legitimate > mailserver at the other end who will retry anyway". This sounds like a pretty good idea, but judging by the size of the rbldnsd file, it's not very popular? Only 4317 entries. /Per Jessen, Zürich

15 years, 11 months

Whitelist website

by Radek Mrskos

What about a "whitelist" website, every ISP could enter the IPs of his MTA's and everybody could use for his whitelisting? Radek Mrskos Email mrskos(a)volume.ch volume.ch Tel: +41 43 534 40 24 Baechlerstr. 12 Mob: +41 79 219 68 66 CH-8802 Kilchberg Fax: +41 86079 2196 866 PGP:0x8CB69F6D URL: http://volume.ch

15 years, 11 months

Huge retry delays in mail from Sunrise

by Stanislav Sinyagin

hi, We use the email greylisting policy for incoming email for us and our customers, and it appears that often the email from Sunrise network comes with huge delays, from several hours to several days. Did anyone else see such problems? Guys from Sunrise, plase contact me directly for more details and troubleshooting. Such delays seen in email coming from smtp-auth-be-01.sunrise.ch (mail-proxy-be-01.sunrise.ch [194.158.229.48]) smtp-auth-be-06.sunrise.ch (mx-auth.sunrise.ch [194.158.229.90]) cheers, stan 044 732 9953 079 407 0224

15 years, 11 months

RE: [swinog] Huge retry delays in mail from Sunrise

by Stanislav Sinyagin

--- "Kurt A. Schumacher" <Kurt.Schumacher(a)schumi.ch> wrote: > Just a guess: > The more retries to a certain SMTP destination, the longer the retry > interval...leads to exponential delivery times. no, it's quite sporadic: some emails are retried wihtin 10 minutes, and some were delaying for hours. > Pure greylisting is - just like blacklistsing - is useless or leads to > unexpected behavior without a well-maintained and monitored whitelist for a > corporate or ISP e-mail system. it is actually a well-maintained whitelist, but of course sometimes exceptions happen...

15 years, 11 months

Init7 is hiring

by Fredy Kuenzler

Init7 is hiring a a Junior Linux SystemadministratorIn: http://www.init7.net/jobs.php F.

15 years, 12 months

Lawyer recommendation

by ralf.zenklusen＠barinformatik.ch

A customer is looking for a good (with experience and knowledge) lawyer in CH concerning a .com domain dispute. Any recommendations? Thank you Ralf Zenklusen

15 years, 12 months

AW: [swinog] Lawyer recommendation

by ralf.zenklusen＠barinformatik.ch

Thank you for the different suggestions I've received. I'll pass them on... Ralf Zenklusen -----Ursprüngliche Nachricht----- Von: Nik Hug [mailto:lists.nik@nts.ch] Gesendet: Freitag, 23. März 2007 10:50 An: Ralf Zenklusen Betreff: Re: [swinog] Lawyer recommendation ralf.zenklusen(a)barinformatik.ch schrieb: > A customer is looking for a good (with experience and knowledge) lawyer > in CH concerning a .com domain dispute. > > Any recommendations? ev. Dr. Ursula Widmer ... from widmerpartners-lawyers.ch habe mal bei ihr studiert - nach mir war Sie auch zeitweise Antwalt von Switch und hat nach mir verschiedene WIPO-Verfahren begleitet. Gruss Nik > > Thank you > Ralf Zenklusen > > > > _______________________________________________ > swinog mailing list > swinog(a)lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

15 years, 12 months

MPLS VRF source routing (inter-vrf routing)

by Steven.Glogger＠swisscom.com

hi all i've got some nice cisco bugs / features / whatever. some prerequisites: - 2 VRFs: vrf blue and vrf red - both vrfs have a different default route. - a PPP session / user terminating in vrf blue a specific route (10.0.1.0/29) is routed over static route (e.g. radius avpair) over the ppp session (vrf blue). this route is imported to vrf red by importing rd values and route-map filtering. so the connectivity from the red vrf to the vrf blue is working (one way). so, the goal (and this is the problem) is traffic souring that specific route should go back to vrf red. how i thought would be the simplest way to do it: policy routing. interface virtual-access123 ip policy route-map set-vrf-red ... ! access-list 110 permit 10.0.1.0 0.0.0.7 any route-map set-vrf-red permit 10 match ip address 110 set vrf red ! would be the nicest way of doing this. now the but: if you put the policy on the virtual-template / radius profile the session starts flapping (connect/disconnect/connect/disconnect....). so: not usable. my other approach was: interconnect vrf blue with vrf red by a vlan / interface. assume on vrf blue: fastethernet0/0 with 11.0.0.1/30 connnected to vrf red with fastethernet0/1 with 11.0.0.2/30. modifying the route map to: route-map set-vrf-red permit 10 match ip address 110 set interface fastethernet0/0 set ip next-hop 11.0.0.2 ! this will stop the flapping (disconnect/connect/disconnect...) of the ppp session and the whole routing works as expected.... BUT: somewhen it stops working because of one thousand possible CEF bugs ;-( i have to put "no ip route-cache cef" on the interconnection interface, then it works. some hours later (as already said) it stops working. when i do again "no ip route-cache cef" on the interface it works some other hours. i've tried several IOS for the C7200series and the only half-way working version is the 12.4T (or even 12.3T). so, now the big question to the community: 1) do you see any other working way doing source-routing from one vrf to another vrf? (there's a vrf source routing command, but i think this will really not scale) 2) do you have encountered the same CEF bugs? (i have seen them on 7206, 1841 and 2851 series routers) how cisco tells me to do it: http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080296409.html i would be glad to get some input from you guys. greetings -steven

15 years, 12 months

Swisscom wants CHF 31/Month per regulated copper line

by Andre Oppermann

The price seems to be a bit far out when considering that a normal phone line (which includes the telephony infrastructure as well) costs only CHF 25.25/Month. Reading the financial reports of Swisscom from the last few years it doesn't seem Swisscom was losing any money on the phone lines even when excluding any traffic minute charges. http://www.swisscom.com/GHQ/content/Media/Medienmitteilungen/2007/20070320_… Yet more work for BAKOM, Comcom and the Bundesgericht in the next years. -- Andre

16 years

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog March 2007