[c-nsp] Interesting Problem - MPBGP Filtering

Marko Milivojevic markom at vodafone.is
Mon Nov 12 07:17:34 EST 2007


Sure thing.

PE1 - PE.PE.PE.225
PE2 - PE.PE.PE.226

R1#sh ip bgp vpn all PE.PE.PE.225
BGP routing table entry for AS:1:X.X.X.X.0/19, version 57
Paths: (2 available, best #1, table Internet)
  Not advertised to any peer
  Local
    PE.PE.PE.225 (metric 101) from PE.PE.PE.225 (PE.PE.PE.225)
      Origin IGP, metric 0, localpref 1000, valid, internal, best
      Community: AS:0
      Extended Community: RT:AS:1
      mpls labels in/out nolabel/55
  Local
    PE.PE.PE.226 (metric 101) from PE.PE.PE.226 (PE.PE.PE.226)
      Origin IGP, metric 0, localpref 1000, valid, internal
      Community: AS:0
      Extended Community: RT:AS:1
      mpls labels in/out nolabel/53
BGP routing table entry for 2:AS:4:PE.PE.PE.225/32, version 67
Paths: (2 available, best #2, no table, not advertised to EBGP peer)
  Not advertised to any peer
  Local
    PE.PE.PE.225 (metric 101) from PE.PE.PE.226 (PE.PE.PE.226)
      Origin incomplete, metric 0, localpref 100, valid, internal, mdt, no-import
      Extended Community: RT:AS:4 MDT:AS:239.232.4.1
      Originator: PE.PE.PE.225, Cluster list: 0.0.0.1
      mpls labels in/out nolabel/3
  Local
    PE.PE.PE.225 (metric 101) from PE.PE.PE.225 (PE.PE.PE.225)
      Origin incomplete, metric 0, localpref 100, valid, internal, mdt, no-import, best
      Extended Community: RT:AS:4 MDT:AS:239.232.4.1
      mpls labels in/out nolabel/3
BGP routing table entry for 2:AS:1125:PE.PE.PE.225/32, version 24
Paths: (2 available, best #1, no table, not advertised to EBGP peer)
  Not advertised to any peer
  Local
    PE.PE.PE.225 (metric 101) from PE.PE.PE.225 (PE.PE.PE.225)
      Origin incomplete, metric 0, localpref 100, valid, internal, mdt, no-import, best
      Extended Community: RT:AS:1125 MDT:AS:239.232.4.2
      mpls labels in/out nolabel/3
  Local
    PE.PE.PE.225 (metric 101) from PE.PE.PE.226 (PE.PE.PE.226)
      Origin incomplete, metric 0, localpref 100, valid, internal, mdt, no-import
      Extended Community: RT:AS:1125 MDT:AS:239.232.4.2
      Originator: PE.PE.PE.225, Cluster list: 0.0.0.1
      mpls labels in/out nolabel/3


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
Sent: 12. nóvember 2007 11:28
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Interesting Problem - MPBGP Filtering

Can you post a full

sh ip bgp vpn all PE.PE.PE.1 ?

from R1?

Dave.


Marko Milivojevic wrote:
> I have discovered one interesting issue today. It could be expected
> behaviour, or it could be a bug. It doesn't appear to be very dangerous,
> but I would still like to understand it a little bit better. And get rid
> of the side effects. This is a little bit longer post, so stay with me
> :-).
> 
>  
> 
> I have setup that's similar to this:
> 
>  
> 
>  {mpls cloud}
> 
>   |        |
> 
> [PE1]    [PE2]
> 
>   |        |
> 
>   +--[R1]--+
> 
>  
> 
> There are two PE's that have full mesh MPBGP peerings in the MPLS cloud.
> There is a fair mix of L3VPN, Internet and MVPN in the BGP table. All in
> all some 300k prefixes. To make things more fun, Internet prefixes are
> also in the VPN.
> 
>  
> 
> Router R1 is some "special-purposes" router, that needs just selected
> subset of Internet routes. Due to restrictions on iBGP peering from VRF,
> R1 is doing VPNv4 peering with PE1 and PE2, which are in turn configured
> as route reflectors for it. Fairly simple stuff. And it seems to work.
> Except for one thing.
> 
>  
> 
> Our "Internet route-target" is AS:1, where AS is our AS number. There is
> following configured on R1:
> 
>  
> 
> ip extcommunity-list standard AS-Internet permit rt AS:1
> 
> ip community-list standard AS-Originated-Routes permit AS:0
> 
> ip community-list standard AS-Customer-Routes permit AS:10
> 
>  
> 
> ip prefix-list Internet-Allow permit x.x.x.x/yy
> 
>  
> 
> route-map PE-in permit 5
> 
>  match extcommunity AS-Internet
> 
>  match community AS-Originated-Routes
> 
> !
> 
> route-map PE-in permit 10
> 
>  match extcommunity AS-Internet
> 
>  match community AS-Customer-Routes
> 
> !
> 
> route-map PE-in permit 90
> 
>  match extcommunity AS-Internet
> 
>  no match community Internet-Allow
> 
>  match ip address prefix-list Internet-Allow
> 
> !
> 
> route-map PE-in deny 999
> 
>  
> 
> router bgp AS
> 
>  template peer-policy PE-Policy
> 
>   route-map PE-in in
> 
>   send-community both
> 
>  exit-peer-policy
> 
>  !
> 
>  template peer-session PE-Session
> 
>   remote-as AS
> 
>   password xxxx
> 
>   update-source Loopback0
> 
>   version 4
> 
>  exit-peer-session
> 
>  !
> 
>  bgp router-id x.x.x.x
> 
>  no bgp default ipv4-unicast
> 
>  bgp log-neighbor-changes
> 
>  bgp graceful-restart restart-time 120
> 
>  bgp graceful-restart stalepath-time 360
> 
>  bgp graceful-restart
> 
>  neighbor pe1.pe1.pe1.pe1 inherit peer-session PE-Session
> 
>  neighbor pe2.pe2.pe2.pe2 inherit peer-session PE-Session
> 
>  !
> 
>  address-family vpnv4
> 
>   neighbor pe1.pe1.pe1.pe1 activate
> 
>   neighbor pe1.pe1.pe1.pe1 send-community both
> 
>   neighbor pe1.pe1.pe1.pe1 inherit peer-policy PE-Policy
> 
>   neighbor pe2.pe2.pe2.pe2 activate
> 
>   neighbor pe2.pe2.pe2.pe2 send-community both
> 
>   neighbor pe2.pe2.pe2.pe2 inherit peer-policy PE-Policy
> 
>  exit-address-family
> 
>  !
> 
>  address-family ipv4 vrf Internet
> 
>   no synchronization
> 
>   network X.X.X.X mask 255.255.255.255 route-map R1-Internet-Loopback
> 
>  exit-address-family
> 
> !
> 
>  
> 
>  
> 
> Idea above is that we wish to receive only Internet routes (permitting
> only that route-target) and only our own originated routes and customer
> routes - controlled by appropriate communities. All works, I can see the
> subset of the routes I need.... plus something else.
> 
>  
> 
> No matter what sort of extended community filtering I do inbound on R1
> or outbound on PE1 and PE2, I receive all PE loopbacks in all VPN's
> configured for MVPN! For example, we have VPN that is using RD AS:4
> globally, this is what I see on R1:
> 
>  
> 
> R1#sh ip bgp vpn all | b ^Route.*4$
> 
> Route Distinguisher: 2:AS:4
> 
> * iPE.PE.PE.1/32
> 
>                     PE.PE.PE.1          0    100      0 ?
> 
> *>i                 PE.PE.PE.1          0    100      0 ?
> 
> *>iPE.PE.PE.2/32
> 
>                     PE.PE.PE.2          0    100      0 ?
> 
> * i                 PE.PE.PE.2          0    100      0 ?
> 
> * iPE.PE.PE.3/32
> 
>                     PE.PE.PE.3          0    100      0 ?
> 
> *>i                 PE.PE.PE.3          0    100      0 ?
> 
> * iPE.PE.PE.4/32
> 
>                     PE.PE.PE.4          0    100      0 ?
> 
> *>i                 PE.PE.PE.4          0    100      0 ?
> 
> * iPE.PE.PE.5/32
> 
>                     PE.PE.PE.5          0    100      0 ?
> 
> *>i                 PE.PE.PE.5          0    100      0 ?
> 
> * iPE.PE.PE.6/32
> 
>                     PE.PE.PE.6          0    100      0 ?
> 
> *>i                 PE.PE.PE.6          0    100      0 ?
> 
>  
> 
>  
> 
> ... and so on for every other MVPN.
> 
>  
> 
> Can I get rid of these somehow, without going through the nightmare of
> setting up VRF iBGP peering?
> 
>  
> 
> Kind regards,
> 
> Marko.
> 
>  
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


More information about the cisco-nsp mailing list