From: Scott Morris (swm@emanon.com)
Date: Sun Sep 11 2005 - 09:23:27 GMT-3
In Cisco world, you have an LSP table (LFIB) and a routing next-hop table
(CEF). In Juniper routers, you have an inet.0 routing table for unicast
routes and an inet.3 routing table for MPLS LSP paths.
So you have a similar thought process among both routers. I don't have
experience with Alcatel devices or others in MPLS, so all I could do was
assume their behavior at that point. But like Pat said, I can't imagine
that other don't do similar behavior.
HTH,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Richard Dumoulin
Sent: Sunday, September 11, 2005 6:39 AM
To: 'ccie 2005'; ccielab@groupstudy.com
Subject: RE : RE : Cisco MPLS
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
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:14 GMT-3