Teaser

[romccallum]

On flying through my studying this weekend i came across a very interesting (well i think it was interesting) and i thought i would share the scenario for everyone to try to see if they get the answer to it spot on. Scenario

PE A connects to CE A

PE B connects to CE B

CE A connects via LAN to CE B

BGP is the routing protocol for the vpn and CEA&B are in the same VPN. There is an IBGP connection between CEA & B also.

Configure this scenario to avoid routing loops. What would you do and why is my question here. The CE routers are in AS 87 and the SP environment is AS 65001.

Enjoy!!

[olorunloba]

Working on the idea of not using SOO, I think filtering based on communities can be used to ensure there will be no routing loops. Lets say for CE1, all the locally injected routes into BGP are tagged with community 1:1 and for CE2 they are tagged with 2:2. CE1 is connected to PE1 and CE2 is connected to PE2.

On PE1, have a route-map to filter all routes with community 1:1 to CE1. Also, PE2 should filter out routes with 2:2 to CE2. With this scenario, I do not expect a routing loop. I assume though that CE1 and CE2 do not have any other BGP sessions.

Any comments on this?

[mheusinger]

Hello,

BGP AS path processing would still prevent CE-CE connectivity through the MPLS VPN. Additionally you would need allowas-in on the CE and then routing loops could occur ... so you need additionally filters on the CEs and the whole thing gets messy and complicated.

Basically one trys to implement something which was not intended by the initial BGP design.

I am sure it can be done ... turn off standard BGP loop detection in PE and CE and configure filtering manually through communities and route-maps.

Or place very CE in its own AS and use LocPref for proper path selection.

In any case it gets painful from an operation point of view.

Regards, Martin

[mheusinger]

Hello,

new idea ... keep the iBGP session between CE routers up and running through the MPLS VPN.

So I would assume floating statics for the Loopbacks of the CE routers would do the trick.

CE1:

interface Loopback0

ip address 10.0.0.1 255.255.255.255

interface Ethernet0

ip address 10.1.1.1 255.255.255.0

interface Serial0

description to PE1

ip address 10.1.2.1 255.255.255.252

ip route 10.0.0.2 255.255.255.255 10.1.1.2

ip route 10.0.0.2 255.255.255.255 10.1.2.2 190

router ospf 10

network 10.0.0.1 0.0.0.0 area 0

network 10.1.1.1 0.0.0.0 area 0

router bgp 65000

neighbor 10.0.0.2 remote-as 65000

neighbor 10.0.0.2 update-source Loopback0

redistribute ospf 10

PE and other CE along the lines of the config above.

This should do the trick.

Comments?

Regards, Martin

[michael_davis]

Hi Martin,

Great discussion/exploration!

No worries. I thought I was misreading. Just wanted to be sure. :-)

I see where I was wrong on the AD issue. AD won't come into play until after the BGP decision process. doh!

I'm with you on your point about QoS for both provider and the customer. Especially when the customer won't pay a premium for a well thought out SLA. Also known as, How does my gold-level EF/Exp 3 RTP traffic get priority over your gold-level EF/Exp 3 RTP traffic in the SP core, etc. When all traffic starts to look the same, nobody gets priority.

Not to digress anymore on the WTF discussion, but I do spend a fair amount of my day working at educating previously L2VPN customers to the pros/cons of L3 VPNs, particularly QoS and backup links. I usually get called after something breaks or the network is asked to perform "un-natural acts" So this is a bit of a sore spot for me.

Anyway, I need to play in the lab with some of the ideas posted here. Clearly, I need to do some add'l homework.

So far I have:

Backdoor links.

Floating static for iBGP over the VPN. (If iBGP is a requirement)

Any others, anyone?

Michael

[mheusinger]

I see your problems Michael. People build a Toyota and you are then in charge to let it look and drive like a Ferrari ...

So your challenge is: "Pimp my network!" ;-)

Have you ever tried to get a job at MTV?

Have fun! Martin