The MPLS-OPS Archive

[Robert Raszuk <raszuk@cisco.com>]

Hi Roger,

Yes as Rajiv and I already said ext community ORF is not implemnted in
IOS. What is implemented is prefix list ORF for ipv4 AF only. Hope this
clarifies this confusion. 

Now reg your question:

> Alok's next question would be: Once the ORF is in place and the filtering 
> is being done on the passive BGP speaker, what happens if the other end 
> (destination) decides it really does want that route? How does the RR 
> retract the ORF and allow the forwarding of that route?

It does not. The other dst has really nothing to decide in this case.
ORF is not transitive. It is pushing only local configuration of inbound
filter to your peer - as simple as this. 

So your scenario should not happen - why - simply as the general rule of
thumb is to connect all PEs especially when rr-group is applied to all
RR clusters especially if all of them server different rr-group.

Rgs,
R.

> Roger Clark Williams wrote:
> 
> Rajiv, help me out and clarify something for me please. The bgp rr-group
> command is stated on the RR. This RR unit then sends information to the
> passive BGP speakers (the ORF message) saying "don't send me updates for
> this VRF route", and that message is based on the RT of the route in
> question, not the RD. Since secondary RTs can be issued to refer to only
> certain addresses or subnets within a given VRF, this allows a more
> granular filtering of routes at the RR level. My question is this: I
> thought the ORF process was already available in the IOS, but you say in
> another note "Since ORF is yet to be supported in IOS,...".
> 
> And unless I missed it (and it is early and I don't have my glasses...)
> Alok's next question would be: Once the ORF is in place and the filtering
> is being done on the passive BGP speaker, what happens if the other end
> (destination) decides it really does want that route? How does the RR
> retract the ORF and allow the forwarding of that route? I would go look it
> up, but your answers are very clear so I will pass it back to you.
> 
> Roger Williams
> 
> At 05:26 PM 10/13/2002, Rajiv Asati wrote:
> >Alok,
> >
> >At 04:00 PM 10/13/2002, alok wrote:
> >>well yes....
> >>
> >>for starters can u please tell me what ORF means?
> >
> >Outbound Route filtering, a feature that allows a BGP speaker to advertise
> >to its BGP neighbors the outbound route filters neighbors should use.
> >These filters are described in ORF entries, which are part of
> >route-refresh message.
> >Yes, it is actually a BGP capability that should be exchanged before the
> >session comes UP.
> >
> >In a nutshell, ORF is a way to tell the neighbors that "hey, don't send me
> >an update/prefix etc, since I don't need it".
> >This helps to reduce unwanted routing updates.
> >
> >ORF for prefixes have been existing for quite-a-while as explained below:
> >http://www.cisco.com/en/US/products/sw/iosswrel/ps1612/products_feature_guide09186a008008088c.html
> >
> >>  and how does cisco carry out BGP updates for multiple VPNs? dont u use
> >> route distinguishers? as
> >>proposed in RFC2547 ?
> >
> >Of course.
> >[ So VPNv4 address is RD:IPv4.And the MP-BGP update contains this VPNv4
> >address along with an extended-community RT.]
> >
> >
> >Now in MPLS VPN context, ORF support gets extended to extcomm. (I don't
> >know about the IETF draf for this one).
> >
> >I guess your Q is really: why RT, why not RD for ORF ?
> >Having RD based ORF may defeat the purpose of extranet, since a PE might
> >not have a certain VRF configured, but still accepting routes (from that
> >VPN) into another VPN based on RT.
> >
> >Hope this helps.
> >Cheers,
> >Rajiv
> >
> >
> >
> >
> >>----- Original Message -----
> >>From: Rajiv Asati <rajiva@cisco.com>
> >>To: alok <alok.dube@apara.com>
> >>Cc: Joseph Anthony <tonyjoe20002002@yahoo.co.in>; <rogerw@nordlink.com>;
> >><mpls-ops@mplsrc.com>
> >>Sent: Monday, October 14, 2002 1:14 AM
> >>Subject: Re: [MPLS-OPS]: REG: Filtering of MPLS VPN routes
> >>
> >>
> >>Alok,
> >>
> >>At 10:29 AM 10/13/2002, alok wrote:
> >> >have been following this thread for a while so ...as i started getting
> >> >lost, i thought id ask a question....
> >> >
> >> >wouldnt RRs be "per vrf based"?
> >>
> >>RR typically does not have any VRF configured.
> >>Are you referring to any other implementation ?
> >>
> >>  From my understanding,  Joseph was referring to extcomm based filtering on
> >>RR. Since he mentioned IOS CLI "bgp rr-group", I assumed he was referring
> >>to Cisco's implementation.
> >>
> >>Cheers,
> >>Rajiv
> >>
> >> >so in that case wudnt the vrf be assoicated with a "RD" flag...?
> >> >
> >> >how would ever spill over routes at all...i guess u mean "spill over
> >> >routes of other VPNs".... then the answer is you wont coz the NLRIs have
> >> >the RD field indicating which VPN the route belongs too....
> >> >
> >> >so i doubt if u will ever need filters at all.....
> >> >for this case...unless u want to block certain routes in the same VPN...
> >> >
> >> >unless cisco does something different from "RDs"...havent done MPLS VPNs
> >> >on cisco but only junipers and zebra etc..so am not sure on this...
> >> >
> >> >-rgds
> >> >Alok
> >> >>----- Original Message -----
> >> >>From: <mailto:tonyjoe20002002@yahoo.co.in>Joseph Anthony
> >> >>To: <mailto:rajiva@cisco.com>Rajiv Asati ;
> >> >><mailto:rogerw@nordlink.com>rogerw@nordlink.com
> >> >>Cc: <mailto:mpls-ops@mplsrc.com>mpls-ops@mplsrc.com
> >> >>Sent: Saturday, October 12, 2002 8:23 PM
> >> >>Subject: Re: [MPLS-OPS]: REG: Filtering of MPLS VPN routes
> >> >>
> >> >>  Hi All,
> >> >>
> >> >>Thanks for all the inputs. I do have some questions in regard to
> >> >>Route-Filtering pertaining to Route Reflectors configurations in an MPLS
> >> >>VPN environment. Assuming the following scenario -
> >> >>
> >> >>Now while using Extended community based filtering by means of the ORF
> >> >>for route filtering. My question is as follows -
> >> >>
> >> >>1. In a partitioned RR setup, should all the RR clients and RR server
> >> >>have the extended community list and bgp-rr group configured on them, in
> >> >>order to facilitate both outbound and inbound filtering (dynamic).
> >> >>
> >> >>Assuming I have 2 RR's, each servicing a set of VPN's. Now in a situation
> >> >>in which an existing PE router suddenly needs to service a VPN, to which
> >> >>it has not provided routes previously, I understand that we would need to
> >> >>have the PE router establish an additional session to the other
> >> >>Route-reflector, which is currently reflecting routes to its clients for
> >> >>the particular VPN. This requires filtering to happen at the PE, wherein
> >> >>the PE should not spill over unwanted VPN routes to either of the RR's.
> >> >>Now while using Extended community based filtering by means of the ORF
> >> >>for route filtering. My question is as follows -
> >> >>
> >> >>1. How would the same work here? Any sample config will be greatly
> >> >>appreciated.
> >> >>
> >> >>Thanks in advance,
> >> >>
> >> >>Tony.
> >> >>
> >> >>
> >> >>
> >> >>Yahoo! Properties Special Buy, sell, rent...your flat, or even post an ad
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml