[c-nsp] BGP for multi-homed environment (Alex Foster)
Greg Owens
gowens at covad.net
Tue Sep 7 18:43:24 EDT 2004
You can configure BGP to automatically load balance if they were going to
the same ISP. However, with different ISP you must use the weight or local
preference. You must make sure you don't become a transit area.
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
cisco-nsp-request at puck.nether.net
Sent: Tuesday, September 07, 2004 6:26 PM
To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 22, Issue 16
Send cisco-nsp mailing list submissions to
cisco-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
cisco-nsp-request at puck.nether.net
You can reach the person managing the list at
cisco-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-nsp digest..."
Today's Topics:
1. BGP for multi-homed environment (Alex Foster)
2. Observation about vlan counters (Hroi Sigurdsson)
3. Per packet Load balancing (Amol Sapkal)
4. Re: 6509 Sup720-3B with 6816-GBIC and DFC (Sam Munzani)
5. Re: Network merging: factors to be considered (Rodney Dunn)
6. Wireless Work in Japan for 3-4 Weeks (Skeeve Stevens)
7. Re: Per packet Load balancing (Rodney Dunn)
8. Re: 6509 Sup720-3B with 6816-GBIC and DFC (Ian Cox)
----------------------------------------------------------------------
Message: 1
Date: Mon, 6 Sep 2004 17:21:31 +0100
From: "Alex Foster" <afoster at gammatelecom.com>
Subject: [c-nsp] BGP for multi-homed environment
To: <cisco-nsp at puck.nether.net>
Message-ID:
<F4F9407F37B2D147A65AE47CB478ADF7010F15B4 at gamma01.gammatelecom.com>
Content-Type: text/plain; charset="iso-8859-1"
To begin with Im a novice with BGP and its terminology so please forgive any
inaccuracies. I am migrating our existing network from a single upstream
connection to a dual-fed environment (different ISPs). I have all the BGP
information that I need (AS numbers etc) but am a little unsure as to the
best topology/configuration to implement. I want to connect each feed into
a separate router and load share from my network. First off - is this
possible ?? I have been allocated a class C address block. I also want the
ability to provide seamless failover between both providers. I am also a
little unsure as to what is required with regards to filtering etc; what is
the best policy here??
If anybody implements a similar configuration - I would appreciate some tips
or feedback.
Kind Regards
Alex
The information in this e-mail and any attachments is confidential and may
be subject to legal professional privilege. It is intended solely for the
attention and use of the named addressee(s). If you are not the intended
recipient, or person responsible for delivering this information to the
intended recipient, please notify the sender immediately. Unless you are the
intended recipient or his/her representative you are prohibited from, and
therefore must not, read, copy, distribute, use or retain this message or
any part of it. The views expressed in this e-mail may not represent those
of Gamma Telecom.
This message has been scanned for viruses by MailController
------------------------------
Message: 2
Date: Mon, 06 Sep 2004 18:56:20 +0200
From: Hroi Sigurdsson <hroi at asdf.dk>
Subject: [c-nsp] Observation about vlan counters
To: cisco-nsp at puck.nether.net
Message-ID: <413C96B4.6010504 at asdf.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi.
I recently upgraded some Catalyst 4006-SupIII devices to 12.1(20r)EW1
from 12.1.11b and it looks like the counters in the output from "show
int VlanXX" are now showing numbers that are surprisingly close to
reality, maybe even correct!
I haven't checked whether this is also the case for SNMP counters yet.
Does anyone know in which release Cisco fixed their counters? Maybe it's
a side effect of the PROM upgrade..
------------------------------
Message: 3
Date: Mon, 6 Sep 2004 23:38:08 +0530
From: Amol Sapkal <amolsapkal at gmail.com>
Subject: [c-nsp] Per packet Load balancing
To: cisco-nsp <cisco-nsp at puck.nether.net>
Message-ID: <ef4028ae040906110879d4db26 at mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII
Hi,
I got a client who connects to me on L3 on 2 seperate routers.
I have assigned him a pool of /28 (16 IPs).
The total traffic requirement of the client is 2 Megs. One of the IPs,
in the above pool hogs 90% of the total available badnwidth.
Now, the connectivity of the client router (CE) with my router R1 and
R2 is via Nortel FR switches.
Initially, the client used to connect to R1 only. But, due to banwidth
design limitations on the FR switch, I had to connect it on IP with
the other router R2.
What I did was,
1.Created a PVC 'Y' from the CE which ran upto R2. Made this 1 Megs
fat. Cut down the original PVC 'X' between CE and R1 to 1Megs.
2. Put 2 default routes on the CE to point to these 2 PVCs. This made
sure that my outgoing traffic (from the client router) is load
balanced.
3.R1, on which the CE initially pumped in 2 Megs, is the one which
announces the /24 pool containing the client IPs to the Internet.
4. On R1, I put 2 static routes to the /28 client pool. One points to
the original PVC 'X' and the other pointed to R2 (there is a PVC
running between R1,R2 )
So basically, what I am trying to achieve is 'incoming traffic load
balancing' wrt CE.
This was needed because, the traffic for the /28 pool entered my
network on R1 and I do not want the entire 2 Megs to pass to CE
directly. So I put 2 static routes on R1 so that half the traffic is
diverted via R2 to CE (with an latency overhead)
But for some reason, the load balancing is not happening.
'ip cef' was enabled on R1 before, which I thought, was causing the
problems (If I am not wrong, flows are mapped as a combination of Src
IP/Destn IP to outgoing interface)
After disabling ip cef, I still see that the incoming traffic on CE is
not being load balanced.
Any suggestions?
--
Warm Regds,
Amol Sapkal
--------------------------------------------------------------------
An eye for an eye makes the whole world blind
- Mahatma Gandhi
--------------------------------------------------------------------
------------------------------
Message: 4
Date: Tue, 07 Sep 2004 16:39:51 -0500
From: Sam Munzani <smunzani at comcast.net>
Subject: Re: [c-nsp] 6509 Sup720-3B with 6816-GBIC and DFC
To: Ian Cox <icox at cisco.com>
Cc: cisco-nsp at puck.nether.net, Bob Snyder
<rsnyder at toontown.erial.nj.us>
Message-ID: <413E2AA7.7080302 at comcast.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Ian Cox wrote:
> At 11:31 AM 9/7/2004 -0500, Sam Munzani wrote:
>
>> comments inline,
>>
>>>>
>>>> Which brings up another question for me: Can you use any of the DFC3s
>>>> (WS-F6700-DFC3B, WS-F6700-DFC3A, WS-F6700-DFC3BXL) on any line card
>>>> that
>>>> supports DFC3s?
>>>
>>>
>>>
>>> The WS-F6700-xxx DFCs only function on the WS-X67xx series line
>>> cards. It has a totally different connector to the one that is
>>> required for the WS-X6516s, and WS-X6816 module, they require the
>>> WS-F6K-xxx DFCs. The DFC3b, DFC3bXL DFCs for WS-X615s and WS-X6816
>>> have not been released yet. Contact your account team to get the FCS
>>> date for these DFCs.
>>>
>>> Ian
>>
>>
>> Ian,
>>
>> This is what we have plans to purchase and our Account Team blessed it.
>> WS-SUP720=
>> GLC-SX-MM
>> WS-X6516A-GBIC=
>> WS-F6K-DFC3A=
>>
>> We wanted to use Distributed Forwarding on all our Gig ports and were
>> told to purchase DFC3A daughter card for it.
>> 1. Are these compatible?
>
>
> Yes, because it is a "WS-F6K" and your installing it on a WX-X6516A,
> the WS-X67xx cards take WS-F6700-xxx DFCs.
>
>> 2. Do thoese SFP gig ports on Sup720 need DFC or is it built in since
>> the ports are physically on Sup module?
>
>
> The Supervisor GE ports switching is controlled by the PFCx that is
> part of the Supervisor.
>
>> 3. Will EoMPLS work with this hardware?
>
>
> No. EoMPLS requires DFC3b or DFC3bXL along with a Supervisor with
> PFC3b or PFC3bXL. You could have EoMPLS supported on the above
> configuration if you do not install the WS-F6K-DFC3A= on the
> WS-X6516A-GBIC= module and the Supervisor is a PFC3b or PFC3bXL based
> Supervisor. If you wish to have EoMPLS and DFCs for all Gig ports I
> would recommend changing the Gigabit card listed above to a WS-X6724
> (It uses SFPs instead of GBICs) with a WS-F6700-DFC3b or 3bXL DFC.
>
> Ian
We wanted to go with PFC3B route but could not because at the time of
e-rate submission, it was not available. I guess we are stuck with PFC3A
and without EoMPLS till next upgrade budget. The current network does
not require EoMPLS so didn't justify PFC3bXL at the time of e-rate
submission. However we see eventually using EoMPLS down the road(Not
near term though)
I appreciate the clear cut explaination(that I should have got from our
Acount Manager or SE)
Thanks,
Sam
------------------------------
Message: 5
Date: Mon, 6 Sep 2004 23:01:46 -0400
From: Rodney Dunn <rodunn at cisco.com>
Subject: Re: [c-nsp] Network merging: factors to be considered
To: Amol Sapkal <amolsapkal at gmail.com>
Cc: Zaheer Aziz <zaziz at cisco.com>, cisco-nsp
<cisco-nsp at puck.nether.net>
Message-ID: <20040906230146.B3423 at rtp-cse-489.cisco.com>
Content-Type: text/plain; charset=us-ascii
Here is a pretty good page. If you have to do mutual
points of redistribution it's highly recommended
to use tags.
http://cco.cisco.com/en/US/tech/tk365/tk207/technologies_tech_note09186a0080
09487e.shtml
Rodney
On Mon, Sep 06, 2004 at 09:04:42PM +0530, Amol Sapkal wrote:
> Hi,
>
> First thing, this is not an actual scenario, its just a Question that
> arised while my team was having a generic discussion.
>
> On Mon, 06 Sep 2004 01:21:27 -0500, Zaheer Aziz <zaziz at cisco.com> wrote:
> > At 04:20 AM 9/4/2004 +0530, Amol Sapkal wrote:
> > >Need to know what you guys think of this:
> >
> >
> > There are several techniques depending on the circumstances.
> >
> > Few Q?
> > 1)Will the new network be under one control?
> Yes.
>
> > 2)Any overlapping Private IP addresses?
> Yes. But this can be resolved by re-designing the IP Scheming
>
> > 3)Running two different IGPs (could you specify which ones) may pose
some
> > challenge
> > with training, redistributions, loops etc.
> OSFP and RIP
>
> > 4)Can BGP can considered as an option to glue the two networks together?
> >
> Yes, IBGP could be considered. But we were considering redistribution
> as an option.
>
> > This should be a good start
> >
> > Zaheer
> >
> >
> >
> >
> > >If I got 2 networks, that need to merged, both running different IGPs
> > >what would be the design considerations?
> > >
> > >Considering redistribution as an option, what would be the obstacles
and
> > >checks?
> > >What would be an alternative to redistribution?
> > >
> > >
> > >
> > >--
> > >Warm Regds,
> > >
> > >Amol Sapkal
> > >
> > >--------------------------------------------------------------------
> > >An eye for an eye makes the whole world blind
> > >- Mahatma Gandhi
> > >--------------------------------------------------------------------
> > >_______________________________________________
> > >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/
> >
> >
>
>
>
> --
> Warm Regds,
>
> Amol Sapkal
>
> --------------------------------------------------------------------
> An eye for an eye makes the whole world blind
> - Mahatma Gandhi
> --------------------------------------------------------------------
> _______________________________________________
> 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/
------------------------------
Message: 6
Date: Tue, 7 Sep 2004 13:45:11 +1000
From: "Skeeve Stevens" <skeeve at skeeve.org>
Subject: [c-nsp] Wireless Work in Japan for 3-4 Weeks
To: <cisco-nsp at puck.nether.net>
Message-ID:
<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA3lTk66ynJ0mF5BlGTsZ+XsKAAAAQ
AAAAWGxKfRpEdkKkVSPI9uBvkQEAAAAA at skeeve.org>
Content-Type: text/plain; charset="us-ascii"
Ok..
We're looking for someone who is interested in travelling around Japan for
3-4 weeks doing Wireless site surveys and installation of Wireless Access
Points (Cisco) and install a Cisco Pix Firewall (config supplied -
familiarity is all that is required for the PIX).
Must speak fluent Japanese and very goodly English ;-)
Please email 'japan at skeeve.org' if you are interested.
_______________________________________________________
Skeeve Stevens, RHCE Email: skeeve at skeeve.org
Website: www.skeeve.org - Telephone: (0414) 753 383
Address: P.O Box 1035, Epping, NSW, 1710, Australia
eIntellego - skeeve at eintellego.net - www.eintellego.net
_______________________________________________________
Si vis pacem, para bellum
------------------------------
Message: 7
Date: Mon, 6 Sep 2004 23:14:37 -0400
From: Rodney Dunn <rodunn at cisco.com>
Subject: Re: [c-nsp] Per packet Load balancing
To: Amol Sapkal <amolsapkal at gmail.com>
Cc: cisco-nsp <cisco-nsp at puck.nether.net>
Message-ID: <20040906231437.C3423 at rtp-cse-489.cisco.com>
Content-Type: text/plain; charset=us-ascii
It's better to draw a picture for scenarios like this.
I think I get what you have done.
Internet -- R1 ---- PVCa ----\
| \--CE -- /28
R2 ---- PVCb -------/
So to loadbalance from the CE to the internet you
put two default routes on the CE pointing at PVCa and PVCb.
Then to get to the /28 from the internet you put a /28
route on R1 to PVCa and a second pointing at R2 so R1 has
equal cost routes (at least from R1's perspective) to get
to the CE. You put the same /28 route on R2 towards PVCb I
assume.
Given that, it still will not guarantee you have equal
load balancing over those links because all it takes is
one large pair of ip addresses to use all the bandwidth.
My post a few days ago went over this in detail.
One flow (src/dst) ip pair could eat up all the bandwidth
on one of the PVC's.
Now if your spread of traffic is pretty good between the
/28 and the Internet you should see *some* load sharing
but it will not be 50/50 most likely.
Your best bet is to run netflow and see who are the top
talkers and to verify the path they are taking on R1
do "sh ip cef exact-route <src> <dst>".
This is an example where you may have to do per-packet
if you are required to get more granular on the traffic
split.
Rodney
On Mon, Sep 06, 2004 at 11:38:08PM +0530, Amol Sapkal wrote:
> Hi,
>
> I got a client who connects to me on L3 on 2 seperate routers.
> I have assigned him a pool of /28 (16 IPs).
>
> The total traffic requirement of the client is 2 Megs. One of the IPs,
> in the above pool hogs 90% of the total available badnwidth.
>
> Now, the connectivity of the client router (CE) with my router R1 and
> R2 is via Nortel FR switches.
> Initially, the client used to connect to R1 only. But, due to banwidth
> design limitations on the FR switch, I had to connect it on IP with
> the other router R2.
> What I did was,
> 1.Created a PVC 'Y' from the CE which ran upto R2. Made this 1 Megs
> fat. Cut down the original PVC 'X' between CE and R1 to 1Megs.
> 2. Put 2 default routes on the CE to point to these 2 PVCs. This made
> sure that my outgoing traffic (from the client router) is load
> balanced.
> 3.R1, on which the CE initially pumped in 2 Megs, is the one which
> announces the /24 pool containing the client IPs to the Internet.
> 4. On R1, I put 2 static routes to the /28 client pool. One points to
> the original PVC 'X' and the other pointed to R2 (there is a PVC
> running between R1,R2 )
>
> So basically, what I am trying to achieve is 'incoming traffic load
> balancing' wrt CE.
> This was needed because, the traffic for the /28 pool entered my
> network on R1 and I do not want the entire 2 Megs to pass to CE
> directly. So I put 2 static routes on R1 so that half the traffic is
> diverted via R2 to CE (with an latency overhead)
>
> But for some reason, the load balancing is not happening.
> 'ip cef' was enabled on R1 before, which I thought, was causing the
> problems (If I am not wrong, flows are mapped as a combination of Src
> IP/Destn IP to outgoing interface)
> After disabling ip cef, I still see that the incoming traffic on CE is
> not being load balanced.
>
> Any suggestions?
>
>
>
> --
> Warm Regds,
>
> Amol Sapkal
>
> --------------------------------------------------------------------
> An eye for an eye makes the whole world blind
> - Mahatma Gandhi
> --------------------------------------------------------------------
> _______________________________________________
> 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/
------------------------------
Message: 8
Date: Tue, 07 Sep 2004 13:30:23 -0700
From: Ian Cox <icox at cisco.com>
Subject: Re: [c-nsp] 6509 Sup720-3B with 6816-GBIC and DFC
To: sam at munzani.com
Cc: cisco-nsp at puck.nether.net, Bob Snyder
<rsnyder at toontown.erial.nj.us>
Message-ID: <6.1.2.0.2.20040907131433.052eb988 at mira-sjcd-1.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 11:31 AM 9/7/2004 -0500, Sam Munzani wrote:
>comments inline,
>
>>>
>>>Which brings up another question for me: Can you use any of the DFC3s
>>>(WS-F6700-DFC3B, WS-F6700-DFC3A, WS-F6700-DFC3BXL) on any line card that
>>>supports DFC3s?
>>
>>
>>The WS-F6700-xxx DFCs only function on the WS-X67xx series line cards. It
>>has a totally different connector to the one that is required for the
>>WS-X6516s, and WS-X6816 module, they require the WS-F6K-xxx DFCs. The
>>DFC3b, DFC3bXL DFCs for WS-X615s and WS-X6816 have not been released yet.
>>Contact your account team to get the FCS date for these DFCs.
>>
>>Ian
>
>Ian,
>
>This is what we have plans to purchase and our Account Team blessed it.
>WS-SUP720=
>GLC-SX-MM
>WS-X6516A-GBIC=
>WS-F6K-DFC3A=
>
>We wanted to use Distributed Forwarding on all our Gig ports and were told
>to purchase DFC3A daughter card for it.
>1. Are these compatible?
Yes, because it is a "WS-F6K" and your installing it on a WX-X6516A, the
WS-X67xx cards take WS-F6700-xxx DFCs.
>2. Do thoese SFP gig ports on Sup720 need DFC or is it built in since the
>ports are physically on Sup module?
The Supervisor GE ports switching is controlled by the PFCx that is part of
the Supervisor.
>3. Will EoMPLS work with this hardware?
No. EoMPLS requires DFC3b or DFC3bXL along with a Supervisor with PFC3b or
PFC3bXL. You could have EoMPLS supported on the above configuration if you
do not install the WS-F6K-DFC3A= on the WS-X6516A-GBIC= module and the
Supervisor is a PFC3b or PFC3bXL based Supervisor. If you wish to have
EoMPLS and DFCs for all Gig ports I would recommend changing the Gigabit
card listed above to a WS-X6724 (It uses SFPs instead of GBICs) with a
WS-F6700-DFC3b or 3bXL DFC.
Ian
>We don't need it now but see a value for it in near term.
>The idea of WUP720-3B was dropped since there is no DFC3B available
>today(Was required before e-rate grant request)
>
>Thanks a lot in advance,
>Sam
------------------------------
_______________________________________________
cisco-nsp mailing list
cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
End of cisco-nsp Digest, Vol 22, Issue 16
*****************************************
More information about the cisco-nsp
mailing list