[c-nsp] BGP Peering with new client for vrf's

[Oliver Boehmer (oboehmer)]

John,

> >
> > wow, what type of customer is this? If they are using MPLS-VPN
> > themselves, provisioning a CsC service might be a more suitable
option,
> > depending on their requirements?
> > There is a new Inter-AS option ("AB"), where you can maintain
control
> > over the traffic using distinct (sub)-interfaces per VRF, but scale
the
> > control plane using a single eBGP session between the ASBRs. Take a
look
> > at " MPLS VPN - Inter-AS Option AB" feature
> >
(http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ias
> > _optab.html).
> > If you trust your client, a simple Inter-AS option B connection
(vpnv4
> > eBGP, labelled interface between ASBRs) would also work.
> >
> > oli
> >
> 
> 
> Thanks for the reply - Client is wireless provider....they state they
would
> need to scale to this number of vrfs, hence not wanting to go the
> subint/vlan per vrf route....whether this is a reality is debateable.

Please be aware of the security implications. They can theoretically
spoof the top label and send packets to other VPNs/LSPs. As I said:
Inter-AS Option B and C assume a level of trust, so is generally used
between SPs only, rather than between SPs and customer. 

> So we use there existing AS and ours, but add them under vpnv4?(based
on
>
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_e
xamp
> le09186a0080094472.shtml#PEsaro)
> 
> router bgp xxxxx
> neighbour 10.10.10.2 remote as yyyyy
> address family vpnv4
> neighbour 10.10.10.2 activate
> neighbor 10.10.10.2 send-community extended
> 
> And on inter-as link, we do not enable mpls?

No, BGP takes care of it. If you take a look at "show mpls interface
..", you should see "BGP forwarding enabled" or something like this.
 
> Then, how do we restrict which routes they can see?
> 
> Simply with route-target export/imports?

No! You don't need to enable VRFs on the ASBR, you need to restrict the
prefixes you send and receive via extcommunity-lists where you filter on
the RT, i.e.

ip extcommunity-list 1 permit rt 100:3
ip extcommunity-list 2 permit rt 200:3

route-map asbr-out
 match extcommunity 1
route-map asbr-in
 match extcommunity 2

it is also advisable to delete any RTs used by your MPLS-VPN deployment
which they shouldn't be communicating with, otherwise they might inject
routes into your own VPNs. You can use the RT rewrite feature.. for
example assuming your RTs all are 100:xxx, then you can remove them via

ip extcommunity-list 100 permit RT:100:.*
!
route-map asbr-in permit 10
 match extcommunity 100
 set extcomm-list 100 delete
!
route-map asbr-in permit 20
 match extcommunity 2

 
So you see, there is actually a lot to consider in this deployment. You
also need to coordinate RT values with them.. Please take a look at the
"Carrier-supporting-carrier" (CsC) model, which is not a "peering
between equals", but rather a customer/SP relationship with appropriate
security and isolation. 

Please also consider that you will essentially build an end-to-end LSP
between their and your PE. Troubleshooting connectivity issues can be
challenging, as traceroute fails whenever an LSP is broken (wherever it
breaks), and you will need MPLS-OAM or close collaboration with your
customer to actually find out the cause.

Also be aware that you will be switching MPLS packets on the interface.
So you can no longer use IP ACLs for security or qos classification.

I would be happy to discuss this offline, learning the exact
requirements/environment/topology/etc. 
(my availability is limited right now, travelling..)..

	oli