[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