From: ccie 2005 (cui666@gmail.com)
Date: Mon Sep 12 2005 - 01:48:02 GMT-3
That's exactly we saw during our interoperability testing between
Cisco PE and Juniper PE, but whether it's because cisco PE is sending
too many labels or it's because Juniper PE can't handle large amount
of labels, it's debatable. To make scenarios like Internet-in-a-vrf
really work, I would say one label per vrf is your best bet, hope we
see it soon on Cisco routers(in particular, GSR platforms)
and I am not quite convinced that it would be any difference in a
dual-CE load balancing scenario, unless CEF-in-a-vrf uses inner labels
as part of its load-balancing hashing algorithm or something?
Pat
On 9/11/05, Chris Lewis (chrlewis) <chrlewis@cisco.com> wrote:
> There is a lot of history to this, but essentially the difference
> between Juniper and Cisco PE's is as described (the P routers function
> the same regarding the MPLS question originally asked, although I'm sure
> the account teams from both vendors will have a well prepared set of
> differentiators to share).
>
> I have seen a customer with Juniper routers that do not have as much
> space to hold label values as Cisco routers (the issue arised when the
> Cisco PE was sending something like 35,000 labels to a Juniper PE), I
> have heard it suggested that the limited label space is why Juniper came
> up with the label per CE rather than label per route concept. Although
> as I don't work for Juniper, I don't know if this is accurate. There are
> some corner cases regarding load balancing for dual CE connected sites
> where the label per CE provides sub-optimal operation, but for the vast
> majority of cases, a label per CE is fine, which is why Cisco is coding
> the label per CE as an option instead of the label per prefix.
>
> Chris
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Richard Dumoulin
> Sent: Sunday, September 11, 2005 4:50 PM
> To: 'ccie 2005'; ccielab@groupstudy.com
> Subject: RE : RE : RE : Cisco MPLS
>
> So you have 1 label per CPE instead of per network per CPE? It makes
> sense as it is a FEC representing a CPE...
>
> -- Richard
>
> -----Message d'origine-----
> De : ccie 2005 [mailto:cui666@gmail.com] Envoyi : dimanche 11 septembre
> 2005 21:10 @ : ccielab@groupstudy.com Objet : Re: RE : RE : Cisco MPLS
>
> I am not sure if I understood your comments but I was referring to the
> inner label, not the outer label. the inner label's basic function is
> just an indentity of a VPN, so it is not unique based on different
> next-hops, but based on which VPN it represents. say if you have 2 PEs
> each carrying a VPN route in the same vrf, from the 3rd PE, you only
> see different outer labels for the 2 VPN routes because the netx-hop is
> different. The inner labels? they are the same if all 3 PE routers are
> Juniper routers, as for Cisco, they are improving as I mentioned in my
> previous email(and personally I don't know why Cisco is doing it
> differently, ie, even the routes are in the same vrf, the INNER labels
> are unique on a per route basis, maybe someone from cisco can gives more
> insights of this). once the packets in a VPN are delivered to the
> destination PE, all the PE has to do is to forward the packets to the
> right vrf and then deliver them to the right CEs, the inner labels are
> just leading the packets to the vrf they are representing, they are not
> used for indentifing next-hop in the vrf, it's all back to ip at this
> point, so obiviously packets are forwarded to the right CEs based on
> dest. ip, nothing else.
>
> Cheers,
> Pat
>
>
>
> On 9/11/05, Scott Morris <swm@emanon.com> wrote:
> > The label savings is based on next hop, not just routes in a VRF! As
> > I'm sure you know you can have many different next-hops even though
> > the routes have been brought into the same VRF.
> >
> > Scott
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of
> ccie
> > 2005
> > Sent: Sunday, September 11, 2005 2:03 PM
> > To: ccielab@groupstudy.com
> > Subject: Re: RE : RE : Cisco MPLS
> >
> > How could I forget CEF?! but you got the basic concept. I would
> > disagree
> of
> > some of your other corrections, but I don't feel like chasing them
> > right now...
> >
> > My question for you: if you already knew these, what made you think
> > only Cisco can make BGP-free core network and the rest can't? it's
> > rather a benefit of turning P routers into MPLS switches than anything
>
> > else. And furthermore, if you knew Cisco, Juniper and other vendors
> > support FR over MPLS, ATM over MPLS, or Ethernet over MPLS, will it
> > make you think the P routers has to be FR , ATM or Ethernet switches?
> > the answer is an obivious NO!, so the same goes to IPv4(bgp routes)
> > over MPLS. P routers is a IP routers at first, but when you turn-up
> > MPLS on
> them,
> > IP is just an underlying protocol to form MPLS LFIB. you could turn on
>
> > BGP in P routers, but will the P routers use bgp table(didn't forget
> > CEF this time, but to make it simple:)) no!, because now they are just
>
> > MPLS
> switches,
> > not really a IP router anymore.
> >
> > Someone in C&W may directly answer your question as they have a
> > Juniper
> core
> > network(?), we only use Juniper as edge routers. but again I would be
> REALLY
> > REALLY surprised if the answer is: Juniper needs BGP in P routers. (it
>
> > amazes me how many carriers still have BGP in their core networks and
> > at
> the
> > same time, they have MPLS!, I am not joking, this is from my
> > converstions with fellow engineers in NANOG, mplscon, and etc)
> >
> > Scott, we use Alcatel 7750/7450 routers as PEs, so I know they are
> > Juniper-alike routers, really powerful boxes, network-processor based
> > hardware architecture, lots of ports, wonderful QoS performance, OS is
>
> > not as good as JunOS, but usable. they followed Juniper on lots of
> > concepts, though they have their own L2VPN solutions(of course,
> > because Vach
> Kompella
> > works for them!), no big difference on routing tables, mpls lsp
> > tables,
> etc
> >
> > Simon, it's interesting you mentioned Internet-in-a-vrf concept,
> > because
> we
> > are looking at it right now, and found out that Cisco has unique inner
> label
> > for each of the routes in the same vrf: 160000 routes means 160000
> labels!
> > Juniper only uses one inner label for all the routes in the same vrf
> > thus saves tremendous label resources. I wonder if you use Cisco gears
>
> > as PEs
> and
> > do you consider this as a limitation? the last time I heard from our
> > Cisco SE, they will have a knob to let customer choose whether single
> > label for all routes in the same vrf or not, but not sure it's already
> available?
> (in
> > particular, on GSR platforms)
> >
> > Cheers,
> > Pat
> >
> >
> >
> >
> >
> >
> >
> >
> > On 9/11/05, Richard Dumoulin <Richard.Dumoulin@vanco.fr> wrote:
> > >
> > >
> > > Hi Pat,
> > >
> > > thx for the explanation but I already knew this. The question
> > > remains unanswered. I quote you " I would be REALLY surprised that
> > >
> > > Juniper, Alcatel or other vendors in this game would not see it" -->
>
> > > I would just like the answer to this.
> > >
> > > Now let me correct some of your sentences below. In step 1 when the
> > > packet arrives at peer1, the router does not look at his routing
> > > table but at his CEF table. Then it imposes the label which also
> > > corresponds to peer2 BGP ip address or BGP next hop.
> > >
> > > In steps 2,3 and 4 peer2 looks at its LFIB table in order to swap
> labels.
> > > Peer2 is supposed to not have any BGP table so how would it do a
> > > recursive BGP lookup? At least in a Cisco based network. The LFIB
> > > would is created from 2 tables: the LIB and the RIB (derived form an
> IGP).
> > >
> > > Finally, in step 6, the operation is such that peer2 will never have
>
> > > to perform 2 lookups. Either it will consult its CEF table because
> > > of PHP or its LFIB.
> > >
> > > All this started in my head because I did hear rumours that Juniper
> > > P routers needed a full routing table in order to label switch BGP
> > > destination packets, that is all. Now this still remains unanswered.
> > >
> > > Also I did not say it was magic but just found the concept amazing
> > > and wonderful. I very much like MPLS and I am just starting to
> > > appreciate it although I did a lot of work with it when I was
> > > working for GlobalOne in Spain 5 years. It was the first MPLS
> > > network in the country
> > by then!
> > >
> > > -- Richard
> > >
> > >
> > >
> > > -----Message d'origine-----
> > > De : ccie 2005 [mailto:cui666@gmail.com] Envoyi : dimanche 11
> > > septembre 2005 05:46 @ : ccielab@groupstudy.com Objet : Re: RE :
> > > Cisco MPLS
> > >
> > >
> > > let me try to explain this using packet walkthrough, imagine this;
> > >
> > > peer router1(igp/bgp/mpls) - p1(igp/mpls)-p2(igp/mpls)-peer
> > > router2(igp/bgp/mpls) - customer router(ebgp with peer2)
> > >
> > > peer router #1 and #2 have full bgp routing table, p1 and p2 only
> > > have isp's internal IGP routes and mpls lsp table based on igp. a
> > > packet trying to get to customer router from peer router 1, and here
>
> > > are the
> > > steps:
> > >
> > > 1. packet arrived at peer1 as ipv4 packet, looking at ip routing
> > > table, and a bgp route learned from peer2 indicates that the packet
> > > has to be delivered to peer2 router in order to reach the
> > > destination; 2. now peer1 started bgp recurisive lookup process,
> > > realized that in order to reach peer2, the packet need to go to p1;
> > > 3. because peer1 and p1 are running mpls in between, an mpls label
> imposition occurred.
> > > note that the packet's destination ip is still customer router's ip
> > > which p1 doesn't know; 4. packet arrived at p1, will p1 look at the
> > > destination ip of the packet? NO! (this is the key part), it will
> > > only look at the imposed label from peer1 and use mpls pre-learned
> > > lsp table to deliver the mpls packet to p2; 5. p2 will look at its
> > > lsp table and deliver the packet to peer2 as mpls packet or ip
> > > packet depends on whether you use PHP or not, to make it simple,
> > > let's say it still sent mpls to peer2; 6. peer2 receive the packet,
> > > as it's the last hop of the mpls lsp path, it performed 2 things:
> > > pop the label and do ip lookup. as it has the customer's route in
> > > its bgp routing table learnt via ebgp, it sent the packet to
> > > customer router. end of journey!
> > >
> > > like I mentioned, the key step is #4, and if you really understood
> > > this step, you will see there was no magic here: all because of you
> > > have used mpls as transport protocol instead of ip in the core
> > > network.
> > >
> > > And if I could see the "magic", I would be REALLY surprised that
> > > Juniper, Alcatel or other vendors in this game would not see it.
> > >
> > > and the similar steps goes to mpls/vpn,only one more label to deal
> > > with as the inner label is the indentity of the VPN, the edge PEs do
>
> > > all the work, P routers still see the outer label without knowledge
> > > of inner labels and ip info.
> > >
> > > to end this, MPLS is not only capable of transporting ipv4 packets,
> > > but also almost everything else - ATM cells, FR frames, IPv6,
> > > Ethernet frames, etc, other rfcs like martini-draft, vpls and
> > > cisco's ATOM(Any Transport Over MPLS) are based on the basic
> concept.
> > >
> > > HTH,
> > > Pat
> > >
> > >
> > >
> > >
> > >
> > > On 9/10/05, Richard Dumoulin <Richard.Dumoulin@vanco.fr> wrote:
> > > > Take the example of an ISP using an MPLS backbone. Will Juniper P
> > > > routers need all the routes to create the LSP table? We all know
> > > > that this is not the case with Cisco. What about the others?
> > > >
> > > > -- Richard
> > > >
> > > > -----Message d'origine-----
> > > > De : Scott Morris [mailto:swm@emanon.com] Envoyi : dimanche 11
> > > > septembre 2005 04:05 @ : Richard Dumoulin; 'Joe Rinehart';
> > > > ccielab@groupstudy.com Objet : RE: Cisco MPLS
> > > >
> > > > The LSP "routing table" is a different list all together. You CAN
>
> > > > have
> > > BGP
> > > > routes present, but it's certainly not necessary to have your
> > > > customer routes present.
> > > >
> > > > Scott
> > > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > > > Behalf Of Richard Dumoulin
> > > > Sent: Saturday, September 10, 2005 9:19 PM
> > > > To: 'Joe Rinehart'; ccielab@groupstudy.com
> > > > Subject: RE : Cisco MPLS
> > > >
> > > > I heard that on a Juniper based MPLS network, the BGP networks
> > > > needed to
> > > be
> > > > present on the P routing tables. Would be nice if anyone could
> > > > confirm or not by having a look at the routing table...
> > > >
> > > > -- Richard
> > > >
> > > > -----Message d'origine-----
> > > > De : Joe Rinehart [mailto:jjrinehart@hotmail.com] Envoyi :
> > > > dimanche
> > > > 11 septembre 2005 02:12 @ : Richard Dumoulin;
> > > > ccielab@groupstudy.com
> > Objet :
> > > > Re: Cisco MPLS
> > > >
> > > > Yes, I realize that but I was pointing out how the architecture
> > > > works in general, most notably the IGP vs. BGP functionality.
> > > > Even if you do not create MBGP VPNs the routing behavior is the
> > > > same, with the IGP knowing
> > > ONLY
> > > > core routes and BGP just at the edges. Both protocols run
> > > > separately with no real interaction...
> > > >
> > > > And as far as the AT&T network goes, yes there is a large Cisco
> > > > component, particularly on the edges, but Avici routers are
> > > > operating
> at
> > the core.
> > > The
> > > > architecture is independent of the actual platforms....
> > > >
> > > > Joe Rinehart
> > > > CCIE #14256, CCNP, CCDP
> > > > Data Network Consultant
> > > > AT&T Pacific Northwest Enterprise Markets
> > > > ----- Original Message -----
> > > > From: "Richard Dumoulin" <Richard.Dumoulin@vanco.fr>
> > > > To: "'Joe Rinehart'" <jjrinehart@hotmail.com>;
> > > > <ccielab@groupstudy.com>
> > > > Sent: Saturday, September 10, 2005 2:12 PM
> > > > Subject: RE : Cisco MPLS
> > > >
> > > >
> > > > > But AT&T are using Cisco routers I believe. Also please note
> > > > > that I am not talking about MPVPN but just about the way BGP
> > > > > network destinations are label switched,
> > > > >
> > > > > Regards
> > > > >
> > > > > -- Richard
> > > > >
> > > > > -----Message d'origine-----
> > > > > De : Joe Rinehart [mailto:jjrinehart@hotmail.com] Envoyi :
> > > > > samedi 10 septembre 2005 01:07 @ : Richard Dumoulin;
> > > > > ccielab@groupstudy.com Objet : Re: Cisco MPLS
> > > > >
> > > > > Anyone feel free to jump in if I am way off base here...
> > > > >
> > > > > It's pretty much just a function of how the routing is set
> > > > > up...I created
> > > > a
> > > > > mini-MPLS network on my lab rack and really was surprised to see
>
> > > > > how the mechanics all work, especially as I tried to mimic how
> > > > > we have it set up
> > > > at
> > > > > AT&T. The feature you are referring to is sometimes called a
> > > > > route-free core. The label switched core itself doesn't have
> > > > > any knowledge of edge
> > > > (or
> > > > > MPLS VPN) routes at all, they are clueless of anything outside
> > > > > the
> > > > backbone
> > > > > itself. Usually an IGP like OSPF or ISIS is run between the P
> > > > > nodes in
> > > > the
> > > > > core and includes the PE devices too. I had one router get all
> > > > > buggy because of short memory so I verified just using static
> > > > > routing across the simulated backbone and that worked too. The
> > > > > core just uses IGP and
> > > > internal
> > > > > routes and does the label switching from PE to PE.
> > > > >
> > > > > The magic is at the PE, it's pretty much doing all the heavy
> lifting.
> > > > > The PE runs BGP at the edge only, peering with the CE (using
> > > > > eBGP) and other PE's (using iBGP), and it's also responsible for
>
> > > > > creating the MPLS VPN's using Route Distinguishers and
> > > > > Multiprotocol BGP. The core doesnt know, doesnt care and doesnt
>
> > > > > play with BGP or the VPN's, it just pushes
> > > > traffic...
> > > > >
> > > > > The same would apply to Internet routes, as the BGP on the
> > > > > edge/PE routers would know all of it, advertise routes, and
> > > > > such, but once passed to the core P routers it would be label
> switched....
> > > > >
> > > > > It really is cool fascinating stuff.....
> > > > >
> > > > > Joe Rinehart
> > > > > CCIE #14256, CCNP, CCDP
> > > > > Data Network Consultant
> > > > > AT&T Pacific Northwest Enterprise Markets
> > > > > ----- Original Message -----
> > > > > From: "Richard Dumoulin" <Richard.Dumoulin@vanco.fr>
> > > > > To: <ccielab@groupstudy.com>
> > > > > Sent: Friday, September 09, 2005 2:03 PM
> > > > > Subject: Cisco MPLS
> > > > >
> > > > >
> > > > > > There is a feature in MPLS that I find powerful and it is the
> > > > possibility
> > > > > of
> > > > > > building an Internet backbone with 160000 routes present only
> > > > > > in the PEs routing table. I was wondering if this was only a
> > > > > > Cisco feature or do
> > > > the
> > > > > Ps
> > > > > > of other vendors also support this like Juniper for example?
> > > > > >
> > > > > > Thx
> > > > > >
> > > > > > -- Richard
> > > > > >
> > > > > >
> > > > > >
> > > ********************************************************************
> > > > > > ** Any opinions expressed in the email are those of the
> > > > > > individual and not
> > > > > necessarily the company. This email and any files transmitted
> > > > > with it are confidential and solely for the use of the intended
> > > > > recipient. If you are not the intended recipient or the person
> > > > > responsible for delivering it to the intended recipient, be
> > > > > advised that you have received this email in error and that any
> > > > > dissemination, distribution, copying or use is strictly
> prohibited.
> > > > > >
> > > > > > If you have received this email in error, or if you are
> > > > > > concerned with
> > > > the
> > > > > content of this email please e-mail to:
> > > > > e-security.support@vanco.info
> > > > > >
> > > > > > The contents of an attachment to this e-mail may contain
> > > > > > software
> > > > viruses
> > > > > which could damage your own computer system. While the sender
> > > > > has taken every reasonable precaution to minimise this risk, we
> > > > > cannot accept liability for any damage which you sustain as a
> > > > > result of software
> > > > viruses.
> > > > > You should carry out your own virus checks before opening any
> > > > > attachments
> > > > to
> > > > > this e-mail.
> > > > > >
> > > ********************************************************************
> > > > > > **
> > > > > >
> > > > > >
> > > ____________________________________________________________________
> > > > > > ___ Subscription information may be found at:
> > > > > > http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > > >
> > > ____________________________________________________________________
> > > __
> > > > > _ Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> > > ____________________________________________________________________
> > > __
> > > _
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> > > ____________________________________________________________________
> > > __
> > > _
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > > ____________________________________________________________________
> > > __ _ Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> > ______________________________________________________________________
> > _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:14 GMT-3