From: Rick (rick@iptool.net)
Date: Sun Sep 11 2005 - 23:24:16 GMT-3
One correction on Juniper VPN labels. It is one label per VRF not a label
per CE. There could be thousands of CE's per VRF.
Rick
----- Original Message -----
From: "Chris Lewis (chrlewis)" <chrlewis@cisco.com>
To: "Richard Dumoulin" <Richard.Dumoulin@vanco.fr>; "ccie 2005"
<cui666@gmail.com>; <ccielab@groupstudy.com>
Sent: Sunday, September 11, 2005 8:35 PM
Subject: RE : Cisco MPLS
> 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
>
> _______________________________________________________________________
> 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