From: ccie 2005 (cui666@gmail.com)
Date: Sun Sep 11 2005 - 15:03:27 GMT-3
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
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:14 GMT-3