Options

2 Redundant Routers + 2 ISPs eBGP iBGP

DPGDPG Member Posts: 780 ■■■■■□□□□□
I am trying to gather a proof of concept for a client.

The goal is to eliminate as many points of failure in the network as possible.

networkf.png
Router 1 and 2 are taking a full bgp table from ISP A and B respectively.
Router 1 and 2 will be announcing a 1.1.1.0/22 to each provider
Router 1 and 2 have an iBGP session between them.

The /22 will be VLSM'd and assigned to customers on vlan interfaces.
(Example - Customer 1 - int VLAN 10 - 1.1.1.1/29)

How should I handle VLAN redundancy? Should I use HSRP?

Comments

  • Options
    deth1kdeth1k Member Posts: 312
    There is no need for a second link between the two routers as they will have connectivity through the switches in case of failure. For vlan redundancy you could either use HSRP groups or a routing protocol (OSPF).
  • Options
    keenonkeenon Member Posts: 1,922 ■■■■□□□□□□
    if you want to really increase it have provider A and B on both routers. If you do this make sure the provider doesn't terminate the connections on the same router. I have seen this happen which kills that providers redudancy
    Become the stainless steel sharp knife in a drawer full of rusty spoons
  • Options
    burbankmarcburbankmarc Member Posts: 460
    What kind of switches are those? If they're 3750's I'd say just stack them together. If not then you'll have to use some sort of FHRP.
  • Options
    DPGDPG Member Posts: 780 ■■■■■□□□□□
    I'm going to try to lab the internal side of this at work tomorrow with some 3550's. Ideally I would like to use 6500's at the core and distribution layers and 2950/60's for access.
  • Options
    DPGDPG Member Posts: 780 ■■■■■□□□□□
    I'm revisiting this again in a lab.

    Let's say I have assigned 1.1.1.128/29 to a user.

    If I assign the interface on R1:

    interface vlan 10
    ip addresss 1.1.1.129 255.255.255.248

    I can only go in/out through ISP_A.
    What if the best route is through ISP_B?
    How can I configure this to allow traffic from this vlan to get to ISP_B?

    Any traffic coming in through ISP_B can't reach 1.1.1.10.

    Here is the topology:


    topmj.png
  • Options
    peanutnogginpeanutnoggin Member Posts: 1,096 ■■■□□□□□□□
    I'm no expert so I may be way off basis, but I think you can use a route map to tag the traffic and point it to ISP_B as its destination and use ISP_A as a backup. HTH.

    -Peanut
    We cannot have a superior democracy with an inferior education system!

    -Mayor Cory Booker
  • Options
    jason_lundejason_lunde Member Posts: 567
    DPG wrote: »


    Any traffic coming in through ISP_B can't reach 1.1.1.10.

    Here is the topology:


    topmj.png

    Not quite enough info DPG, so I am going to ask a couple questions. Do you not advertise that subnet to ISP B? Are "R1" and "R2" handling full BGP routing tables? If not, are they capable of doing so?
  • Options
    DPGDPG Member Posts: 780 ■■■■■□□□□□
    R1 is advertising 1.1.1.0/24 to ISP_A
    R2 is advertising 1.1.1.0/24 to ISP_B

    Both are taking full routes in from their respective BGP neighbors.


    To prevent being a transit AS:
    I am using a prefix-list to make sure I only announce 1.1.1.0/24 to ISP_A and ISP_B.
    I have next-hop self on each side of the iBGP session.

    Any problems there?
  • Options
    jason_lundejason_lunde Member Posts: 567
    So what is stopping traffic from ISP B from reaching 1.1.1.10? If you are advertising the /24 to both of them, traffic coming in from outside should simply take the best path back to those users. Traffic egressing from your AS through R1 and 2 should be able to take the shortest path (or whatever you dictate to be the best path) out of your AS. Traffic on the internet is, because of the way bgp is designed, for the most part asynchronous, so the return traffic may not come in on the same link it egressed from.
  • Options
    DPGDPG Member Posts: 780 ■■■■■□□□□□
    Here is some more information.

    R1 and R2's iBGP session is connected through loopbacks.

    R1

    int loopback0
    ip address 1.1.1.1 255.255.255.252

    int vlan 5
    description iBGP
    ip address 172.16.0.1 255.255.255.252

    ip route 1.1.1.2 255.255.255.255 172.16.0.2


    R2

    int loopback0
    ip address 1.1.1.2 255.255.255.252

    int vlan 5
    description iBGP
    ip address 172.16.0.2 255.255.255.252

    ip route 1.1.1.1 255.255.255.255 172.16.0.1
  • Options
    lrblrb Member Posts: 526
    DPG wrote: »
    To prevent being a transit AS:
    I am using a prefix-list to make sure I only announce 1.1.1.0/24 to ISP_A and ISP_B.
    I have next-hop self on each side of the iBGP session.

    There is another, simpler way to prevent becoming a transit AS:
    ip as-path access-list 1 permit ^$

    Then apply to each ISP eBGP relationship:
    neighbor ip-address filter-list 1 out

    This will only allow an update going to the ISPs to contain paths which originate in your AS; the '^$' is a simple regular expression which means that you are looking for an empty AS_PATH in the outgoing update
  • Options
    Panzer919Panzer919 Member Posts: 462
    I did this once for a customer, We had 2 routers connected via ibgp using 2 ISP's. if your trying to route traffic on the inside, you could use either floating statics or a routing protocol, then modify their attributes to get the desired results. on the incoming side, you can prepend your AS so that if route A is preferred over route B from the outside, it will basically add your AS so that it looks like a worse route.

    I found a good example online:

    route-map loop permit 10
    match ip address 10
    set as-path prepend 10 10 10 10 10 10 10
    !
    !
    route-map add permit 10
    match ip address 10
    set as-path prepend 2


    router bgp 9
    neighbor 10.20.29.2 route-map loop out

    Then when you look up the path, this route will show up with 7 hops when it might only be 2 away.
    Cisco Brat Blog

    I think “very senior” gets stuck in there because the last six yahoos that applied for the position couldn’t tell a packet from a Snickers bar.

    Luck is where opportunity and proper planning meet

    I have not failed. I've just found 10,000 ways that won't work.
    Thomas A. Edison
  • Options
    DPGDPG Member Posts: 780 ■■■■■□□□□□
    I figured out the issue. I needed to setup an IGP to create routes between R1 and R2. This allowed R2 to learn that 1.1.1.8/29 was reachable via R1.
Sign In or Register to comment.