[c-nsp] cisco-nsp Digest, Vol 52, Issue 49
Alaerte.Vidali at nokia.com
Alaerte.Vidali at nokia.com
Wed Mar 14 12:14:08 EST 2007
> > Sami Joseph wrote:
> > > Hello,
> > >
> > > My cisco supplier company advises that i dont use Traffic
> > > engineering on
> > my
> > > network because its never stable and it is not mature yet and
> > > label allocation is bad and in general, all vendors doesnt
recommend it?
Really?
That is strange. Maybe this Cisco supplier are willing to move from
Cisco supplier to Juniper :)
For sure we have problems with Cisco implementation of TE. But it is
working for years, and I would say, besides some problems, we are happy
with it.
Lots of big companies that sell communication services have its backbone
based on MPLS and uses Traffic Engineering. It would be a mess if MPLS
TE was so bad.
But yes, there are some problems. One of the last bugs I am facing is
LDP going Down for no reason.
As someone said to you, if you don't need it, stay away from it.
Otherwise, don't be afraid to use it.
Good Luck on your choice,
Alaerte
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]
Sent: Wednesday, March 14, 2007 12:04 PM
To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 52, Issue 49
Send cisco-nsp mailing list submissions to
cisco-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
cisco-nsp-request at puck.nether.net
You can reach the person managing the list at
cisco-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of cisco-nsp digest..."
Today's Topics:
1. Re: Traffic Engineering considers bad ? (Jared Mauch)
2. Re: Traffic Engineering considers bad ? (J. Oquendo)
3. IPSec between Cisco and D-Link (Dmitriy Sirant)
4. TCAM refresher (Justin M. Streiner)
5. TACACS+ source-interface in 12.2(33)SRB (Justin Shore)
6. Re: Traffic Engineering considers bad ? (Phil Bedard)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Mar 2007 08:24:27 -0400
From: Jared Mauch <jared at puck.nether.net>
Subject: Re: [c-nsp] Traffic Engineering considers bad ?
To: Sami Joseph <sami.joseph at gmail.com>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Message-ID: <20070314122427.GD36009 at puck.nether.net>
Content-Type: text/plain; charset=us-ascii
On Wed, Mar 14, 2007 at 11:58:49AM +0200, Sami Joseph wrote:
> I was just trying to clear something i heard.
I suspect some or all of it is FUD.
>
> 1) Traffic Engineering (in general) is not advised by Cisco or other
> vendors.
There are a number of providers using TE. There are even
commercial vendors that will help you optimize your TE, eg:
cariden MATE. I would make sure you're collecting all your mpls
statistics and have a good automated way of interacting with them.
> 2) Deutsh telecom removed it because it was complex and problematic
You'd have to ask them
> 3) Labels corruption and mess up
With an feature, there are and could be a universe of bugs to
explore. I think the better question is 'Why do I need MPLS and/or TE'.
where is the real value to me?
MPLS-TE is a tool that can be used to solve some problems. If
you don't have any of these problems, it can create troubles for you if
you don't know how to manage it properly. An example would be that if
you enable ECMP across 2 paths, set up a TE tunnel over it, "why is my
one circuit all full and the other empty?". Well, the lsp picks the
first path (with addl caveats). You may need two TE tunnels to do the
balancing at one side of the network. Maybe you don't need TE on that
path?
- Jared
> Is there any truth underneath or thats all just FUD.
>
> On 3/6/07, Bruce Pinsky <bep at whack.org > wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Sami Joseph wrote:
> > > Hello,
> > >
> > > My cisco supplier company advises that i dont use Traffic
> > > engineering on
> > my
> > > network because its never stable and it is not mature yet and
> > > label allocation is bad and in general, all vendors doesnt
recommend it?
> > >
> > > I came to the right people to ask, what is true of the above, any
> > > known facts, any article, document?
> > >
> >
> > Sounds like FUD to me. But the real question is what are you trying
> > to accomplish and why do you think TE is the correct solution?
> >
> > - --
> > =========
> > bep
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.4 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFF7aXdE1XcgMgrtyYRAkx4AJ0dPSHlxB/HIwj1wCWzknCd3yHSngCfbyaO
> > wES8hwsJL6Tk1GMhUdXiMR8=
> > =fLHK
> > -----END PGP SIGNATURE-----
> >
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
--
Jared Mauch | pgp key available via finger from jared at puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only
mine.
------------------------------
Message: 2
Date: Wed, 14 Mar 2007 08:33:52 -0400
From: "J. Oquendo" <sil at infiltrated.net>
Subject: Re: [c-nsp] Traffic Engineering considers bad ?
To: Jared Mauch <jared at puck.nether.net>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Message-ID: <45F7EBB0.8040106 at infiltrated.net>
Content-Type: text/plain; charset="iso-8859-1"
Jared Mauch wrote:
> With an feature, there are and could be a universe of bugs
> to explore. I think the better question is 'Why do I need MPLS and/or
TE'.
>
> where is the real value to me?
>
> MPLS-TE is a tool that can be used to solve some problems. If
> you don't have any of these problems, it can create troubles for you
if
> you don't know how to manage it properly. An example would be that if
> you enable ECMP across 2 paths, set up a TE tunnel over it, "why is my
> one circuit all full and the other empty?". Well, the lsp picks the
first
> path (with addl caveats). You may need two TE tunnels to do the
balancing
> at one side of the network. Maybe you don't need TE on that path?
>
>
Also noteworthy is the differentiation of protection against failures,
One-to-One, Facility Backups, what the DMP (detour merge point), etc.
> I am not qualified enough to argue with you, but i know that no
vendor
> will ever mention in their website what they dont support or what
they
> dont recommend because it will lead to problems later, i am just
simply
> wondering if any part of this is true.
I'm lost, did you mean vendors as in equipment vendors or the NSP
portion
of it. I would think equipment vendors would sell you a rainbow to go
with
that supEngine, on the NSP side, I could see some vendors not wanting to
implement it for whatever reason they'd choose.
--
====================================================
J. Oquendo
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743
sil . infiltrated @ net http://www.infiltrated.net
The happiness of society is the end of government.
John Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5157 bytes
Desc: S/MIME Cryptographic Signature
Url :
https://puck.nether.net/pipermail/cisco-nsp/attachments/20070314/245d4a8
5/attachment-0001.bin
------------------------------
Message: 3
Date: Wed, 14 Mar 2007 15:50:24 +0200
From: Dmitriy Sirant <lex at init.net.ua>
Subject: [c-nsp] IPSec between Cisco and D-Link
To: cisco-nsp at puck.nether.net
Message-ID: <et8uj1$uoq$1 at sea.gmane.org>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Hello,
Have main office where somebody put D-Link DFL-1600 as main VPN
concentrator. I try to connect there my cisco 2620.
As i can see, i has worked IKE keys between d-link and cisco, but have
problem when try ping other side. Found something interesting in debug:
1w1d: IP: s=192.168.132.1 (local), d=10.223.132.254 (FastEthernet1/0),
len 100, output crypto map check failed.
But i can't found in google what is the problem.
Also i think about that problem sad #send errors 90,
Here some info about ios and config:
ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
ROM: C2600 Software (C2600-IK9O3S3-M), Version 12.3(20), RELEASE
SOFTWARE (fc2)
cisco-skoda uptime is 1 week, 1 day, 5 hours, 58 minutes
System returned to ROM by power-on
System restarted at 09:37:53 UKR Tue Mar 6 2007
System image file is "flash:c2600-ik9o3s3-mz.123-20.bin"
sh runn (somewhere skipped):
!
ip subnet-zero
ip tcp selective-ack
ip cef
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
lifetime 3600
crypto isakmp key some_key address 212.xx.xx.xx
crypto isakmp keepalive 30 5
!
crypto ipsec transform-set PRN0006 esp-aes esp-sha-hmac
!
crypto map MOJA_MAPA local-address FastEthernet1/0
crypto map MOJA_MAPA 10 ipsec-isakmp
description Tunnel toPRN0006
set peer 212.xx.xx.xx
set transform-set PRN0006
set pfs group2
match address KRYPTO_LIST
!
interface FastEthernet0/0
description Link to LAN
ip address 192.168.132.1 255.255.255.0
speed 100
full-duplex
fair-queue
!
interface FastEthernet1/0
description Link to ISP
ip address 193.xx.xx.xx 255.255.255.224
speed auto
half-duplex
fair-queue
crypto map MOJA_MAPA
!
ip route 0.0.0.0 0.0.0.0 193.xx.xx.xx
ip route 10.0.0.0 255.0.0.0 FastEthernet1/0
!
ip access-list extended KRYPTO_LIST
permit ip 192.168.132.0 0.0.0.255 10.0.0.0 0.255.255.255
!
Some info:
cisco#sh crypto ipsec sa
interface: FastEthernet1/0
Crypto map tag: MOJA_MAPA, local addr. 193.xx.xx.xx
protected vrf:
local ident (addr/mask/prot/port):
(192.168.132.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
current_peer: 212.xx.xx.xx:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 90, #recv errors 0
local crypto endpt.: 193.xx.xx.xx, remote crypto endpt.:
212.xx.xx.xx
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
current outbound spi: 0
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
cisco#ping 10.223.132.254 source 192.168.132.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.223.132.254, timeout is 2 seconds:
Packet sent with a source address of 192.168.132.1
.....
Success rate is 0 percent (0/5)
cisco#sh crypto isakmp sa
dst src state conn-id slot
212.xx.xx.xx 193.xx.xx.xx QM_IDLE 1 0
Please help with that problem.
------------------------------
Message: 4
Date: Wed, 14 Mar 2007 10:11:23 -0400 (EDT)
From: "Justin M. Streiner" <streiner at cluebyfour.org>
Subject: [c-nsp] TCAM refresher
To: cisco-nsp at puck.nether.net
Message-ID: <Pine.LNX.4.64.0703140957580.9092 at whammy.cluebyfour.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Someone I know is considering upgrading the core network device in their
data center to a 6500/Sup2/MSFC2. They take three full BGP feeds from
their transit providers. My initial caution to them about going with
the
Sup2 instead of a Sup720/3BXL was that the Sup2 is limited to about 250k
TCAM entries assuming they're not running uRPF. Given the size of a
full
Internet routing table these days, that allows them a little bit of
headroom, but not much, plus this doesn't take into account their
existing
access-lists, policies, local routes, multicast, Netflow, NAT, etc...
That said, it would seem that a Sup2 would work for now, but it won't be
very long before it would need to be upgraded, i.e. they'd be better off
going with the 720/3BXL straight out of the gate.
IIRC, if the TCAM table fills up, certain operations will either 1.
fail,
or 2. be handled in software, with the associated performance penalties.
Am I correct in saying this?
Also, how much TCAM headroom should be allowed for things like
significant
routing topology changes, i.e. adding a new BGP neighbor, general
routing
table churn, etc?
Thanks
jms
------------------------------
Message: 5
Date: Wed, 14 Mar 2007 09:21:08 -0500
From: Justin Shore <justin at justinshore.com>
Subject: [c-nsp] TACACS+ source-interface in 12.2(33)SRB
To: "'Cisco-nsp'" <cisco-nsp at puck.nether.net>
Message-ID: <45F804D4.30604 at justinshore.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I just put 12.2(33)SRB on a router we have in testing. We'll be moving
all our Sup720-3BXLs to SRB in the near future for CALEA support. I
rebooted that Sup this morning and noticed upon reboot that it would not
auth me via SSH. I checked the logs on my AAA server and found that the
TACACS packets were coming from an interface IP and not from Lo0 like
I had previously configured prior to the reboot. I changed my TACACS
server config to match the packet coming it and it fixed the problem.
When I went to add the missing command to the 720-3BXL, ip tacacs
source-interface Lo0, it would not take it. SRA1 had this feature and
just about every IOS I've used in the last 5+ years. SRB appears to
have either removed the feature or moved it to another command in the
config tree. Source interface commands are still available for NTP,
syslog, and FTP I know.
Does anyone know if this command is a goner or if it just moved to
somewhere else? I haven't been able to find any docs online.
Thanks
Justin
------------------------------
Message: 6
Date: Wed, 14 Mar 2007 10:30:12 -0400
From: Phil Bedard <philxor at gmail.com>
Subject: Re: [c-nsp] Traffic Engineering considers bad ?
To: Sami Joseph <sami.joseph at gmail.com>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Message-ID: <0F059455-0DB1-4F8A-ABBA-7E1E02C56231 at gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
If it fits a problem you are trying to solve then it is currently a
valid
solution and people are using it. If you are using it just
because it's there, it gives you a lot of rope to hang yourself, or
tie yourself
up in complexity.
http://www.cariden.com/technologies/papers/nanog-t-com-
horneffer.pdf , I believe
that is the paper from DT where they went with an MPLS core that uses
TE based
upon IGP metrics and LDP versus RSVP-TE.
Phil
On Mar 14, 2007, at 5:58 AM, Sami Joseph wrote:
> I was just trying to clear something i heard.
>
> 1) Traffic Engineering (in general) is not advised by Cisco or other
> vendors.
> 2) Deutsh telecom removed it because it was complex and problematic
> 3) Labels corruption and mess up
>
> Is there any truth underneath or thats all just FUD.
>
> On 3/6/07, Bruce Pinsky <bep at whack.org > wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Sami Joseph wrote:
>>> Hello,
>>>
>>> My cisco supplier company advises that i dont use Traffic
>>> engineering on
>> my
>>> network because its never stable and it is not mature yet and label
>>> allocation is bad and in general, all vendors doesnt recommend it?
>>>
>>> I came to the right people to ask, what is true of the above, any
>>> known
>>> facts, any article, document?
>>>
>>
>> Sounds like FUD to me. But the real question is what are you
>> trying to
>> accomplish and why do you think TE is the correct solution?
>>
>> - --
>> =========
>> bep
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.4 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFF7aXdE1XcgMgrtyYRAkx4AJ0dPSHlxB/HIwj1wCWzknCd3yHSngCfbyaO
>> wES8hwsJL6Tk1GMhUdXiMR8=
>> =fLHK
>> -----END PGP SIGNATURE-----
>>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
Phil Bedard
philxor at gmail.com
------------------------------
_______________________________________________
cisco-nsp mailing list
cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
End of cisco-nsp Digest, Vol 52, Issue 49
*****************************************
More information about the cisco-nsp
mailing list