关于inter-as mpls vpn# EmergingNetworking - 热门网络技术
p*a
1 楼
目前国外各大运营商主要用哪个option来做为互连方式？ 以前可能A用的比较多，现在
是不是已经在考虑转到C了？
是不是已经在考虑转到C了？
s*g
2 楼
The most popular option is option C, the problem with option A is
scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
【在 p***a 的大作中提到】
: 目前国外各大运营商主要用哪个option来做为互连方式？ 以前可能A用的比较多，现在
: 是不是已经在考虑转到C了？
scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
【在 p***a 的大作中提到】
: 目前国外各大运营商主要用哪个option来做为互连方式？ 以前可能A用的比较多，现在
: 是不是已经在考虑转到C了？
z*r
3 楼
nod, and I don't think option A has ever been popular. All 3 options are
defined in the same RFC (2547bis then 4364), that means when ppl think of
inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
very obviously, tho it looks very simple. However, when 2 SP's talking about
inter-as vpn connectivity, they normally want some strategy inter-
connectivity, not just case by case, which is as you said, not scale, high
maintain cost.
the problem of option C is it requires 2 SP
【在 s*****g 的大作中提到】
: The most popular option is option C, the problem with option A is
: scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
defined in the same RFC (2547bis then 4364), that means when ppl think of
inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
very obviously, tho it looks very simple. However, when 2 SP's talking about
inter-as vpn connectivity, they normally want some strategy inter-
connectivity, not just case by case, which is as you said, not scale, high
maintain cost.
the problem of option C is it requires 2 SP
【在 s*****g 的大作中提到】
: The most popular option is option C, the problem with option A is
: scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
d*i
4 楼
//hand. I think option B is also easier to implement compared to option C. for example, our
testcenter can test this using option b only because we almost don't need to
do anything additional to implement this test.
is
about
route
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
testcenter can test this using option b only because we almost don't need to
do anything additional to implement this test.
is
about
route
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
z*r
5 楼
right, option C increases the complexity because of the route reflectors
btw, are you still busy everyday? and how was your interview?
for example, our
to
【在 d****i 的大作中提到】
: //hand. I think option B is also easier to implement compared to option C. for example, our
: testcenter can test this using option b only because we almost don't need to
: do anything additional to implement this test.
:
: is
: about
: route
btw, are you still busy everyday? and how was your interview?
for example, our
to
【在 d****i 的大作中提到】
: //hand. I think option B is also easier to implement compared to option C. for example, our
: testcenter can test this using option b only because we almost don't need to
: do anything additional to implement this test.
:
: is
: about
: route
p*a
6 楼
option b is not very scalable and has some security concerns.
is
about
route
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
is
about
route
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
p*a
7 楼
actually some vendors still don't support option c yet. option c also has
some security concerns.
option C is not trivial, while option A does not need any special handling
besides basic MPLS-VPN implementation, so option A is kind of poor man's
Inter-AS solution, any vendor t
【在 s*****g 的大作中提到】
: The most popular option is option C, the problem with option A is
: scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
some security concerns.
option C is not trivial, while option A does not need any special handling
besides basic MPLS-VPN implementation, so option A is kind of poor man's
Inter-AS solution, any vendor t
【在 s*****g 的大作中提到】
: The most popular option is option C, the problem with option A is
: scalability and managment overhead. However, implementing option B and option C is not trivial, while option A does not need any special handling besides basic MPLS-VPN implementation, so option A is kind of poor man's Inter-AS solution, any vendor that supports basic MPLS-VPN will be able to implement inter-AS by using option A. Of cause, vendor has to support "sub-interface" on ASBR link (vlan on Ethernet, sub-interface on ATM B
s*g
8 楼
Could you please elaborate what are the security concerns of option B and
option C?
And how are those security concerns are addressed by option A?
IPsec over MPLS is always an option if customers are paranoid.
【在 p***a 的大作中提到】
: actually some vendors still don't support option c yet. option c also has
: some security concerns.
:
: option C is not trivial, while option A does not need any special handling
: besides basic MPLS-VPN implementation, so option A is kind of poor man's
: Inter-AS solution, any vendor t
option C?
And how are those security concerns are addressed by option A?
IPsec over MPLS is always an option if customers are paranoid.
【在 p***a 的大作中提到】
: actually some vendors still don't support option c yet. option c also has
: some security concerns.
:
: option C is not trivial, while option A does not need any special handling
: besides basic MPLS-VPN implementation, so option A is kind of poor man's
: Inter-AS solution, any vendor t
s*g
9 楼
Of course you don't run IGP between to SPs for option C, this is a basic
requriement of any inter-AS, no IGP between ASBRs.
Problem with option B is also obvious, ASBRs have to be VPN aware (you need
to configure vrf/vpn address family under ASBR's bgp in order to exchange
VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
imagine if you have a dozen customers and each customer wants to have whole
Internet routes ..., not many vendors on the market can do over 1M routes
hardw
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
requriement of any inter-AS, no IGP between ASBRs.
Problem with option B is also obvious, ASBRs have to be VPN aware (you need
to configure vrf/vpn address family under ASBR's bgp in order to exchange
VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
imagine if you have a dozen customers and each customer wants to have whole
Internet routes ..., not many vendors on the market can do over 1M routes
hardw
【在 z**r 的大作中提到】
: nod, and I don't think option A has ever been popular. All 3 options are
: defined in the same RFC (2547bis then 4364), that means when ppl think of
: inter-as MPLS VPN, they've known all 3 options. The drawback of option A is
: very obviously, tho it looks very simple. However, when 2 SP's talking about
: inter-as vpn connectivity, they normally want some strategy inter-
: connectivity, not just case by case, which is as you said, not scale, high
: maintain cost.
: the problem of option C is it requires 2 SP
z*r
10 楼
I actually wanted to mean the IGP routes are exchanged between AS's in
option C, because an ASBR must have the knowledge of all loopbacks of the PE
routers within the AS, then uses eBGP to advertise them to other AS's. This
requires greater trust between 2 SP's.
Also a lot of situations that ppl use RR to improve the scalability, thus
the eBGP connections exist only between the blue RR in the blue AS and the
green RR in the green AS.
In option B, ASBR VPN awareness shouldn't be a problem at all,
【在 s*****g 的大作中提到】
: Of course you don't run IGP between to SPs for option C, this is a basic
: requriement of any inter-AS, no IGP between ASBRs.
: Problem with option B is also obvious, ASBRs have to be VPN aware (you need
: to configure vrf/vpn address family under ASBR's bgp in order to exchange
: VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
: imagine if you have a dozen customers and each customer wants to have whole
: Internet routes ..., not many vendors on the market can do over 1M routes
: hardw
option C, because an ASBR must have the knowledge of all loopbacks of the PE
routers within the AS, then uses eBGP to advertise them to other AS's. This
requires greater trust between 2 SP's.
Also a lot of situations that ppl use RR to improve the scalability, thus
the eBGP connections exist only between the blue RR in the blue AS and the
green RR in the green AS.
In option B, ASBR VPN awareness shouldn't be a problem at all,
【在 s*****g 的大作中提到】
: Of course you don't run IGP between to SPs for option C, this is a basic
: requriement of any inter-AS, no IGP between ASBRs.
: Problem with option B is also obvious, ASBRs have to be VPN aware (you need
: to configure vrf/vpn address family under ASBR's bgp in order to exchange
: VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
: imagine if you have a dozen customers and each customer wants to have whole
: Internet routes ..., not many vendors on the market can do over 1M routes
: hardw
p*a
11 楼
i agree with you more on this.
but actually different ASes can be in a singile IGP domain, of course, in
this case the ASes should belong to a same provider.
need
whole
PEs
【在 s*****g 的大作中提到】
: Of course you don't run IGP between to SPs for option C, this is a basic
: requriement of any inter-AS, no IGP between ASBRs.
: Problem with option B is also obvious, ASBRs have to be VPN aware (you need
: to configure vrf/vpn address family under ASBR's bgp in order to exchange
: VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
: imagine if you have a dozen customers and each customer wants to have whole
: Internet routes ..., not many vendors on the market can do over 1M routes
: hardw
but actually different ASes can be in a singile IGP domain, of course, in
this case the ASes should belong to a same provider.
need
whole
PEs
【在 s*****g 的大作中提到】
: Of course you don't run IGP between to SPs for option C, this is a basic
: requriement of any inter-AS, no IGP between ASBRs.
: Problem with option B is also obvious, ASBRs have to be VPN aware (you need
: to configure vrf/vpn address family under ASBR's bgp in order to exchange
: VPN labels with neighbors) and ASBRs have to hold all VPN routes (just
: imagine if you have a dozen customers and each customer wants to have whole
: Internet routes ..., not many vendors on the market can do over 1M routes
: hardw
p*a
12 楼
for option b, the security concern is label spoofing at the asbr
for option c, the security concern is access to all PEs from the remote AS
yes you can use some tools such as filter to reduce the risk but SPs still
should worry about it.
【在 s*****g 的大作中提到】
: Could you please elaborate what are the security concerns of option B and
: option C?
: And how are those security concerns are addressed by option A?
: IPsec over MPLS is always an option if customers are paranoid.
for option c, the security concern is access to all PEs from the remote AS
yes you can use some tools such as filter to reduce the risk but SPs still
should worry about it.
【在 s*****g 的大作中提到】
: Could you please elaborate what are the security concerns of option B and
: option C?
: And how are those security concerns are addressed by option A?
: IPsec over MPLS is always an option if customers are paranoid.
相关阅读
还是有不能做合集的关于Intel的一点传言【菜鸟求助】无法上网，555这个web desktop方案怎么样?WiMax哪里注册域名比较便宜？关于我的电脑的IP地址的问题。How to build up a small local business network?有谁用过Vonage公司的无线产品？华为在印度玩儿了个政治游戏有人对IPv6的协议感兴趣吗？Ingress QoSWRV54G + winXP Client VPN setup need help用godaddy的请看看反无线路由？Consortium Said to Weigh Vodafone Bid如何防止无线网络被盗用?[合集] Anybody has Multi Point Bridging experience?请教：.NET Framework 1.1有没有支持数据压缩的函数？ (转载)skype 协议被中国公司破解？