From: Richard Dumoulin (Richard.Dumoulin@vanco.fr)
Date: Sun Sep 11 2005 - 07:38:45 GMT-3
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