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

2007-03-22 Diskussionsfäden Christian.Kuster
I miss the vrf receive command
Cheers
chris 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Glogger Steven,
FX-IT-SME-SNE
Sent: Wednesday, March 21, 2007 11:12 PM
To: swinog@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@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


RE: [swinog] QoS Monitoring

2007-03-09 Diskussionsfäden Christian.Kuster
Hmm, that's only about the Class based stuff (MQC), lot's of cisco boxes
(Multilayer switches) use MLS QoS, what about that?

Cheers
Christian

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stanislav Sinyagin
Sent: Friday, March 09, 2007 1:00 PM
To: swinog@swinog.ch
Subject: Re: [swinog] QoS Monitoring

http://torrus.org/plugins/tp-cisco-cbqos.pod.html

you've got here everything that is available from Cisco IOS via SNMP.


--- [EMAIL PROTECTED] wrote:

 I'm looking for a QoS Monitoring Software for an enterprise customer.
 
 The customer is operating a Cisco network with ~30'000 endsystems, the

 backbone is based on 10GE technology.
 
 We like to monitor general QoS contracts on all interfaces and 
 microflows on the edge. QoS events should trigger alerts in HP-OV. 
 Statistics are welcome.
 
 Anyone with experiences?
 
 
 Marco
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
 

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


RE: [swinog] de-peering

2006-12-15 Diskussionsfäden Christian.Kuster
Na dann Prost !
 
Cheers
Christian



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andre Chapuis
Sent: Friday, December 15, 2006 12:21 PM
To: swinog@swinog.ch
Subject: [swinog] de-peering



www.cablecom.ch http://www.xcn.de/  

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


RE: [swinog] SwiNOG#13 Registration

2006-10-27 Diskussionsfäden Christian.Kuster
On Fri, 2006-10-27 at 14:57 +0200, Jérôme Tissières wrote:
 Maybe we can try the FIFO queue at the door of the meeting room ? :)


And use Random early discard ;-)
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


RE: [swinog] Reset DSCP/IP-PREC field

2006-06-20 Diskussionsfäden Christian.Kuster
Strongly recommended, unless the Provider's Backbone is DSCP
transparent...

Cheers
Christian 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marcel Leuenberger
Sent: Tuesday, June 20, 2006 1:59 PM
To: swinog@lists.swinog.ch
Subject: [swinog] Reset DSCP/IP-PREC field

HiYa!

Just want to ask you if it is allowed to reset the
IP-PRECEDENCE/DSCP-Field to Zero (or any other value) at the border of
an ISP network? 

Means there is no problem if an IP-Transit provider reset the customers
IP-PREC/DSCP field because INTERNET is best effort and therefore each
ISP can do with the IP-PREC/DSCP whatever he want's because each ISP has
it's own QoS-Domain and rules?

For me resetting the IP-PREC/DSCP is a must concerning security and to
declare Internet-Traffic as BE in internal networks.

Or I am wrong and are there any existing rules in the ISP community
relating modifying IP-PREC/DSCP?

Are you resetting the IP-PREC/DSCP as well?

Thanks and greetings,
- Marcel

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


RE: AW: [swinog] couple of sunrise dsl outages

2005-12-06 Diskussionsfäden Christian.Kuster
No comment... 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Viktor Steinmann
 Sent: Tuesday, December 06, 2005 3:50 PM
 To: swinog@swinog.ch
 Subject: Re: AW: [swinog] couple of sunrise dsl outages
 
 Well - don't know, how many of your read the jobs.ch jobmail, 
 but if you do, you have probably noticed, that sunrise is 
 looking for experienced network engineers for a long time 
 now...  I guess, they don't have a technical, but a HR problem  ;-)
 
 Too bad, their offices are in the totally wrong place (from 
 my point of view (which is of course the middle of nowhere 
 (Säuliamt)))
 
 Cheers,
 Viktor
 
 Zitat von Xaver Aerni [EMAIL PROTECTED]:
 
  Sunrise has sayed, one of the two Routers are completly down... I'm 
  wondering that sunrise only has two routers in Switzerland. 
 One in Zürich...
  it was today down... and one in Lausanne...
  I think Sunrise has a big problem with the rednunance of 
 their system
  Only two  Possiblety and if one is down, they couldent 
 route all the 
  traffic to the other router...
 
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
 
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


RE: AW: [swinog] couple of sunrise dsl outages

2005-12-06 Diskussionsfäden Christian.Kuster
 Oh well, Rümlang isn't any better in terms of being in the pampas.
 
 CU, Venty
 (who is happy living and working both in Schlieren)

No no, Rümlang is shut down. Everything in the sunrise towers...
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog